2.3 Level III : Loading Images and Using Switches
.. to be continued
just a test
Now it gets more challenging:
We are working on the truly usable version of our script, with the following enhancements over the "Level 2" version:
- To make it look nicer, we want to display an icon before each of the two telemetry sensors.
- Additionally, we will use a 3-position switch to retrieve either the current value (middle position) or the max/min value.
- The color representation should also change accordingly (max values in red, min values in blue).
Example: Red = "Max Value"
The completed widget can already be found in the "tut 2.3" folder.
To display graphics or images under Ethos, they must first be "loaded" into the code. This effectively assigns a variable to the graphic.
In this example, this is done in the header section, i.e., at the "beginning" of the script.
This way, the variable is available to all handlers.
Since two sensor values will be displayed, I load two suitable images; the variables are named bmp1 and bmp2.
Often, images associated with the widget are stored in the corresponding widget directory, with the path specified accordingly.
What is the command for loading? Since we want to display an image on the screen, the method is logically located in the lcd class.
The code is as follows:
The display is achieved using the drawBitmap method, which can be referenced in more detail in the Reference Guide.
In general, the command is:
The graphic from the bmp variable is displayed at the coordinates x,y** **with the specified **width **and height.
The title says it all.
Whether it’s a telemetry sensor, logical switch, analog input, or physical switch, Ethos simply considers these objects as sources of some kind that return values.
Therefore, sources are defined as variables in the code.
As with telemetry sensors, the value() method reads a value from the source and assigns it to another variable.
Remember, a source is defined as a variable only ONCE.
Once defined, it can be read as often as needed with value().
In 5.1, it was already mentioned that the header is executed once when the transmitter starts, along with the registration. Therefore, a variable for the switch sources (srcSwitch) is defined in the header and is available to this script environment.
As you can see, the syntax is the same as for the telemetry sensor; only a different category is used.
Great, now we have a source, but how do I apply it?
First, I read the state of the switch in the wakeup handler:
Depending on the value, I then assign a "self-explanatory constant" to another variable.
This "other variable" can take on three states, just like the switch, and now represents the states "show minimum values," "show maximum values," and "show real-time values."
The names of the three corresponding constants were chosen as follows:
- VALUE_LIVE
- VALUE_MIN
- VALUE_MAX
The variable that takes on one of these values "handles" the switch state and can therefore be referred to as a handler:
Assignment of the "switch handler" named swHandler:
Here you can see two things:
a)
Depending on the switch state (x < 0, x = 0 [middle position], or x > 0), the "switch handler" is assigned a value previously defined as a "self-explanatory constant" in the header.
The advantage is that later, you only need to check if the handler (representing the switch state) has the status for:
- "Real-time" display, i.e., VALUE_LIVE
- or "Minimum value display," i.e., VALUE_MIN, etc.
This makes the code much easier to read later, rather than repeatedly checking the actual switch value
for =0, <0, etc.
b)
Depending on the Max/Min state, a color value (tmpColor) is also set directly; only during the real-time display are the colors specifically chosen in the paint handler.
The necessary constants for the switch handler and colors were, of course, also added in the header beforehand.
For completeness:
Now that swHandler has been set in the wakeup routine and represents the switch state, we can build a logic that reads the current, maximum, or minimum value from the telemetry sensors accordingly.
In the paint handler, you’ll find the following code block before displaying the values:
Depending on the switch state, the desired sensor values are provided.
It’s nice to see how the value method can specify parameters to achieve this.
- OPTION_SENSOR_MIN
- OPTION_SENSOR_MAX
The respective values are selected.
Such options are always listed under the 'base' section in the Lua reference guide.
... just take a look there to see what exists.
As the title suggests ("display"), we are still in the paint handler.
Here is the essential excerpt for the actual display.
For Understanding: Before the actual data, the corresponding icon is placed first.
The Size of the Icon
Starting from the last widget, we add the necessary "sizing" for the bitmap, i.e., the size of the icon (local bmpSize). We set the icon size to 90% of the line height.
Positioning
We also define the variable bmpY for independent placement along the Y-axis, separate from the text. This adds a bit more code but looks nicer afterward (-;
Drawing
Finally, we can use lcd.drawBitmap(...) to draw the previously loaded bitmap.
Now, as in Level 2, the respective value is displayed!
With this, our original goal is achieved.
We display two telemetry values and can retrieve Max/Min values with a switch.
In addition to the three progressively developed widgets just described, a template is also included.
This allows the entire exercise to be easily followed in the simulator.
The template displays all three widgets simultaneously.
Feel free to experiment with the coding and make your own adjustments.
However (cliffhanger)!
I’m not a fan of conspiracy theories, but as is often the case in programming:
"Nothing is as it seems."
Our widgets seem to meet our goals and expectations in the simulator.
This is often the case. You’re pleased with the result, everything works as it should at first, but sooner or later, small issues arise because minor changes in the environment cause problems. The cause is not really the changed environment but that "not everything was done quite right."
I’ve intentionally placed a few small "Easter eggs" here; maybe you’ll spot them. Have fun searching! Only when these "Easter eggs" are found and fixed will this chapter truly be complete.
Otherwise, the solution will be revealed soon (-;