Start a new topic

Global Variables and getText

 In the Chat section of this forum it was explained to me that if I kept track of the Nextion pages then I could change the the text component text from say an arduino when I am on that page. I understand this, but its combersome


I would like the feature that all 'green' items under a 'global' area setting are changeable via UART and the Nextion will show the last stored settings. This means that I can change them anywhere in my program without having to know the page postion.


I would also like , as someone else mentioned a get.text feature so I can directly access text inputs on the Nextion, rather than the random delivery of a serial input to my arduino through the print command


@ Rod


I am going to try to plant an idea for a methodology to help you design.  The thing with programming is that there are 100 ways to skin a cat, and you need to focus on one really well.  Trying six at the same time usually creates a mess and somewhere you need to call in a medic.


You have an Arduino, another segment of computing power and access to resources (this side of the serial Rx/Tx lines), and you have a display.  Key here, is to create your organization so that it is easier for you to implement your current design, and in a manner that makes it even easier to roll out another.  On the Display side, you don't really have many expansion options.  The Arduino, the skies almost the limit.


Now when you sit in front of your computer to program your Arduino, how much information are you storing into your monitor in hopes of retrieval?  And the answer is very very little, if any at all.  The information you are storing and retrieving is actually being stored elsewhere, and you are pushing updates to the Monitor to reflect the current state of your "program" or flow of events that have occurred thus far.  When I have a text component on my Monitor as a Title, I am not going into the Monitor to evaluate pixels to see what I have stored in the Title, rather I am looking in the variables or storage for what the value of Title is.  And IF and WHEN that value should ever change, then a routine sends the change to the graphics card to be updated and have the Monitor reflect the change that was made.


Now in MANY computer systems the graphics card is almost as powerful, if not more powerful than the actual CPU.  There is extremely fast Graphics RAM of vast size, with an outrageous number of data lines and an outrageous number of independent coordinated compute cores to execute the changes.  We compare that to the Nextion Display ... and our expectations need to change.


Your Nextion Display has two wires Rx/Tx and not at 4,800,000,000 (4.8 Gbps) on each line, but a mere max 115,200 bps, but possibly 9600 bps or otherwise known as your baudrate.  Because of the TTL aspect and programming of the onboard USART, you can not really multitask well when it comes to sending and receiving at the same time.  Usually, focusing on either the sending or the receiving but not both.  There isn't vast amounts of DDR-5 on the Display side, but rather just enough embedded GRAM to represent your pixels in color.  The format used to speed things up is 565 or sixteen bits (a half word at 32 bit words) where these 16 bits in binary as 01010-101101-00110, the highest 5 bits represent the amount of Red, the middle 6 bits represent the amount of green, and the lower 5 bits represent the amount of Blue to display for that pixel (65536 colors where 0 is black for no color, and 65535 is white for all color)  There is not a whole lot of cores to help do all these calculations, rather there is a mere TFT display driver usually embedded inside the display.  So if the lowered resources weren't sufficient to slow things down, there is the how you get your pixel information to the pixels ... ah, yeah 9600 baud Rx/Tx lines.  Picture them like a BRIDGE that will end up with huge grid-locking traffic jams.


Now, as far as I can see the advantage the Nextion presents is it has programmable flash storage on the opposite side of that BRIDGE.  If information happens to be stored there, it will probably be easier to send someone from the Graphics Department to the warehouse to pick things up and come back with our package than if we had to wait for it to arrive across that God forsaken grid-locked BRIDGE.  Luck for us there is a foot path across the BRIDGE that a bike courier can get back and forth, but forget the Transport Truck, there are too many cars in front of him, the driver just can't get around them.


So here it is.  If we plan ahead, we put things in the warehouse that are going to be needed.  Fonts, Pictures, and static locations of words and phrases.   We can get our bike courier to fetch a phrase on the otherside of the BRIDGE from time to time and be fairly certain he will make it back and forth with really small packages, but don't expect a bike courier to fetch an living room suite and carry it on his bike.


Your Display side warehouse isn't super huge, but every time reusable pieces are retrieved from there it sure as heck saved the amount of time it would have taken waiting for it to cross the bridge (and without loosing any pieces or parts, while we are at it some things going across the bridge do indeed go missing)  On your Arduino side of the BRIDGE, you could have a warehouse as well, but smart planning would be for lots of little items the bike courier can handle (words, values, phrases), and it is way easier to have an extra warehouse built on the Arduino side than the Display side.


