Honda Insight Forum banner
61 - 80 of 102 Posts

Engine-Off-Coast
Joined
2,378 Posts
Writing data to the nextion is slow, and I can only send 1 command at a time. Right now I've got it sending commands every 250ms. I think that time can be reduced, but changing bar graph colour would make an SoC change take 3 commands instead of 1.
 
  • Like
Reactions: Arbus

Engine-Off-Coast
Joined
2,378 Posts
If you are going to use touchscreen inputs... it is sensitive to the polling interval so you can end up hanging the screen if you don't poll it often enough etc... the stock Nextion library is very prone to this.

I ended up using EasyNextion which handles alittle of the work of getting the thing to work reliably .... you put a bit of code in each button and it triggers predefined functions eg trigger0() etc... when you press a button that is printing the correct bytes to UART. The other nextion libraries are all nice and use objects and such but they this is the only library I got working reliably.

You can put
Code:
bauds=38400
In the Program.s to set the baud rate to a permanently higher or lower rate... I have tested higher rates and they can only really be done over short cables, 38400 is a good compromise speed. I also changed all the names of my screen objects to single letters... so I could maximize sceen update speed and minimze serial errors.

I implemented a progress guage for the project I did (it was QT tester for an industrial board).... it also had an encoder my board was using and displaying the output to a graph with, something like add 0,23,0,data here to add plot points... I can dig up the code if curious.
# Touch Screen Inputs:
Yes we will need to use those

# Baud Rate:
LiBCM, for its own purposes, needs all the memory and storage it can get so the code has to be compact, so I'm not importing a nextion library. Do you know a way to set Nextion baud rate without the library? Note: The cable is probably about 5 feet long. IDK if that's too long.

# Plot data:
I would be happy to see the code if you have it!
 

Registered
Joined
59 Posts
# Touch Screen Inputs:
Yes we will need to use those

# Baud Rate:
LiBCM, for its own purposes, needs all the memory and storage it can get so the code has to be compact, so I'm not importing a nextion library. Do you know a way to set Nextion baud rate without the library? Note: The cable is probably about 5 feet long. IDK if that's too long.

# Plot data:
I would be happy to see the code if you have it!
You set the baud rate from the HMI protect Program.s ... or from the first screen etc.. baud=xxxx sets it temporarily and bauds=xxx writes it to the flash of the screen you only have to run this once and it persists. The MCU controlling the screen isn't involved at all, just drop that line into the code behind of a screen etc... you could even have a screen that lets you set the baud rate with buttons without any additional code on the MC. Also be aware you can change screens without the MCU being involved.

5ft ethernt cable in my experience is fine up to around 38400 or so... with an occasional bit error. But thats not a big deal if you are constantly refreshing the data on the screen. My wiring was a little sketchy also with a bit more solid wiring it is probably more reliable.

Honestly I'll probably have to just write a demo for the graph... since I can't share the work related code. Also I'd suggest using the EasyNextion library anyway... there isn't much too it so its not like its a code hit, I was using it on an Atmega32u4.... the text is a far bigger hit than the library. Wherever you can hardcode the text into the screen and just display values with the HMI to avoid wasting serial bandwidth and flash space for text. You can always write the easy nextion code out of the picture later anyway if you find the need.... I'd at least look at how it works since in my experience it was the least likely to deadlock my MCU in the event loop.
 

Registered
Joined
59 Posts
Writing data to the nextion is slow, and I can only send 1 command at a time. Right now I've got it sending commands every 250ms. I think that time can be reduced, but changing bar graph colour would make an SoC change take 3 commands instead of 1.
Not sure why its that slow for you... you should be able to fill up your serial buffer every 100ms or so, at least just be careful not to overrun it. Default serial buffer is 64 bytes, you actually can increase it though... which I would recommend 128 or 256 is much more comfortable. Also I believe I said this before but use single character names for objects and variables in the HMI that you will reference from the MCU... since the whole variable name has to get sent every time you reference it over the serial port.

If you are running at 9600 baud you... just have to stop doing that as its 1ms per character approximately. 115200 baud would be idea.. with only approx 80us per character. https://lucidar.me/en/serialib/most-used-baud-rates-table/

Also you can do most of the graphics in the screen script.. and just send a variable update to the HMI and it will redraw it all by itself. Just create a variable and use that from a program.s to update your graphics (the screen script commands are basically the same as over the serial port).

Also you can test all of that without reprogramming the MCU ... use the debugger for the HMI and set it so you are emulating the MCU serial port and just type out what you want to send etc... to test.

Also what MCU is used? I have experience mostly with Atmega32u4 and Pic32MX270, the latter is incredibly faster than a Atmega even at only 40Mhz... the Atmega might only be better if you require 5V IO and also better at tight IO event loops since the PIC32 may have variable execution time due to caching.
 

Linsight Designer
Joined
3,904 Posts
Discussion Starter · #67 ·
Not sure why its that slow for you... you should be able to fill up your serial buffer every 100ms or so, at least just be careful not to overrun it.
LiBCM's tick rate is 10 ms.
Overflowing the buffer isn't possible; if you write more than is available in the buffer, the code just hangs until room is available... this is equally as bad, though, as it causes LiBCM to miss timing, which causes a P1648.

Default serial buffer is 64 bytes, you actually can increase it though... which I would recommend 128 or 256 is much more comfortable.
This used to be really easy to do in the Arduino environment. However, it is much more difficult now because Arduino no longer allows you to #undefine core library constants. Therefore, to change the default 64 B value, you end up having to bail on Arduino's serial driver entirely. I haven't wanted to to commit to this yet.

If I'm wrong, please let me know how to change the default value without bailing on the core Arduino serial driver.

Also I believe I said this before but use single character names for objects and variables in the HMI that you will reference from the MCU... since the whole variable name has to get sent every time you reference it over the serial port.
Absolutely.

If you are running at 9600 baud you... just have to stop doing that as its 1ms per character approximately. 115200 baud would be idea.. with only approx 80us per character. https://lucidar.me/en/serialib/most-used-baud-rates-table/
I agree 9600 is quite slow for graphics display. I'm not sure if we'll make it to 115200 given the cable length, but certainly we'll eventually want to run as fast as possible.

Also you can do most of the graphics in the screen script.. and just send a variable update to the HMI and it will redraw it all by itself. Just create a variable and use that from a program.s to update your graphics (the screen script commands are basically the same as over the serial port).
Also you can test all of that without reprogramming the MCU ... use the debugger for the HMI and set it so you are emulating the MCU serial port and just type out what you want to send etc... to test.
This is certainly an easy way to debug.

Also what MCU is used? I have experience mostly with Atmega32u4 and Pic32MX270, the latter is incredibly faster than a Atmega even at only 40Mhz... the Atmega might only be better if you require 5V IO and also better at tight IO event loops since the PIC32 may have variable execution time due to caching.
MEGA2560 on an Arduino MEGA clone. Reasons:
-in stock
-cheap
-QTY4 hardware serial
-lots of IO
-easy customer programming experience (compared to any other MCU)
-5V IO
 

Linsight Designer
Joined
3,904 Posts
Discussion Starter · #68 ·
LiBCM, for its own purposes, needs all the memory and storage it can get so the code has to be compact, so I'm not importing a nextion library. Do you know a way to set Nextion baud rate without the library? Note: The cable is probably about 5 feet long. IDK if that's too long.
Right now LiBCM uses 12% of program storage space. I had intended to use quite a bit of that memory for LiDisplay, so please use as much as you need.

RAM is more coveted, but again, please use as much as you need for LiDisplay. Right now LiBCM uses 25%.
 

Registered
Joined
59 Posts
This used to be really easy to do in the Arduino environment. However, it is much more difficult now because Arduino no longer allows you to #undefine core library constants. Therefore, to change the default 64 B value, you end up having to bail on Arduino's serial driver entirely. I haven't wanted to to commit to this yet.

If I'm wrong, please let me know how to change the default value without bailing on the core Arduino serial driver.
No, you are quite right I think you have to basically create a copy and edit it to your liking... https://www.hobbytronics.co.uk/arduino-serial-buffer-size

I don't think there is a way around having to do that.... but you do what you have to to make it work. I think non of my recent code does this though, as I was able to shorten the serial commands enough, and increased the UART rate enough for it to not be a problem.

Also I use Protothreads Protothreads - Lightweight, Stackless Threads in C for everything I write as its very simple and lightweight.
 

Premium Member
Joined
2,865 Posts
I'm so jealous. I defend the 4x20 to the death, but I MIGHT be willing to replace it with this...
 
  • Like
Reactions: Natalya

Registered
Joined
59 Posts
Your HMI looks sharp.

