Start a new topic

PicBasic Pro Serial Communication


My current setup:

LCD: NX4832T035

Nextion Editor: v0.32

PIC: 18F4620

My layout:

Number component (n0), val=9

Button component (b0), Touch Press Event: n0.val=5

Debug: Works fine, Simulator Data on press: 0x65 0x00 0x01 0x01 0xff 0xff 0xff

I am trying to send a command from PIC to Nextion through serial port to change something on display.

To confirm that I'm using the correct ports, I tried below code with the printer which is using the same pins and it is working fine.


HSEROUT ["printer testing",13,10]

So far I've tried:

     hserout ["n0.val=2"]

     hserout ["0xff"]

     hserout ["0xff"]

     hserout ["0xff"]

     hserout ["n0.val=2 0xff 0xff 0xff"]

     Serout2 portc.7,84,["n0.val=2"]

     Serout2 portc.6,84,["n0.val=2"]

Do you have any recommendations for me?

If so, you send the two characters go through format. (Hex: 0x32 or Bin: 00110010)
Error type.
Try to be sent to a numerical value. ( Hex: 0x02 or Bin: 00000010 )


 In the sample code appears (the marked lines)

float getValue;
int value;
float oldvalue;

void setup() {

void loop() {
  getValue = analogRead(A0);
  if (getValue==oldvalue)
 { oldvalue=getValue;
  Serial.print("j0.val=");     <----------------------------
  Serial.print(value);        <----------------------------



1 person likes this
there is a major bug inside the Nextion protocol description
1. The instruction is end with three bytes "0xff 0xff 0xff"

is definitely wrong. Correct is
1. The instruction start and end with three bytes "0xff 0xff 0xff"

When you send
b0.txt="abc" & chr(0xff,0xff,0xff)
it won't work

When you send instead
chr(0xff,0xff,0xff) & b0.txt="abc" & chr(0xff,0xff,0xff)
it works as expected

The chr(0xff,0xff,0xff) must be send before AND after EVERY given command !!!!!



1 person likes this
Rikaine, did you already managed to fix this issue? I'm facing the same problems as you do with a slightly different PIC (18F2523).


For your information, I finally have it working. The comment of Gerhard Kropf is incorrect, you don't have to send 0xff 0xff 0xff in front of the data you are sending.
In the following link you can see my findings: Sending data to Nextion



frankly speaking, you are wrong ... :-)

Finally, you "got" it to work, but NOT because your code works, only because of some special conditions and behave of the Firmware ... let me explain.

First do following ...

- Power Off your display, and Power ON it again
- Now send exactly ONE time your "working" code
- And you will see it WONT work
- Now send the same again exactly one time
- And NOW the display shows your data

What happens, and why did it NOT display first time?
The Nextion Firmware has no timeout method implemented, means, you can send data whenever you like, in one block, in different blocks with big delays between, the Nextion firmware dont care about.
- You turn on the Nextion, its RX buffer is empty.
- Now you send  b0.val=123 chr(0xff,0xff,0xff)
- nothing happens
- BUT in the RX buffer is now ONE time a chr(0xff,0xff,0xff)
- and when you send again b0.val=123 chr(0xff,0xff,0xff)
- the Nextion just adds this to its RX buffer
- now the buffer contains from 2 transmissions

b0.val=123 chr(0xff,0xff,0xff) b0.val=456 chr(0xff,0xff,0xff)

And so, the firmware finds a valid chr(0xff,0xff,0xff) b0.val=456 chr(0xff,0xff,0xff) and displays it correctly. BUT it is the sec. value and not the first

Honestly, this is NOT the exact explanation, because when you

- turn off display
- then send
- b0.val=1 chr(0xff,0xff,0xff)
-b0.val=2 chr(0xff,0xff,0xff)
-b0.val=3 chr(0xff,0xff,0xff)
-b0.val=4 chr(0xff,0xff,0xff)
-b0.val=5 chr(0xff,0xff,0xff)

you can see 2,3,4,5 instead of 2,4 (as it should be with above explanation). Anyway, the 1 is always missing after power on.
So the save way to display ALWAYS correctly EXACTLY what you send out is, put a leading and trailing chr(0xff,0xff,0xff) around your data and commands, and all works as expected. If there is one chr(0xff,0xff,0xff) too much somewhere, it wont matter, the Nextion just does nothing about. But without them, you will have conditions, where data are definitely lost ...






I re-checked and indeed, you are right. Sorry for that. Apparently the display should be initialized by sending 3x 0xff to it once powered. Then you can send the value and end it by sending 3x 0xff. It seems not to be necessary to sent it each time.

Hi Bas,

the initialisation after power on CAN be the reason. But I am not really sure about.
Other points are
- you never know when the display is reset, you also can reset by accident
- power failure
- display and remote mcu use separate power supply
- corrupted transmission
- your remote mcu does NOT mandantory know, when the connected display will reboot
- ...

means, the display can restart without your knowledge, and then commands with only trailing chr(0xff,0xff,0xff) just wont work anymore ...

So, the save way for any situation is leading AND trailing chr(0xff,0xff,0xff) ... the more on protocol overhead is the price for "working under all circumstances"

Best regards



I agree that the save way is to send the extra instructions each time. On the other hand, it is not difficult to implement a initialization procedure in the uC.
I think it also depends on your application. In my current application the data to the Nextion will be updated every 2 to 5 seconds. And it is not really a problem if occasionally some data is missed.

I haven't tried reading data from the display though. If I miss updates made by the user on the Nextion then that would be a bit more problematic. So, yes we might need to chose the save way.


 Point is, the remote instance wont get any automatic feedback from the display in case of a reboot.

Means, you surely can implement an initialization routine inside your code, but you dont know when you must send it. At power on is only one out of many other possibilities ...

So, you either can

- add on a hprint command on page0 at startup to send out a message everytime the display boots. But remember, this is also send out everytime the page is displayed. So, thats not really 100% a boot-indicator ... and the remote instance must handle this message ...

- remote instance and display use same power supply. Remote instance initialize display once at power on. That may work on embedded independent devices, but also not 100% save . The display can also be reset independent of the remote instance

so, instead of managing different code libraries, based on the final project, it is more easy to

- Just initialize with every command (leading ff,ff,ff) and it just works ...

Even with 9600 Baud, the 3 Bytes more is not that much to care about ...



I checked

Gerhard : Itead ---> 1:0

truly be the beginning (FF FF FF)



Login or Signup to post a comment