If you’re trying to implement a custom feature on the Nextion that’s computationally intensive (eg. graphics, trig, sqrt, etc) I’ve found that using certain system variables can speed up calculations versus local or global user-defined (.val) variables
Here are some userful system variables, along with min/max ranges, increment(++) speed and increased calculation speed versus user-defined variables (in %)
Increment++ Speed Vs
Variable Range Speed (uS) User Defined Notes
sys0/1/2 -2147483648 to 2147483647 (32-bit signed) 39 + 41%
sya0/1 -2147483648 to 2147483647 (32-bit signed) 39 + 41%
thc 0 to 65535 (16-bit unsigned) 43 + 35% Touch Paint Brush Color
pwm4/5/6/7 0 to 100 42 + 37% PWM Duty Cycle (Enhanced)
global .val -2147483648 to 2147483647 (32-bit signed) 66 User Defined
local .val (32-bit signed) 65 User Defined
ADDITIONAL NON-VOLATILE SYSTEM VALUE
Another useful note about “hidden” system variable ‘appid’…
This system variable has a range of -2147483648 to 2147483647 (32-bit signed), is read/write and also NON-VOLATILE. A new Nextion screen will return -1 for ‘appid’. Any value written to ‘appid’ will persist between power cycles. This may be useful for saving firmware revisions, unique id #'s, etc that persist.
For debugging and development purposed, it’s often helpful to have your firmware detect if it’s running on an actual Nextion device or in the Debug simulator so it can behave differently. One previously mentioned method for detecting Nextion vs Simulator involves baud rate values (always 9600 in Simulator).
These are a few other methods I’ve found for easy detection:
‘pwmf’ variable - always 0 in simulator, defaults to 1000 on Nextion
‘appid’ variable - always 0 in simulator, defaults to -1 on Nextion but can be changed (NON-VOLATILE)
‘thc’ variable - always 0 in simulator, defaults to 63488 (RED) on Nextion
Interesting results! I didn‘t expect those differences for sure. There are cases where it makes sense because the Nextion “compiler” doesn‘t always translate the variable names into addresses. However, that shouldn‘t be the case here… So I do struggle to think of a reason for those differences.
Since you‘re already on it, you could also check the differences between
p[page.id].b[name.id]. It might also be interesting to see
Please include details about the Nextion screen and the Nextion Editor used because it‘s unlikely that these results hold true for all models.
Regarding the “creative” usage of system variables:
As has been pointed out in the official forums,
sya0/1 is used internally by Nextion, too. However, what they don‘t tell you is how. Let me fill in that gap. The Nextion “compiler” decomposes components into simpler drawing commands from the instruction set (
fill, …). In some cases this requires one or two temporary variables, namely
sya2. As far as I could tell they aren‘t used anywhere else.
That means that
sya1/2 aren‘t generally suited as “storage” variables because component updates can overwrite them. However, using them as temporary variables within press/release/… events shouldn‘t ever cause any issues.
Since only very few components use
sya1/2 (radio buttons was one case if I‘m not mistaken; can‘t remember the full list), one could argue that it‘s “safe” to use them as global variables anyways - if the project isn‘t using those components. While true in certain cases, this can change at any time with an editor update. The usage as temporary variable however is unlikely to be broken.
appid actually has a purpose that has been demonstrated with the NSPanel firmware. It is possible to have multiple TFT files concatenated into one, and then flash that to the device. Each header contains an appid field with a unique value. By setting the appid variable and resetting the device you can select into which image you boot. The NSPanel image using this feature has been compiled with a 1.64 editor version that hasn‘t been released yet, so it‘s well possible that this feature is completely disabled in current versions.
Future versions however may not like it when the appid has some random value that doesn‘t match any TFT file.
NSPanel uses this feature to change the screen orientation btw.
The tests and benchmarking above were done on Nextion 3.2" Enhanced models with the firmware compiled in Editor version 0.58.
On a side note, I’ve also done some other testing on some of the “hidden” commands.
Here are a few findings:
’lcd_refx’ behaves like the ‘rest’ command but operates much faster. It takes you to the first page and you’ll get the normal start up messages over serial
[Nextion Startup] 0x00 0x00 0x00 0xFF 0xFF 0xFF
[Nextion Ready] 0x88 0xFF 0xFF 0xFF
’getpassw’ prints a seemingly random number over the serial port followed by the normal 0XFF 0XFF 0XFF terminators. The command will continue to return the same value every time until the display is restarted. Each power up results in a new value being returned with no obvious pattern or sequences to the results.
’showqq’ This one is just plain weird. Sending ‘showqqÿÿÿ’ over the serial line results in…penguins. Lots of them. Sixty 40x40 cartoon penguins filling the entire screen each sporting a fashionable red scarf. Dead serious. No clue why this occurs or why the cartoon penguins are a component of Nextion’s 0.58 firmware images.
Are you f*ing kidding me? Pretty much every Nextion Forum poster gets to hear how stupid their feature requests are because only bytes of firmware space were left and reserved for future editor updates or whatever. And what’s that precious firmware space filled with? Penguins.
I think I’m going to reply with that screenshot every time Patrick mentions firmware space was too limited for sensible improvements. Because Penguins.
Edit: Can someone verify if this is still the case with current editor versions?
Here some Penguins too .
Display NX4832K035 buyed some weeks ago, needed update to editor ver. 1.63.3