I think that what you present is expected from your script
- when executed as written, what you are seeing is what I would expect
What is the question?
Reverse Engineer your Question from the Nextion Instruction Set
What is the 0x65 Return Data Format?
According to your HMI and your script you present
page0.b8 release - should indeed produce output b'e\x00\t\x00'
page0.b9 release - should indeed produce output b'e\x00\n\x00'
The only error I see is your claim page0.b9 release
0x65 0x00 0x09 0x00 0xFF 0xFF 0xFF
was responsible for both outputs
- perhaps a typo or copy you forgot to edit when making your post.
But what is the Question?
Or is the post merely a statement of confusion with no question
I am confused about the feedback from serial or socket read output, the Nextion Debugger/Simulator say me when i press the button of component ID9 is '0x65 0x00 0x09 0x00 0xff 0xff 0xff'.
But when i read out the serial or socket i get 'b'e\x00\t\x00\xff\xff\xff''??
My Question is, from where is the 'e\' and why is change x09\ to t\?
But maybe is better i will ask them in a Python forum.
Br,
Marc
a byte is eight bits, a char is generally eight bits (but not always)
the b' and trailing ' your script was told to put there.
- this is not part of the output but you added it.
so what is value of e, in hexadecimal 0x65, or decimal 101, or binary 01100101
the \ is not part of e - e\ but is beginning part of the next non-printable char
\t a horizontal tab, hexadecimal 0x09, decimal 9, binary 00010001
\x00 is hexadecimal 0x00 (\x00 ... 0x00 ... \x00) a null char binary 00000000
\xff is also hexadecimal 0xFF, decimal 255, binary 11111111
So when you make your own scripts - you will know what you put in
but when you use other people scripts ... maybe less so that you know.
if you don't understand Python, there are other languages, such as Basic, C, or C++
but you will indeed need to learn whichever one you choose.
@Patrick Martin
It's 100% my script, but i am learning sorry about that i am not perfect as you...
I know what is a bit and byte ;-)
I am just read and write out the serial buffer. Not more!
But i ask me why is just the read out change x09 to t? Ever other byte read out will be ok!
But anyway i think that is the wrong forum.
Regards,
Marc
Perhaps look for how your PySerial or Python can modify
( Python is not my language )
But most languages have modifiers to convert to different formats
such as Arduino C++, a Serial.print has DEC, BIN and HEX modifiers
print(read_ser,HEX); or print(read_ser,DEC);
in pascal,
format('%.2x',[read_ser]); for hexadecimal or format('%d',[read_ser]) decimal
You will generally need some modifiers for ranges that are not typical ASCII
chars 0x00 to 0x1F, 0x7F are not printable and chars 0x80 to 0xFF may be undefined.
This may give an idea of what to ask for at python forum.
I figure you are learning,
so don't bother taking an offense, I presented facts.
Reread in monotone, you will see I presented facts.
Your MCU will only do exactly as it was instructed to do
- the HMI is programmed purposefully, there is no fail
- the script will also only do as it was told to do, exactly as told.
So, when learning
- the output is exact, there is no error in HMI or in script, exact.
- your code compiles and it runs, so output is exact from commands.
- observe what happened, it is purposeful.
So the why did it do that?
- this goes exactly back to every command line by line
obviously, one of them caused it
- nail down which you suspect is responsible for, read more on it.
- when using someone else's library (such as PySerial - not yours)
you may indeed need to examine the code for the library to see why
is rarely ever what the library's programmers thought should happen
(such is why there are so many libraries to do the same thing)
Result not exactly as you might have wished for?
- define what you wish it would be
- now look for what command will produce that wished for result
When you know what is a bit, and what is a byte (no offense)
- then what is a char?
- because a char is not truly byte based - it is interpreted from one or many bytes
- it is regional, encoded, part of some set ... which set of which encoding?
ASCII, GB2312, iso-8859-5, UTF-8 UTF-16, Unicode, EBCDIC, other?
Yet your MCU is integer based, not string based.
char for one MCU in one region of the world is different in another region
but you MCU really knows what a byte, word, long is
char is forced upon it, and not very well I might add.
therefore, you have to look to what char to byte and byte to char
actually means to your MCU in your region on your MCU
How does you compiler, your programming language your MCU handle this
- and therein will your answer will lay.
@Patrick
A lot of text but you can just say me what is wrong in my script?
One simple answer?
I think you can't!
Best Regards,
Marc
There is nothing wrong with your script.
Depending on your systems encoding for dealing with chars
- these details are not stated
- I will take a stab at Python is usually used on Unix based systems
so maybe the underlying encoding maybe UTF-8
or not, it is only a guess to an unknown detail.
But as stated before,
0x00 to 0x1F, 0x7F and possibly all of 0x80 to 0xFF is probably non-printable.
this means that your encoding doesn't have a font matrix to represent that byte value
So 0x65 can be represented - and your screen draws an e
0xFF can not be drawn, no or likely no representation in your font
so python translates it rather than printing an empty character
it translated it to \xff so that you could atleast see it was 0xFF, or a 255 came in.
Likewise in almost every encoding 0x00 or the NULL transmission character
it too is a non-printable character, so python translates it to \x00 so you can see.
\t as stated before is the horizontal tab, dec 9, again not printable
\n is a line feed character to cause a cursor or printer to move 1 line down but stay in column
it is also within the non-printable class of characters - but at least something was seen.
\x07 or decimal 7 also unprintable but causes a speaker to make a "ding" sound
So, the programmers of PySerial and Python decided this is the way they will
represent these characters so that you see something.
You may find it more appealing to read from serial typecast to bytes and then hex
But I highly doubt a single line can explain character handling (byte to char, char to byte)
especially since there are too many standards, and no common standard
And if you are learning ... I doubt even more one line could accomplish.
Perhaps could have done in one line.
one simple answer ...
the script is formal correct ...
the error is in front of the computer ...
lack of understanding your used toolset ...
The error is in front of the computer ...
I need convert every serial output to hex, simple and easy :-)
import serial ser = serial.serial_for_url('socket://10.0.2.234:23', timeout=5) def read(): out_hex = '' ff = 0 while ser.inWaiting(): read_ser = ser.read() if read_ser == b'\xff': ff += 1 if ff == 3: print('GET cmd: ', out_hex) ff = 0 out_hex = '' else: out_hex += "0x{:02x} ".format(ord(read_ser)) while True: read()
The Output now:
GET cmd: 0x65 0x03 0x09 0x00
Marc Peter
Hi,
I have write a Test Scripts in Python for read Serial.
The script is very easy but give me wrong output:
Example (Simulator return Data):
0x65 0x00 0x09 0x00 0xff 0xff 0xff
The Script read this one:
b'e\x00\t\x00'
Simulator:
0x65 0x00 0x09 0x00 0xff 0xff 0xff
Script:
b'e\x00\n\x00'
Com4, The Display is atached over Sparkfun serial to usb adapter
Socket: Same fail output with ESP-link over ip