Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

puzzled by output of ReceiveMessages #34

Open
RootlessAgrarian opened this issue Jan 30, 2018 · 1 comment
Open

puzzled by output of ReceiveMessages #34

RootlessAgrarian opened this issue Jan 30, 2018 · 1 comment

Comments

@RootlessAgrarian
Copy link

Something is puzzling me about the output from this demo sketch. I have got some push buttons working on my Nextion, and am reading the serial port with a Uno successfully. I see this kind of output in my Monitor:

65 0 8 0 ffff ffff ffff
65 0 8 1 0 0 0 ffff ffff ffff
65 0 8 0 ffff ffff ffff
65 0 8 0 0 0 0 ffff ffff ffff

So far so good -- an on/off button id 8 on page 0 is pressed and released, and on the release event I send its id and also (in user code) package up a data message to send its state (selected); I press it again, and on release I get the release message again and my Nextion user code sends a further message with its state (deselected) and it's all fine. Except for those trailing EOM bytes!

The ITEAD doco says that the EOM marker is three bytes: 0xFF 0xFF 0xFF.

Yet the monitor is showing 6 bytes: FFFF FFFF FFFF.

I did take a look at the "listen" function and I don't see where those FFs are getting duplicated, yet when I print out my messages from the Nextion (user code) ending in FF FF FF, what I see in the log is FFFF FFFF FFFF. It's quite puzzling. I must be missing something obvious...!

@GeertvanWissen
Copy link

I think this had to do with the way "cmd" is stored in the Nextion::listen method. It is declared as an String object, but the individual characters are handled like the string is a null terminated char[] array. I'm not sure if this is possible like this, but it looks like we end up with a uint16_t number from the one byte that was received. I noticed that this 'bug' also messed up the coordinates when receiving data from "sendxy"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants