If I want to modify the values of 10 variables with discontinuous addresses, can I send 10 instructions in succession with time intervals added in the middle or wait for the reply signal from the screen?
I was able to do it by using stone’s screen, and I think they should almost be able to do it as well.
Serial buffer is 1024 bytes, if you work at 9600 baud I think that you have non problems to modify 10 variables.
Even at higher baud rates, this should work in the “throw and forget” mode. The secret is optimizing the transmission by using very short variable names…
“theThingyPlacedOnTheSecondScreenInTheLowerRightCorner7.val=5992” eats more serial buffer than “p[2].b[7].val=5992”
Though pages and variables can’t have more than 14 characters, limiting the maximum variable name length to something around 32 chars.
This also means that with only 10 variables you shouldn’t be able to cause a buffer overflow; 100 chars per command should be enough for most things.
If you want to be absolutely sure, change bkcmd to 3. Then you’ll get an acknowledge for everything you send. If your sending code waits every time for the acknowledge, you have the guarantee that everything got received and processed correctly (Details as always in the Nextion Instruction Set).
If interested, here’s my take at such an acknowledge function. Send your command, call acknowledge() and done.
Kind regards,
Max
What if the baud rate is 115200? Is it possible to do that?
Is there a video demonstration? Change 10 variable addresses at a time at high baud rates.
Thanks for your reply, I will follow this method and test it.
Why’d you need a video demonstration? I suggest that you take the time to approach that topic scientifically and do your own tests with increasing baud rates. The own experience is normally much more convincing and satisfying than just seeing that others managed to do a thing.
Hi… I’ve not had any issue exchanging between Pi’s employing a HDMI switch. In case the Pi’s aren’t designed to yield HDMI when they boot up, you’ll have issues once you come to choose those Pi’s afterward, but you ought to be able to switch back to the initial flag I would have thought. I have a TV which in some cases comes up short to perceive an HDMI stream when turned on, but is at that point fine once a few other HDMI stream has been chosen and I have exchanged back.
After much testing when running @ higher serial speeds (921600), bkcmd=3 was the only way I could reliably avoid running over the serial buffer. The problem you’ll have without that is that various commands take a different amount of time to execute, so simply counting bytes coming by over a set amount of time isn’t really useful. You can just send data until you get a buffer full error back, but that doesn’t tell you which commands were successfully buffered. At some point, you’re left dealing with acknowledging every command.
Once I implemented that approach the speed was great and the reliability increased significantly.
2 Likes
If you use the reparse mode with crc checking and just send the data or state of the object the amount sent to the buffer should be much lower and then if you create a variable to copy the buffer to, this should help also as you can clear the buffer, I am doing this with the stand alone nextion screen.
Without any sort of acknowledgement you still don’t have a guarantee that no buffer overflow can occur. It is less likely for sure since you can define a more compact data format but it’s not impossible*. So you’d have to add that on top of the custom protocol and protocol parsing.
*well, since you are the one who designs and implements the protocol, you can modify the timings in such a way that no overflow occurs (f.ex. one update of 600bytes per second, knowing that processing takes 200ms). However, this likely doesn’t fit every usage case.
This all means much, much more work to do (remember f.ex. that you need to copy your custom parser to every single page in your Nextion application) - and the reward is rather small: coms are faster and complexity moved from the MCU side to the Nextion side. If you really need either one of those advantages there’s no way around reparse mode. But otherwise I’d strongly advise anyone to just go with the built-in instruction set and acknowledgement.
Regards,
Max
1 Like
To simplify the copying I used timers to contain blocks of code and named the timers so I can see what they do eg parse for the parsing , crcgen for the crc generator I then used them as sub programs by enabling the timer the disable it at the end . I actually found it fairly simple once I had constructed the sub’s to make changes for different pages . I also saved these sub’s as text files so I can use them in other nextion projects. As far as more work it was write the code on the external mcu or in the nextion. This is what I found hope it helps others. Note I do not write code in “C” so no prior experience, I use a basic compiler with atmel AVR’s so it should be a lot easier for those who do use “C”.
I found out that you can send multiple commands at the same time because I saw this video.
Uhm… someone sends a bunch of commands to a STONE display. How does this tell you anything about Nextion displays, their buffers and overflow risks?
But yeah, up to a certain point you can send a bunch of commands t Nextion, too - as it‘s been discussed above.
Regards,
Max
1 Like
I think they are very similar, so maybe the same functionality can be achieved?
They aim for a similar market - similar, not the same. The majority of Nextion users is unlikely to switch to STONE and vice versa.
They are different products by independent companies with different philosophies, qualities and capabilities. They don‘t adhere to any common standard in terms of development environment. So to cut a long story short, no, from the way you can communicate with a STONE display you can‘t conclude anything about Nextion. I‘d suggest to look for Nextion tutorials instead and - most important - start playing with the screen yourself.
Regards,
Max