I'm currently using the ITEADLIB_Arduinoo_Nextion-Master library, and have the latest version.
Currently, I'm working on a project that has a screen with several text/number fields and buttons.
The screen needs to be refreshed fairly quickly (10-per second) and have 10 fields to update, and 3-buttons that requires attention if pressed within the page.
The run-time experience shows that sometimes the buttons are not being recognized, and requires several 'clicks' for the Arduino code to see it (nextLoop).
After a little research in the way the messages are handled, i discovered the following.
When a field needs to be updated, it sends the text and waits for the (ACK) response. If the response happens to be the ACK , then all is good.
But if, for some reason, a button is pressed and its message happens to sneak in before the ACK reply for the pending text-write , the Arduino library code tries to handle the incoming message incorrectly. It will try to use the Button event message as the reply to the pending Text-update and it fails, thus, failing the reply and trashing the button event.
Has anyone have experience this phenomenon, and/or have a solution for it?
A rewrite to the Hardware.cpp will resolve this issue, just trying to see if a solution already exists.
Forget the ITEAD library, I have yet to hear anyone say it is any good. To the best of my knowledge there is no one here offering support for it.
Here is my tutorial for Nextion displays Using Nextion displays with Arduino
There is also a link in there to an alternative library if you prefer that to my way of doing things.
I doubt that very much. Can you see 10 refreshes per second? I would think it's just a flickering mess. You should only update data on any screen when something changes and not more than about 3 times per second because there's no point going faster, no one can see it.
A problem I did have that sounds a bit like yours is sending several thousand bytes to a waveform I could overload the input buffer with too much data. I settled on using the serial port at 38400 baud, which seems to be as fast as it will go without over filling the input buffer.
While @PerryBebbington supports his way to handle the Nextion,
I don't think ignoring the native message format
is a good way to circumvent the problems of the itead library.
It is quite simple to handle the normal communication yourself,
and you don't have to use the blocking approach that the itead library uses.