Writing to global variables causes considerable lag and chugging

Hey everyone! Trying to solve a problem here -

I have a project with about 80 global variables over 6 pages that update constantly and simultaneously, and do so just fine.

In trying to free up ram, I am trying a couple approaches at freeing up memory:

  1. In progmem.s: defining global ints. ex., int var1, var2, var3, var4, etc. Then using those variables as master variables that I update right before a page load
  2. Using the variable function that puts them on the page on the bottom bar, writing to those in the background while not on the page, and restoring those values to the values on the page when the page is loaded (then just modifying the page values directly).

I can get both methods to work, but for some reason that I do not know what, writing to those global variables will slow things down to a chug and parts of my program will just cease to function because of some sort of delays happening. From what I can see, and I could be wrong, but it looks like writing to those defined global variables for some reason introduces some lag into the nextion. I’m using a 4.3 inch basic display.

Any insights into what I may be doing wrong? Just to reiterate, the display works awesome using the objects on the screen defined as global variables with very little to no lag and snappy integration with my arduino program. It just seems that once I start serving those defined global vars data, things start to chug.

Really strange. It seems that its not the serial data being written to the device, unless i’m addressing things wrong? when I modify the Nextion program.s and remove the variable declarations, things speed up again, even if I am still sending the serial commands for those variables.

for a program.s declaration of ‘var1’ I am sending “var1=xxnumber” from arduino.

Honestly I haven‘t done such live updating yet. So part of my answer is speculation which others might be able to confirm or correct.

I am sending “var1=xxnumber”

Looks good to me. Don’t forget the "\xff\xff\xff" at the end of every command you send to the nextion.

Of course the processing of the data does take time. Usually this is no problem because it only takes a little bit of time. However I can imagine that a continuous datastream or simply a massive amount of data slows things noticeably down.

In my application I load a ton of variables at the beginning from the microcontroller to the Nextion. This worked just fine up to a certain number of variables. Then I got errors; the input buffer of the Nextion was overflowing. In my case the fix was easy; adding a 20ms delay between every block of data (~10 variables) was enough to fix the issue. Since this upload happens only once at the beginning, delays aren’t problematic.
So my advice would be to make sure you do not get any errors from your nextion. I don’t know if errors slow it down or not but they aren’t good for sure.

Another thought… The nextion protocol is a string based protocol. With Arduino this is very handy to use but strings are horribly inefficient. They require lots of processing to send and to receive. They take up more space, need to be parsed and the data needs to be converted back to what it was (String to integer f.ex.).
Therefore it might be faster to disable the nextion protocol and implement your own one. You’d need around 6 Bytes to update one variable instead of the 10-20 bytes needed for the nextion command. Admitted, this would require quite a bit of work.

Btw: I wonder how the parsing is actually done. Especially how it finds the variable to write to. All it has is a string, so it would have to search through all the components in the current scope to find the one whose name matches the string, right?
In that case I’d guess that it’s quite a bit faster to use the p and b array. Because you immediately give the right index and the nextion wouldn’t have to search for it. Especially for the components further down the list this could make a bigger difference.
Has anyone done some benchmarks on this?

Kind regards,

Thanks again for your response Max - I am using the “Easy Nextion Library” which does include the ending “\xFF\xFF\xFF” on all the commands. It really is strange as it does seem to be on the nextion side.

Stranger still to me is the fact that it works PERFECTLY with simply all the objects on the screen declared vscope global, and only start to chug when you declare and start updating those global values. I want to know how those object variables are declared and parsed inside the system to make it happen without lag.

Looking at the recmod- if I were to make my own protocol, would it have to be connected to a timer to work properly? because the timer can only refresh every 50ms.

Very interesting that global variables take such a long time… especially since it would be easy to recognize them as global (no .val ending). While I can’t answer the question why it is like this, I’d suggest as workaround to make one page with all variables. Sure, your names get a bit longer but other than that it shouldn’t have any disadvantages.

Since “normal” variable objects do not suffer from the issue you describe, It’s probably not worth the effort of writing your own protocol. And yes, I think you’d have to use timers. Although I can think of a way to get around the 50ms limit. If you start multiple timers f.ex. every 10ms, and let all of them do the exact same task you effectively get a 10ms period instead of 50ms. But again, I wouldn’t go through such efforts if its not strictly necessary.

Kind regards,


The plot thickens - So it appears for some reason, it is chugging when I start defining local variables.

  1. I have my program that works great with global variables
  2. I save my program under a new name and the only change made is i’ve made all the global variables local. Ram is low and no program memory is anywhere near it’s limit.
  3. Chugging.

Could it be that something is up with the local variables? Does trying to write to a local variables on another page cause the Nextion to chug like mad?

eh… you can’t write to local variables of other pages…? That’s the whole point of them being local. They are only loaded to RAM (and thus read and writable) when the page is loaded/active. Accessing a local variable from another page should give you an error that it couldn’t find that variable.
Don’t know what this does to the performance.

Edit: I just realize that there might be a misunderstanding what you or I mean with global/local variables. local variables are variables that are only visible on the current page (like described above). Global variables can belong to a page or can be defined in the Program.s file. I‘d suggest to call the latter ones „system variables“ (because the system variables sys0, sys1, sys2 are defined in the Program.s file, too). This makes it easier to distinguish them from global variable objects on a page.

Kind regards,

Thanks Max - that solved it! Once I stopped trying to write to other pages with local variables it sped right up - looks like it was being weighed down by errors.

1 Like