I think I'd mount it vertical and put any on screen buttons the bottom. But that is just me... in any case as long as the names stay the same anyone can edit the HMI. (some of the libraries i've used reference screen objects by ID and this is super clunky if you make changes to a screen because it reorders the IDs).

Also if your connection is reliable enough you can skip rewriting data to the screen saving some valuable bandwidth.
 

Linsight Designer
Joined
3,904 Posts
Discussion Starter · #75 ·
Looking great! I'm sure we can eventually get the refresh rate much higher. I'll need to send you whatever the final cable is going to be, so we can see how fast we can transmit data using the final production cable.

By the way, in the next few days I'm going to push data up to github for the first time in a couple months... I've been really slacking on that. Not much has changed in the firmware, as it's mostly the RevD PCB and various other non-firmware things... but there are a couple firmware changes.

Once I push data, you should probably create a pull request with your code... before I start a deep dive in the firmware. That way we won't have a bunch of merge conflicts down the road.
 

Engine-Off-Coast
Joined
2,378 Posts
@cb88 Is there a byte-wise way to send commands to the Nextion in order to shorten the length of commands the Arduino is writing?

I was looking at this: Nextion LCD Touchscreen Tutorial for Arduino - Experimentos en Hardware Libre
And they came up with a byte-wise way to write from Nextion to the Arduino. I was just wondering if there's a way to do it from the Arduino to the Nextion, instead of long commands like "p0.p0.pic=18"
 

Registered
Joined
59 Posts
@cb88 Is there a byte-wise way to send commands to the Nextion in order to shorten the length of commands the Arduino is writing?

I was looking at this: Nextion LCD Touchscreen Tutorial for Arduino - Experimentos en Hardware Libre
And they came up with a byte-wise way to write from Nextion to the Arduino. I was just wondering if there's a way to do it from the Arduino to the Nextion, instead of long commands like "p0.p0.pic=18"
I believe there is not... you end up just doing the same things all the libraries do.

Just run the screen at a higher baud rate.... there are bytewise commands for writing integers I think but you still have to send the object id as a string.

I'd try 38400 as a start, just put bauds=38400 in the Progam.s file and upload, after that all communication will be at that baud rate including uploads. You may be able to go faster but if it fails you'll need to grab a stock HMI firmware and reset it by putting it on an microSD card (there are instructions on how to do this online).

The baud rate can go almost up to a megabaud (probably only works over very short cables) but the nextion buffer is only 1024 so you are still limited by that and how fast it can process it.
 

Engine-Off-Coast
Joined
2,378 Posts
The cable I have is... shall we say... crispy. ( See part of it for a second in the video above, it's a 5' USB cable connected to a USB breakout that is then poorly soldered to some dupont connectors which connect to the Nextion default connector. )

Today I tried sending Serial1.print("baud=38400"); then of course sent 0xFF 0xFF 0xFF, then waited 2000ms, Serial1.end(); Serial1.begin(38400,SERIAL_8E1); But this didn't work. I also tried 19200, which didn't work either. Nothing on the screen would update. I'm not sure if the failure was at the Nextion or the Arduino, or the cable itself.

I have however had success reducing the delay between commands to 100ms, so that's a step in the right direction.
 

Registered
Joined
59 Posts
I don't think you can run the baud or bauds command from the UART not 100% sure of that though.

Just upload the project with microsd card it will detect the project on there and flash it at boot (don't try uploading at flakey baud rates over the UART you can soft brick the HMI especially if the firmware is updated at the same time, it is possible to recover with a microsd card anyway even in that case). Realistically you don't need 100% reliable UART, you need like 99.9%.. which isn't good enough for UART uploading but you can run the UART at less stable speeds to increase refresh rate.

38400 should be 100% stable for UART uploads also even over your cable... I've ran that over worse (through 2 ethernet to terminal block adapters + and 10ft of Ethernet cable) There is a possiblity your UART is only happy at certain baud rates you might want to double check with this as a reference WormFood's AVR Baud Rate Calculator Ver. 2.1.1

If you are using an 8 or 16Mhz crystal you might even try 250k baud... there is acutally a decent chance of that working IMO. But only attempt that with baud=250000 in the Program.s file that way its easy to back out.

 

Engine-Off-Coast
Joined
2,378 Posts
Oh I've only been uploading the HMI files to the Nextion using a microSD card.
 
  • Like
Reactions: cb88
61 - 80 of 102 Posts
Top