Now lets address the skill level of your employees that work the warehouse.  I can tell you they SUCK at MATH.  They know how to add, sub, multiply (and divide - well, sort of).  If they can count it out on their oddly enough infinite fingers they are good.  But heed this - no fractions, decimal places, sine, cosine etc.  The boys you have in the Arduino office are college educated, but not your warehouse dudes.  If the warehouse dudes knew what Pi meant, the value is 3 - no decimal places.  60000/ 20001 is not 2.99... it is 2 - no decimal places.  So when you think about getting anything math oriented done - use the Arduino office boys - not the warehouse guys.  You have a math problem converting Fahrenheit to Celsius, have the bike courier get the Arduino office guys do the math and send the answer to the warehouse guys or they will screw it up.


The same is going to be true for anything like special characters (degree symbols in °F and °C). Use the Office Boys.  String Manipulation? Yeah, you may as well have said String Theory .... use the Office Boys and send the answer with the bike courier back.  Now you start to see why people wait for that answer to come across the BRIDGE from the Display side, catch it, process it, and send it back.


In programming, there are two methods widely used to check values.  One is called POLLING, and the other is EVENT driven.  Polling is like the kids in the back seat kicking the back of your seat while you are driving, always going "Are we there yet?", "Are we there yet?", "How about now?", "Are we there yet?".  If you were to check what happens when polling happens, it can be constant (100% CPU usage) if you didn't put special sleep commands in.  This is very POWER HUNGRY and can drain a battery real quick.  The other method is EVENT driven.  In this scenario, almost nothing gets done until - you guessed it, an EVENT happens - and that triggers something else to occur, then everything goes quiet until the next EVENT occurs - your batteries will last a long long time.


When you look at the HMI design in the Editor, you notice the Preinitialize Event, the Post Initialize Event, the Move Event (for the Slider Component), the Timer Event (for the Timer Component) and for everything except timers and variables the Press Event and Release Event.   Not much of anything is really going on until one of these EVENTS happen, then a segment of code occurs.  We wait for those segments to happen and catch the results on the Arduino side and respond when it does (or stay quiet when there are no events). 


In any touch EVENT (Press or Release), there is a Send Component ID.  That is going to have that bike courier come across with very little information, encoded to be small.

0x65 0x00 0x01 0x01 0xFF 0xFF 0xFF. 

The first byte (in hex) 0x65 is your byte-sized code word for your Arduino Office Boys to know that the courier is telling you a touch event happened across the BRIDGE.  The second byte 0x00 says it happened on Page 0.  The third byte 0x08 says it was the component with Component ID of 8, the fourth byte tells you it was a Press or Release where 0x00 is Released and 0x01 is Pressed.  This was Pressed.  And almost every single bike courier encoded message ends with 0xFF 0xFF 0xFF - this way you know it was the courier and not some scammer.


With this kind of intel coming from the warehouse side of the BRIDGE, you actually can deduce what is going on with the USER that is using your Nextion Display (after all you designed the HMI and know what all the components were on each page, and what was suppose to do what), so if you are merely snooping, or you need to get a message back to the USER, you now know what JUST happened, and you can send a message back with the bike courier to give to the USER.


Your messages being sent back aren't encoded like they are from the courier, who knows if the USER could understand such codes.  So your messages are more like

Page0.t3.txt="57°F"

And you will send those probably using a serial.write("Page0.t3.txt=\"57°F\"") style command.  Remember you have to keep things simple for the warehouse guys so they will understand.  Like change the picture on page two to your other picture from the warehouse, becomes something simple like Page2.p1.pic=2 so that the warehouse dudes know it is picture number 2 that they are suppose to swap out with whatever picture was there.


When a user presses a Button, or moves a slider it was probably important and was suppose to do something, so you want the Office Boys to pretty much know right away (check the Send Component ID so that when it happens the bike courier will be on his bike right away and be making his way across the BRIDGE)  - then deal with what just happened.


To address get.Text

Your Office Boys can change anything in YOUR HMI design that was in BOLD green.  Anything.

Page1.p0.pic=2

Page2.t3.txt="Good Morning John"

Page0.va4.val=64

And if for any reason you need the Big Boss at the Arduino Office to check up on the warehouse guys, to see that they did indeed change things the way you told the bike courier to tell them to, have the Big Boss use commands like

serial.write("get Page0.n2.val")

This will have the value of n2 on Page0 sent back via the bike courier.

Almost everything attribute of every component can be sent this way.


But for Heaven's sake, if it is something important that needs to be looked after, rely on Arduino Office guys to do the work, and then delegate it back to the warehouse guys via the courier.  Stop trying to rely on the warehouse guys like they were somehow responsible and executive type material.  They're not.


Patrick



1 person likes this

I am now reviewing all of the Feature Requests, this will take some time, patience please.

Although this wasn't a real feature request, it is now marked as reviewed.

Just wanted to state that I really appreciate that long winded explanation. Comping from a c# background trying to understand the low level commands, HEX, and serial comms, that was super helpful!

Login or Signup to post a comment