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

geezer88

Senior Member
Here's another lesson learned using the Nextion. This one is mechanical. I cut a window in the plastic case I've used to house my altimeter. As soon as I tightened the screws finger tight, the touch response died. Loosening the screws restored operation. So the lesson is: don't pinch the touchscreen, even outside the display area. To mount it now, I've simply added spacers between the mounting holes on the Nextion main board and the plastic case to allow a small gap between case and front of display.

I wonder if a small bead of RTV (<1mm) to seal the gap would goof anything up?

tom
 

MartinM57

Moderator
Interesting. Just played with a bare Nextion and, yes, if you apply a reasonable finger pressure right at the border of the display, that seems to be taken as a "touch", which means that touching elsewhere has no effect - the first touch wins out.

We use a design that gently, but rigidly, pushes the display against the front of the case from behind, so that:
- there is no strain on the Nextion/case joint - in fact there is no joint (and it is not needed to be waterproof)
- there is a solid feel when pressing on display, as you are trying to push the Nextion against its rigid mount

(Just) RTV would probably be OK, but:
- maybe will be too "elastic" for a good touch feeling/may fail over time?
- I wouldn't like to have have to disassemble it after a long period - it may stick to the touch membrane too vigorously and detach it as you pull it apart. Well set RTV, installed correctly on clean surfaces is very tough to cut/remove in my experience.
 

geezer88

Senior Member
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.
I did do something similar when I was working out the serial input problem: I used the serial/usb converter that I use for programming the picaxe by simply unplugging it and used alligator clips to attach the input port to the serial line coming from the Nex. Opening Tinyterm or equivalent let me log what was comming to the picaxe. Seeing a bunch of stuff that was not expected got me wondering about the Nex error reports. By the way, these reports can be turned off, too. In my case, fixing the error was all I needed to do.
 

geezer88

Senior Member
Here's another bit Nex learning that may help someone simplify their design. The "advanced" Nex have 1K of EEPROM. It is easy to use with wepo and repo commands. Since it is non-volatile, I have used it in my altimeter project to save settings when powered down.

I keep thinking of features to add to my project. Next will be logging of altitudes and english/metric units. Oh yeah, barometer mode, too.

tom
 

geezer88

Senior Member
Question for You Nex users: is there a way to print out your information after a project is complete? I save my various revisions as backup, but if there was a way to view a printed version, sometimes that would be nice in lieu of firing up the nex editor to see a bit of code.

tom
 

hippy

Technical Support
Staff member
I'm not familiar with the Nextion displays or the Editor but installed the 0.58 version while at a loose end as it's a rainy day.

I couldn't see anything which produces a textual report of what's been designed, but it may be possible to decode the saved .HMI file and obtain it through that, though it doesn't seem Nextion or anyone else has documented its format.

Just a blank design seems to take up a whole 1MB but I would guess that's mostly a default 240x320 background image for the display I had selected. By adding screen widgets, program actions, one at a time, it might be possible to figure out how the file is structured, where pointers point to, how the definition blocks are structured and nested.

Two problems I found; first that the Editor always seems to throw a 'crashed' report when it is exited, and secondly it wouldn't load random .HMI files I pulled from the internet as it reported they had been created in earlier versions of the Editor.
 

johnlong

Senior Member
Hi
Too open older files you need to download the LTS version from the nextion site
this is basically the old version as there recient update changes the editor too the new one to enable
videos and the new features.
word of warning if you open one of your old files in the new editor it converts it to the new format,
which will then not open in the old version, copy before opening to avoid the issue
 

MartinM57

Moderator
As far as I know. the .hmi file encryption is proprietary to Nextion and unpublished.

The editor really could do with:
- a means of documenting/exporting a HMI design in human readable format
- a global text search across all objects in a page/project, for example finding all the uses of a local variable in a page, or uses of a global variable in the whole project - I use a kludge of renaming the variable (e.g. add an "_" at the end) doing a compilation and seeing where the errors occur. Unfortunately, you don't get all the errors at once, so it can be tortuous

I did notice that for my project:
- on the LTS editor I have a ~30MB .TFT file (max is 32MB!) that takes about 90 seconds to load into an Enhanced Nextion device via the SD Card
- on the 0.58 editor the .TFT file for the same HMI file is ~9MB and takes less than 10 seconds to load into an Intelligent Nextion device via the SD Card
...due to, I think:
- the bitmap images in the .HMI file now being compressed into the .TFT file and possibly being uncompressed on the fly during the run time
- the increased processor speed in the Intelligent device, taking data from the SD Card much faster

I've never, thankfully, had a "crash" report on exiting either versions of the editor.
 

geezer88

Senior Member
As far as I know. the .hmi file encryption is proprietary to Nextion and unpublished.

The editor really could do with:
- a means of documenting/exporting a HMI design in human readable format
- a global text search across all objects in a page/project, for example finding all the uses of a local variable in a page, or uses of a global variable in the whole project - I use a kludge of renaming the variable (e.g. add an "_" at the end) doing a compilation and seeing where the errors occur. Unfortunately, you don't get all the errors at once, so it can be tortuous

I did notice that for my project:
- on the LTS editor I have a ~30MB .TFT file (max is 32MB!) that takes about 90 seconds to load into an Enhanced Nextion device via the SD Card
- on the 0.58 editor the .TFT file for the same HMI file is ~9MB and takes less than 10 seconds to load into an Intelligent Nextion device via the SD Card
...due to, I think:
- the bitmap images in the .HMI file now being compressed into the .TFT file and possibly being uncompressed on the fly during the run time
- the increased processor speed in the Intelligent device, taking data from the SD Card much faster

I've never, thankfully, had a "crash" report on exiting either versions of the editor.
 

geezer88

Senior Member
I have had a number of the "crashes" after downloading. Reloading always seems to clear it up, though. My theory is that I have been too rapid removing the SD after powering down?

tom
 
Top