0xFF character in StringReceive = strange Bug

[Rudi]

hi mm stuff,

i have play many time ( month!! ) in this and each projekt i started, i must make a pause if runs wrong, because i do not know, what is happend with receive data. i have not registrated that allways 0xFF makes fail with my "starter projekt's in midi, usb serial, and so on.. "...

until this weekend, i have not know, what this 0xFF character is doing if this in a receive string, .. but now i have catch this strange strange strange 0xFF ghost
here a example as simple RS232 receiveString procedure, i can show this strange strange strange "bug" ( or future ) this dedecise you
..

ok what i done:

i have make a simple flowchart for demonstrate this strange "bug"

i have set variable
FFbug[5] init with 0xFF 0xFF 0x03 0xFF 0xFF
rsUART[20] init with rsUART = ""
and then with
rsUART[0] = 0x61
rsUART[1] = 0x62
rsUART[2] = 0x63
rsUART[3] = 0x64
rsUART[4] = 0x65
( so the rest characters of the variables must be 0x00 ...0x00 )

rbUART[16] // this was a test with bytes..



start:
for controll : this variable will send by rs232
a) send as characters
b) send as string

1. procedure: ReceiveStrings [5]
now a receive string procedure will wait 255 for 5 characters and will store this in the FFbug variable
and then response
a) send as characters
b) send as string

then a
2. procedure: ReceiveStrings [20]
now a receive string procedure will wait 255 for 20 characters and will store this in the rsUART[20] variable
and then response
a) send as characters
b) send as string


now what happend normal:
1. proc wait for input:
i send HELLO
the 1. proc will response
HELLO
HELLO

2. proc wait for input:
i send HELLO GREAT WORLD
the 2. proc will response
HELLO GREAT WORLD
HELLO GREAT WORLD


ok all fine.
but now we test:

reset mikrocontroller
1. proc
send hex code: 0xFF 0x01 0xFF

the first 0xFF will finnished the 1. proc that waits for 5 characters!
and changed the first character of stored variable FFbug to 0x00
then the second send character 0x01 will be a "input for next proc
and because 0xFF was send as third character this wil shot up the
2. proc that was waiting for 20 characters!
and what happend with the variable?
this was changed in first character with the 0x01 character as input
and the 0xFF was changed the second character to 0x00.
the rest of stored variable was untouched.

i am verry interested in you statement of this 0xFF strange bug
this 0xFF i have found because i have a play with AES256
and allways if i send a crypted data with a "0xFF" the things goes crazzy

ok - now i can laugh - but i have many time waste in this, because i have not registrated that allays 0xFF make a fail with string datas...
can you reproduce this ?

will be happy if you say " strange bug "

i know :

a) 0x00 in Strings cut the string and fill out the rest with 0x00


but this i have not know until this weekend!
now i know too:
b) 0xFF in Receive String shot up the receive string proc and will be a 0x00 input character


bug or future ?




best wishes!

rudi


btw:
in this flowchart i have a disabled icon for you, if you want to give a "start" by enter press..
so please do only one character for start, if you enable this icon at start,
if not, so connect the terminal and reset the mikrocontroller so you see all from start.

[Rudi]

add pics and flowchart here
because only 3 attached files allowed.

what is you thinking?
..
..
..

[Benj]

Hello Rudi,

rsUART[20] init with rsUART = ""
and then with
rsUART[0] = 0x61
rsUART[1] = 0x62
rsUART[2] = 0x63
rsUART[3] = 0x64
rsUART[4] = 0x65
( so the rest characters of the variables must be 0x00 ...0x00 )

This is not quite correct.

Code: Select all

rsUART = "" 

will not fill the string with 0x00 values. It will simply do this.

rsUART[0] = 0x00

So only the first byte changes, the other bytes in the string stay as they are.

The 0x00 is known as the null terminator so if we were to do something like this.

rsUART = rsUART + "Hello"

then we scan through rsUART until we find the null terminator, we then replace the null with 'H' and then continue to add the other bytes. Then after the 'o' had been added we add another 0x00 to again terminate the string.

Code: Select all

rsUART = ""

rsUART[0] = 0x00
rsUART[1] = ???
...
rsUART[x] = ???

Then add the "Hello"

Code: Select all

rsUART = rsUART + "Hello"

rsUART[0] = 'H'
rsUART[1] = 'e'
rsUART[2] = 'l'
rsUART[3] = 'l'
rsUART[4] = 'o'
rsUART[5] = 0x00
rsUART[6] = ???
...
rsUART[x] = ???

[Rudi]

hi benj

you are right,

Code: Select all

rsUART = "" // this makes not {0x00,0x00,0x00,0x00,0x00,....};

can u confirm the 0xFF Bug?

txs

rudi

[Benj]

Hi Rudi,

We use the character 0xFF to indicate a timeout when receiving a byte. I'm not sure if this will also be the case for a string. I will investigate the code for you.

[Rudi]

Hi Rudi,

We use the character 0xFF to indicate a timeout when receiving a byte. I'm not sure if this will also be the case for a string. I will investigate the code for you.

Hi benj

no problem - after 10million hour and 10million question and answeres .. now i know:
if i use receivestring i must be careful with 0x00 or 0xFF in strings. better then use receivechar.

learned btw here much rules.. each string must have a \0 if init it wiht default
if string variable, so one character more must given
uint8 stringvariable[11] = "1234567890\0";

i have change routine's from receivestring to receivechar / receiveByte
, i see just in time, in receivechar, there is timeout too.
i have not checked just in time, as same doing do 0xFF there, but i think no, because the routines run well with receivechar.

txs benj!
best wishes
rudi

[Benj]

Hi Rudi,

If your using the RS232 component then there is a "Return Type" property which allows you to set the timeout value. The 16-bits setting allows 0-255 to come through as data and then values of 256 or greater signify a time out or error. This should hopefully work for strings and bytes and allow the 0xFF value to come through correctly. Note that the read byte macro will need to return to a 16-bit variable to allow you to detect the timeout / error conditions.

We default to the 8-bit return type to allow legacy programs to work as expected.