Start a new topic

Performance decreases as displays get larger???

 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 ...

I am simply writhing 5 intergers to the screen and 7 strings.  I am not using the display to do any calculations or lifting.  Just need a simple scalable display to write to with a decent update rate.

As I mentioned before, my project works flawlessly on the 2.4 display.  What gives?   I even get the error prior to scaling the data up...


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 ...

Serial communications

- 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?

Hmh... Interesting as I did not realize that the there were that many differences in your products even though the interfaces are the same.  Ideally, I would like to disable that buffer overrun error as I would prefer to just spit data at the display as serial uart limited to 115200 would just be too cumbersome.  Is there a way to disable the display sending that error?

Patrick, do you care to inform me of the rules of communicating to these displays?  I feel like I am missing something as verifying a well formed request for everything sent seems cantankerous.
15 frames / second is acceptable.

Thank you for your replies.


Patrick, now that I search, I found where you assisted yet another poor soul having similar issues.
Reading this thread was very helpful.
I did experiment with delays and that did work, but it slows things down too damn much.

Question... do the enhanced models allow for a larger buffer?


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()

Good stuff Patrick. 
I appreciate you spelling this out.  Yea... 96 MHZ is filling the buffer pretty fast.
I did not actually use a delay command as I am aware that  it renders micorcontorllers dead in the water.
You are correct, that is stupid programming.


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

Login or Signup to post a comment