Anyone Used Nextion Displays?

geezer88

Senior Member
On a random sampling of a very few Nextion displays (although I've used about 50 so far on my projects), the accuracy of the Nextion RTC is, IIRC, of the order of +/- 3 minutes per day...
...so I use an onboard (and genuine;)) DS3232 for RTC purposes which gives me an accuracy of around 2 seconds per week.
Yikes! I've got a grandfather clock with a mechanical movement that does about 20 seconds per week. I'm glad you warned me about the rtc. I will forget about it for anything needing long term accuracy.

I've seen posts on other forums about the non-square pixels on the bigger displays. I guess x, or y scalling will fix this, but it is just one more thing to keep in your mind.

tom
 

hippy

Technical Support
Staff member
On a random sampling of a very few Nextion displays (although I've used about 50 so far on my projects), the accuracy of the Nextion RTC is, IIRC, of the order of +/- 3 minutes per day...
I would guess the on-board RTC is like PICAXE 'time' more used for rough and ready timings and timeouts, auto-cycling images and the like, than being a reliable time source.

In most products with a Nextion display I would expect there to be a controller which could keep the display's RTC more reliable or would deliver an accurate time itself as you did.

3 minutes per day is about 0.2% error, 2000ppm, which means 1ms should be accurate to 2us, 1 second accurate to 2ms, which is not too bad over a short period. It's just that even small elapsed time errors accumulate greatly over longer times as seen here.
 

geezer88

Senior Member
I am working on an altimeter project using an 18M2, an MPL3115 altimeter board from Sparkfun, and a 240x320 enhanced display from Nextion. I have used the program from rq3, on this forum, as the beginning point. My first implementation used the Nex to display results and set the local barometric pressure. That all works fine. I use serout to send the altitude to the Nex and and hserin to read two bytes that represent the barometer reading. This has been working fine. I used hserin because I could not get regular serin to work at all.

Then I got the bright idea that for some kinds of uses, it would be handy to zero the reading and go by relative changes instead of absolute. I use a flag set to 0 for relative readings, and 1 for absolute. If I hard code the flag, it all works fine, but I cannot get a flag send back to the Picaxe from the Nex. Here is the relevant section of code:



hserin b10 'first byte of new kolls (w5) Kolls is the local barometer x 100, typical is 2992
hserin b11 'second byte of new kolls

'hserin b26 'this is where I try to get the flag Note: only need one bit, may use more bits later for some other options

'pause 10


goto main_routine

end



To try to sort this out, I wrote a short program to receive data from the Nex and then printed it out on the terminal. I could receive the flag just fine if I didn't try to read both the flag and the barometer at the same time. The time to get a new reading from the altimeter is about 1/2 second, so updates from the Nex can come at anytime in the cycle.

So, My next tack will be delaying the Nex update so there is at least a cycle between inputs. I wish there was a better explanation on how the inputs for serial ports work. I think I need some continuing education. Will appreciate some of your thoughts. If you want to see all the code, it is about 100 lines. I just found the other code insertion thing, so here is the whole works, I hope this works........It didn't. So lets start with short version first.

tom
 

hippy

Technical Support
Staff member
Having -
Code:
HSerIn b10
HSerIn b11
Isn't reliable. You may end up with incorrect and out of sync data if both bytes haven't arrived before you try and read them.

A better scheme is -
Code:
b1 = 1 : Do : HSerIn w0 : Loop Until b1 = 0 : b10 = b0
b1 = 1 : Do : HSerIn w0 : Loop Until b1 = 0 : b11 = b0
 

geezer88

Senior Member
Having -
Code:
HSerIn b10
HSerIn b11
Isn't reliable. You may end up with incorrect and out of sync data if both bytes haven't arrived before you try and read them.

A better scheme is -
Code:
b1 = 1 : Do : HSerIn w0 : Loop Until b1 = 0 : b10 = b0
b1 = 1 : Do : HSerIn w0 : Loop Until b1 = 0 : b11 = b0
Thanks for the suggestion, but I still get the right answer only about 1/10 tries. The user will only try to change this word now and then, so it seems like a blocking input with a fairly small timeout might be better. You are right about it not being reliable. I've got standard inputs to burn, so I will see how serin works. I don't want to block the program from cycling too long, or it will seem unresponsive to the user. Also, the user can poke the buttons any old time, so I can't think of a way to get the input synchronized with something else going on.

I'm running the picaxe at 32M, and the nextion seems to like 9600 baud just fine, but do you think slowing the baud rate would help?

So I guess this would be the syntax: serin {timeout], b.3, t9600_32, #b10, #b11 ?? or would #w5 be better?? I believe the nextion sends out words under 65k as two bytes, little endian. Just reread the manual, it should be two bytes.

Finally, is there a serial primer aimed at the picaxe family describes the workings in more detail? I like to understand the workings of things and not just rely on cook-book rote procedures. I guess part of the problem is that serial comm has so many implementations.

Thanks again for your help, tom
 

lbenson

Senior Member
I'm surprised that hippy's code doesn't work for you. I haven't used the 18M2, but I've found a method similar to his very reliable on 08M2, 14M2, and 20M2.

If you connect your hserin pin to a ttl usb/serial module on your PC, and use puTTY or similar (or the PE5/6 terminal), does it reliably receive what you type (bearing in mind that there is only a 2-byte buffer with background serial receive on the M2s, so you might not receive all the characters if you paste in a string--typing at human speed should be fine)?

You do have your hserin set up for background receive, don't you?
 

geezer88

Senior Member
Ibenson,
If I read the manual correctly, hsersetup does not have a setting for M2 parts. Do I have that right?

All,
I have got it working now, though with:

hsersetup b9600_32, %00
hserin b10
hserin b11

It turns out the trouble seems to be with the barometer chip. I'm not sure which of my thrashing around did it, but while it worked in the beginning, it returns bogus data now. My confusion with the input routine was because a bad read on the user inputting the local barometer will drive reported altitude goofy. My mistakes are two-fold: I think I buggered the chip soldering with the power on, and then mistook the resulting bad output to be the fault of the serial input not working right.

So, to separate where the problem really was, I bypassed all the barometer code and substituted a simple function that returns a definite value for altitude given a proper input of barometric pressure. Using this surrogate allowed me to verify that the input routine is working fine. At least for several dozen tests.

Thanks all for your help and support.
tom
 

lbenson

Senior Member
If I read the manual correctly, hsersetup does not have a setting for M2 parts. Do I have that right?
Ah, I misremembered about hserin on the M2s requiring a hsersetup bit to enable the 2-byte buffer--that's there by default (thought other hsersetup features are available for the M2s).
 

geezer88

Senior Member
Today the new altimeter chip arrived. I wasted no time soldering it in the circuit, THEN turning on the power. All works fine. Now I can finish up the code that allows relative readings.
tom
 

geezer88

Senior Member
Here's a few more things I've learned using the Nextion display.

If you send an instruction it doesn't like, it will return, via the serial port, an error message. I forgot that I'd read this, and when I had some serial reading problems, I assumed my use of the Picaxe serial port was incorrect. Turns out, the Nex was sending error messages, and that was what I was confusing with what I expected. I cleaned up some writing to non existent number positions and things started working as expected.

While struggling with the serial input, I thought about other ways to skin the cat. So I used the general purpose IO on the Nex. Instead of sending a message via serial port, I simply raised a gpio pin high that I wired to an extra pin on the Picaxe. Testing the pin on the picaxe is quick, easy, and reliable. Problem avoided. Compared to hours of programming frustration, soldering one extra wire was easy.

Happy coding, tom
 

hippy

Technical Support
Staff member
I am assuming the Nextion display puts out UART TTL, idle high, serial.

One trick there might be - though I haven't tied it - is to use HSERIN to drive the internal Data Signal Modulator, have that select an inverse to output on B.3 which can be fed into a PC with RS232 polarity. That way you can have the PC or another PC or laptop show exactly what the Nextion is sending back.

You could perhaps diode mix C.3 and B.3 so it goes back up the same line to the AXE027 as SERTXD does. Untested -
Code:
                                    .-----__-----.
                                    | C.2        |
To AXE027 <-----.----------|<|------| C.3        |
AXE027 in >-----|------------------>| C.4        |
                |                   :            :
From Nextion >--|------------------>| B.2    B.5 |---.
                `---O==O---|<|---.--| B.3    B.4 |   |
                    LINK         |  `------------'   |
To monitoring PC <---------------'       18M2        |
                                                     |
To Nextion <-----------------------------------------'
This should enable that if you want to try it, again, untested -
Code:
PokeSfr $FC, %11000000 ; SFR $39C MDCON
PokeSfr $FD, %00000001 ; SFR $39D MDSRC
PokeSfr $FE, %01000000 ; SFR $39E MDCARL
PokeSfr $FF, %00000000 ; SFR $39F MDCARH
 

MartinM57

Moderator
I use two cheap eBay CP2102 UART/USB converters to "sniff" (i.e. look but don't touch) the Nextion/processor comms:
- RX on one connected to the Nextion TX line - i.e. showing what the Nextion is sending the processor
- RX on the other connected to the Nextion RX line - i.e. showing what the processor is sending the Nextion
- ground on one connected to the Nextion ground (normally no need to connect the ground on the other, but you can do if you want)

Each converter appears as a COM port on the PC.

I start two instances of the Bray's Terminal app on the PC and connect one instance to the COM port for one converter and the other instance to the COM port for the other converter.

By arranging the Bray's terminal windows side by side, I can see, at the same time, what is going to/from the Nextion from/to the processor in almost real time.

If there is a big stream of data going from say processor to Nextion in say 250mS, the Bray's terminal app can take several seconds to get it onto its window...but it doesn't usually miss (never misses?) anything, even when using 115200 baud comms between the Nextion and the processor.

(...but it isn't using a PICAXE to sniff the comms, unlike Hippy's approach above!)
 
Top