Please refer to the Format of Device Return Data Tables in Nextion Instruction Set
There are varied responses based on setting of bkcmd (power on default of 2)
- See #15 bkcmd in System Variables List
Running HMI in Debug Simulator will for the most part also simulate returns
- (excluding eeprom, gpio functions, but very few others)
sending cirs in Instruction Input Area will also generate Nextion Simulator Return Data
0x71 is numeric Return for commands as
where numeric data is being requested to be sent
A numeric assignment is not such a one.
0x01 success or code for why failed is expected with command as
Debug Simulator is fairly telling of Nextion responses
I was looking at that also. To parse return values is a pain. It would have been nice if the return values were in the escape area of the alphabet and not valid ASCII character.
for example: get object.txt return 0x70 which is the letter p. get object.val returns 0x71 which is a q.
So if your data has those letters in it you need to do some extra checking.
Look, there is a simple means to working with Nextion Return Codes.
With the exception of 0x70 string data, they are all fixed length.
if 0x71(q) then you know there is 0x71 followed by 4 bytes and verify the three after this is 0xFF
- you have an easy means to verify valid over any line noise / interference
if 0x01 then you know this return is only 4 bytes total, verify next three are 0xFF
Want a pain, TFT driver start up sequences, or SPI flash command sequences.
When your datasheet is above 1700 pages, now you have pain,
Nextion is very very few times that fix length isn't known by leading byte.
Waveform addt, eeprom, gpio exceptions
I am saying Debug Simulator quickly confirms most questions.
Yes, I am here so often, and yes, with an answer often within hours
- and honestly, too many times Debug can
- authoritatively provide answer in seconds, compared to hours.
- such command in Instruction Input Area as a test is quicker than posting
So I am NOT saying just experiment, it is your means to debug an issue.
- but it isn't going to spit out anything that isn't already in the Tables.
There is little to expand on what is not said in the Return Code Tables.
Unless it is
- an eeprom rept response
- user specific print/printh response
- upload protocol
The Nextion will not return anything outside the Return Code Tables.
System variable bkcmd sets what you get from 0x00 to 0x23
bkcmd=0, no debug type returns, so 0x00 to 0x23 don't come.
bkcmd=1, each successful command sends 0x01 0xFF 0xFF 0xFF - all else not.
bkcmd=2 (default) 0x01 is NOT sent, only failure sends 0x02 to 0x23 depending on reason
bkcmd=3 0x01 if success else 0x02 to 0x23 depending on failure reason.
Sure, with print/printh and bkcmd=0 you can completely define custom protocol - did it.
Alternatively, you can get a logic analyzer, I love mine
- takes more time to clip the hooks on - so unless I need exact timings - Debug is so easy.
How to expand
If I use command get t0.txt I am expecting string data
0x70 (one byte for each char) ... 0xFF 0xFF 0xFF terminated
or I get a 0x02 to 0x23 failure depending on reason of failure
If I use command get n0.val I am expecting numeric data
0x71 0x01 0x02 0x03 0x04 0xFF 0xFF 0xFF little endian
or I get a 0x23 to 0x23 failure depending on reason of failure
When should we expect a 0x23 failure code?
when component name is longer than 29 chars
14 max for pagename + "." + 14 max for component .objname
All of this is Nextion Instruction Set depending on system bkcmd setting
But that is clearly stated in #15 of the System Variables.
... of the Nextion Instruction Set
The explanation is also clearly printed above each Table
... in the Nextion Instruction Set.
No issues. No one retains total on first pass through - of any document.
Each time through the Instruction Set, you absorb a bit more.
- but mostly only what is either immediately relevant (for a problem) or interesting (for a possibility)
- the rest is always information overload, and needs yet another pass through =)
Yes, I looked at the documentation several times and missed that to send a command you need to add three 0xff to the end of it and not just send a carriage return like you do in debug mode. Once I spotted that I was good to go.
In most serial code the program is looking one character at a time and then responding or jumping to a routine based on that one character. Having to receive several characters and save them so that it can look back to see what it should have processed is a little bit of a pain. But that's what coding is all about.