I think that I currently own all of the Nextion basic displays and have created a successful project around the basic 2.4" display. Of course I wish to scale that all the way up the chain to the 7" display.
One hang up is that Nextion can't handle floats... that's pretty lame, but we will work around it and write to strings... right?
So we write our floats to strings and all is good at a baud rate of 115200. Scale up to the 3.5 displays and notice that I start to get some delayed performance in my project and see data coming back into the serial buffer that I am not expecting. The data is "$ÿÿÿ" which works out to be hex "24" which is barely out of the expected range of errors with hex "23" being the highest. Go all of the way up to the 7" and notice even more errors. I decrease the baud rate (unacceptable in this case) and the errors decrease. I go into my code and 1 by 1 start commenting out things that are being sent. What I find is that writing the strings is what is causing the errors. They do update but it is slower and unacceptable in this instance. What's going on here and does anyone have a work-around? bkcmd = 0
without knowing exactly what you do, hmi, mcu-source, nothing to tell ...
fishing in the dark wont help ...
did you ever turn all your Nextions and check what mcu is working for each model?
the same, maybe different ...
STM32F030 is not GD32F ... even all Cortex core, the datasheets of each will show you the differences ...
you compare apples with bananas ...
return code &24 is just a serial buffer overflow ...
when you send out one, you should also wait for the right return code before send the next ...
just send out all without care may work, but also may not ...
for this, Nextion give return codes, you only must use them in the right way ...
- and sorry it seems, you are ignoring most of the rules.
Decent update rate?
The human eye can catch less than 15 frames/sec.
What is decent update rate?
Rules of is: TTL Serial, vanilla N81
baud rate is length of time of high / low.
baud 115200 is 1/115200 sec per bit
10 bits per character/byte sent/ received
max 11520 bytes per second possible.
setting bkcmd=0 turns OFF all status Return Data
- now of course that makes you blind to what you do.
MCU has 3 word hardware buffer
1 in the TX or RX Register
up to 2 to be added to register for next in/out
Buffer Overrun? You sent too many chars/bytes and overloaded.
Some serial communications libraries (such as Arduino) may have a software buffer
This is perhaps 64 bytes in size on an MCU, and in Desktop PC might be 4096 bytes
So in well under a fraction of a second, you exhaust the buffer and 0x24 overflow it.
At 16MHz, easy to do
At 48 MHz even easier to do
at 72 or 108MHz, much much faster.
So without any synchronization and control on the flow of data to synchronize ... yep.
Silence all, turn off alarms, ignore the irritating errors ... and you have a problem without noise
Pay attention to what these are trying to tell you? Much better, adjust code to fit rules.
Assume n0.val=213ÿÿÿ and t0.txt="23.15"ÿÿÿ
5 numbers and 7 strings
- somewhere around 5*13+7*17 = 184 bytes
184/11520 16ms or 62.6 times per sec
- but other side of transmission needs time to process too: ALWAYS
So faster MCU can indeed lead to faster failure
But hey you can disable with bkcmd=0
Or you can listen more intently and purposefully with bkcmd=3
Sorry, use of delay is stupid programming
It is a halt on this line of code until the penalty time is over.
Delay generally stops everything
- including sending and receiving and what ever interrupts
might occur during the penalty time out
PS: the delay I spoke of in the other thread was a delay in code
- and not use of the command delay()
So Nextion Return Data tells all
- trap it and respond to it
send out - wait for status
Nextion does not send status until work on Nextion side has completed
- how can it, it won't know if there is an error until final line finished
- after all, then status is sent out
As such, it is like tennis
send, receive, send, receive. send ...
In this manner you sync with Nextion
With MCU and Nextion you are now needing rules of coprocessing