Start a new topic

Returned data

I already did a post but did not showed up on the forum. So here it is again.

Is it possible that for the newer CTP devices there will be an option so that the returned data will be something like this: -

Button example request, first send 3 bytes then the button data: -

#NX 0x65 0x00 0x23 0x01

Instead of this: -

0x65 0x00 0x23 0x01 0xFF 0xFF 0xFF

It is more easier for the microcontroller to wait for #NX rather than to look for the `0xFF 0xFF 0xFF'

For backward compatibility, a Nextion HMI: System Variable for the old style or new style can be added.

I.e.: Ret_Dat = 0      // Old style return data



Ret_Dat = 1          // New style return data

N.B. From microcontroller to Nextion display everything stays the same.


This is already implemented in print and printh commands

Refer to the Nextion Instruction Set

Although this is an advanced topic, total flexibility can be obtained in code.

Code will cost more in interpreted commands for time to render

Code will cost a bit more in number of string/attribute count used (max 65534)

Such customized returns is user domain to implement

All outbound has left Nextion standard output

Thanks for your reply. Actually I am working with the standard output but I have friends that they are put off using Nextion because they cannot synchronise the coming data.

However, if the code is not to the limit the print and printh command are useful.

Nextion has a strong series of Return Codes.

In HMI most MCU attention is needed because a touch event occurred.

For this there is a 0x65 event code.

This bound to a function for that event is very powerful indeed.

See the IteadLib Arduino Nextion Library source as a guide.

But the bigger issue is programming approach and skill.

- we learn differently, adopt various habits in approaching code.

Code is more like art on a blank canvas.

- all approaches that accomplish the task is deemed success

  but there are near unlimited approaches.

For me, I like to do things my own way

 - but going with a standard approach enables standard foundation

   and discussions about such are easiest when both sides understand

   the same/similar approach - hence support for an approach.

Nextion as with most Microprocessors are sequential programming

 - single threaded, single core, and sequentially processed

 - this makes it actually easier as only one thing can be done at a time.

 - easy to debug to see what is doing what and when.

I'll say most issues in synchronising has to do with basic use of debugging

tools available at hand (such as the Serial.print command), or if need be

a $10 logic analyzer.  Ignoring available tools leads to guessing, and it is

within guessing that assumptions are made .. and to assume, well ...

When a 0x65 return comes in .. it is a fixed length return.

When a 0x66 return comes in ... it too is a fixed length return

 - the exception is string data

   but a bit of code can send via print the length before this string data.

Most of coding is a learning process to fine tune each artistic flare.

But I have to be serious, most complaints is an inability to code

  - serial is the easiest of protocols, text commands - human readable

  - learning to code well, - this is beyond the scope of Nextion


 I couldn’t agree more. I have a 3.5" RTP and I am very happy using it. I show the Nextion to my friends and also show them my programming technique.

As always thanks for your detailed reply.

I have a few full code example tutorials on the Forum

Although they are mostly fun and games,

  they showcase some techniques that are useful

Just search for Nextion Logic in forum Search Bar

  - Piano, Mastermind, Tilt Box, Yahtzee, TicTacToe

Login or Signup to post a comment