I made a previous topic in bug where you get the same value when you request txt value from different text fast and mr Martin concluded that it was my terrible code and closed the topic.
Because i guess support team doesn't want to discuss and figure out what is wrong or listen I will post the problem and the fix so anyone with the same problem can solve it.
The problem is that the LCD Simulation is slow, maybe it became slower since the time where they wrote the library.
When you request a value there is a TimeOut value in NexHardware.h which is set to 100 mil.
Now lets see some data from logic analyzer.
Upper data are Rx and lower are TX
It waits for response, it doesn't get it so it request again the value.
But the respond came and stored in the Serial buffer on arduino, so because it has some data available it returns the data from previous request, the data from current request will be returned in a feature request.
Below is the timing between last transmit byte and first received byte
As you can see its more than 100 milisec.
If you don't request the data back to back the lcd responds faster like 85 milisec
If you have to request data back too back you can increase Timeout time in Nextion Library. And to avoid getting wrong results you can add a function to clear the Serial buffer (Serial.available must return 0) .
This looks like it's not my code fault but your company's official library mr Martin or your Simulation doesn't meet the specs, I don't know if this happen on screen too and if its something new but isn't this something that you would like to know as a bug?
I have attached the measurements from logic analyzer.
I welcome a discussion around the workings of a Nextion. And in the proper forum, Free Chat is good.
I am glad you are digging in. With this you will better understand that which is Nextion.
The Itead Arduino Nextion Library is provided not as some holy grail of code, but as a sampling or code base for the Arduino users. When the Nextion is designed to be used by 1000's of MCUs in over 100 programming languages, you will note that there is not a PIC library, or an STM library. So perhaps it should be considered as a courteously that some code base was provided for the Arduinos.
The library code is included when the library is installed, and this becomes part of the over all user's code to program their Arduino MCU. And this library can then be locally edited and tailored to the user's needs by each user. But as we know, programming and technique is individual to each user as they see fit. Some user's have even written their own library code for their own needs in their own style.
But really to send an ascii string and receive a patterned result, does such really need a library to do? I wouldn't think so, and this is seen in the PIC and the STM and the ESPs. Simple logic to send the needed ascii and data terminate, simple logic to receive response and the data terminator.
So what you observed was the behavior for your specific MCU given the usage of the library. And you discovered that with an additional 50ms delay you program ran as you desired. But this isn't a Nextion bug or an Arduino bug .... it is the behaviour of your chosen MCU and the Nextion using the code base chosen by you and the Nextion firmware. But you know how to make it work, this is good.
So now you want to break open the analyzer, and this too is good - much about the Nextion behaviour will be learned as well. But have you yet discovered enough about the Nextion's firmware behaviour?
My take on the Arduino Nextion Library is one step up from as is where is, and the Arduino programmer is working on making it better in an ongoing process ... but this demand burden put on this programmer is not created by PIC users and STM users. Personally, I think the Arduino crew should show much more gratitude for this Arduino programmer for providing such code and examples, not demanding that he do their task of programming - it isn't his project. The HMI project and coding of it is the domain of the individual user who desires to create their project.
So outside of that, what do you make of this delay the Nextion is displaying? This again is not a bug, but an expected behaviour from interpreted code. I highly doubt that someone could realize a general purpose HMI code in the such a small Nextion side MCU.
No, did I get this all wrong? Are you describing the behaviour of the Debug simulator? No you couldn't be, or are you? The Nextion Editor Debug will never be a highly calibrated Nextion Emulator. No, you really were talking about physical Nextion hardware interacting with your MCU right?
I am working on simulation, I have no idea how accurate it is, I didn't know that it not accurate as you said.
The 'fault' is that on fast requesting on 9600baud (no matter what MCU or code I use) simulator respond in different time, slower than the max waiting time defined on arduino library and that caused the troubles but anyway, it solved.
The question that matter is how long is the maximum respond time on Nextion hardware on 9600 baud and after this time I can assume that my request data package was lost or corrupted in transmission and there will be no respond from the LCD because request didn't arrive to the LCD properly.
On simulator we saw the slowest respond time on this situation was ~105mil on a real LCD how is it?
And i am not talking for just this case, I could just measure it.
This time is based on how the LCD handles Serial, if it's polling a buffer until it finds a complete request, if each char causes an interrupt and checks the buffer and if the data transmitted back immediately or when the LCD is not busy doing something else. That's something that only you can answer.
Ps. Merry Xmas to you too mr Gerry
Merry Christmas to you too.
The simulator "Debug" is going to replicate the steps of the HMI design, it will replicate the RTC based on the PC RTC, but there is no replication or simulation of EEPROM or GPIO of the enhanced. On the PC there is way too many things going on to influence the result. The MCU connected to a real Nextion does not have such interferences.
But that being said, the Nextion is MOSTLY sequentially single threaded with only a few actual interrupts occurring, such as a the RTC, or the touch sensor, and maybe the GPIO (but from other experiments - the GPIO is not truly interrupted). The serial is one of those may or may not be interrupted. But what we do know is that the firmware is interpreting the HMI in a sequential manner with limited interrupt depth - it is certainly possible to overflow the stack. It is also certainly possible to overload the serial buffers which is limited to 128 bytes.
But we can see from see from the serial upload that we get nearly 10300 bytes per second, which can vary a bit on a 115200 baud connection - this is without the HMI interpreter loaded and interfering, so this is still not 11520 bytes expected from a straight serial connection. So there are other delays in processing the information, such as flash access and write timings, and if something is being displayed .. the cycles needed to display will be in that mix as well.
But you might like to realize this is a limited MCU performing all this on the Nextion side so that the main portions of the HMI design do not need to be transfer via serial, and that is the whole point of the Nextion - few MCU lines required to have a functional HMI at a price point much lower than a Samsung - this is by no means a desktop system.
The Nextion is probably looking for the properly formatted request to be completed, certainly the interpreter will sit and do nothing until it has received data termination. When sending block data, it will do nothing until the block is complete. But this still doesn't say if the STM32 UART is using hardware interrupt or bitbanging its serial, it does showcase that the interpreter will not process the sent command until it has been data terminated. And it does say that a poorly formatted command can cause the interpreters 128 byte buffer to be filled. Even with that stated, the STM32 hardware buffer is 3 words (12 bytes) of which only the first byte is used, so at any point that is limited to one byte in the chamber and max of 2 bytes in waiting.
But even with this information, it extends our understandings somewhat, but it also leads to incorrect conclusions. Such as a logic analyzer will only help shed some light to allow you to make some correlations - not deduce facts. The firmware is and will remain closed source due to legal reasons. And without the source, you do not have any means to calibrate the other side of your equation - so it remains only an observed correlation.
Now with all of that stated, the Nextion device with its limitations and its unknowns still becomes an amazing Human Machine Interface with incredible capabilities for its price point. And I have to say a lot of fun.
A little history - Gerry and I were mere mortal users when this board fell into disarray. We took over responding to user questions because we had the deeper understandings of the inner workings of the firmware and what the Nextion is capable of. We have since been tasked to keep the board clean and in order, and in the last two months, I think 95% of questions are responded to with solid and competent answers within hours and not 6 months of waiting. We have seen the board become more lively in the last 2 months since we have been tasked to do this.
The Arduino Library does needs work, granted. But the poor guy needing to do this task faces no thanks from the Arduino users, and it really irritates me that such non appreciation and a give-me,give-me self entitlement is all that is displayed towards his efforts. You will note that almost all other MCU users are self sufficient using their MCU manuals.
As for Bug Reports and Feature Requests, it is our task to filter and make recommendations on the requested features and to determine what may or may not be a firmware bug. If it is not a firmware bug, or a blatant Editor error (had a few of those), then it doesn't belong in that category.
When it comes to users code, or understanding the Nextion - you can see that we certainly help out where we can. This does not mean that we do the users work for them. And me reading their MCU manual will never help them understand their MCU and its nature ... 1000's of MCUs in 100+ programming languages, the Nextion is most definitely not limited to Arduino C. And personally, most of my code is in Pascal, Gerry - he loves his Basic.
So feel free to discuss the inner workings of the Nextion, for Gerry and I we certainly enjoy this aspect. Free Chat is the place for all things Nextion. But remember, it is neither my firmware nor my Arduino Library, I certainly might have done things a little differently if it had been.
So have fun with the Nextion, truly interesting little device.