My vb app will send a command byte (bytes precisely) to arduino. medium is serial/ethernet, but for now serial. Say 0x50 is the byte which PC will send and then arduino will receive, if matched (as that have to be) then it will reply back/do something. I want to make a parser function which will take care of this:
//Serial parser
void sbcSerialParser(void) {
}
and this will hold the global variable.
The reason is basically instead of sending strings over serial, i wish to send byte as hex to avoid "extra" data for command.
Check if data is available using Serial.available(). If so, read a byte using Serial.read() and compare. If valid, send back e.g. 0x00 (ACK for valid command) or 0x01 (NACK for invalid command) using Serial.write().
If your commands are always single byte, you can skip the below.
Regarding overhead, you will have to keep your PC and Arduino in sync. Lets say that you send two bytes
0x50 0x03
0x50 -> switch led on
0x03 -> led on pin 3
You receive 0x50 but for whatever reason miss 0x03; your Arduino will happily be waiting for the second byte to know which led needs to be switched on.
Next you send two bytes to switch the led off
0x51 0x03
0x51 -> switch led off
0x03 -> led off pin 3
As you missed the 0x03 earlier, the Arduino will now take 0x51 as the second parameter and will switch led 81 on
So you need to design a protocol. E.g. for transmission from PC to Arduino
start byte; the Arduino code will ignore any serial data till it has seen the start byte
data length; how many bytes are to be expected
data bytes; the actual data
checksum; so you can validate the received data
end byte; indicates end of data and Arduino code will wait for start byte again
There is a bit more to that; what if the data can contain the start byte (e.g. start byte is defined as 0x50 but command can also be 0x50). If the Arduino missed the start byte for whatever reason, it will see the command 0x50 as the start byte and use the next byte as the length.
So think about it before thinking that it might save you overhead
sterretje:
So think about it before thinking that it might save you overhead
haha, I understand your point... basically data will be single byte mostly.. commands... like do this do that type... not even LED... it is a task,but on arrrival of that byte based command.
And yes!! Have a plan for protocol development later also... but for now, just sending byte is all enough.
What I'm doing now is i'm sending strings as chars like "open", "close", etc. I wanna change it... (I know I can send "o", "c" and it will be same one byte... but then my choice will be limited and I also want to make this thing a bit hard for people, so serial port and a ascii char will not help them unless they actually send the byte value.
Delta_G:
0x50 == 'P' == 80 == 0120 They are all interchangeable.
just for the sake of debate, (i should not debate though):
string(0x50) as a string and char hexVal = hex(0x50) is not same...
I mean 0x50 can be a string too... :-p
Anyway, all i need is to read a single byte and i got it i think... Now, If i need several bytes, then it's the same old method again... just sending bytes instead of String. Right??
When you write 0x50 without quotes most people will assume you mean a number whose decimal equivalent is 80 an whose binary representation is 0b01010000
I have written it just to make readers understand that I'm looking for (or talking about) HEX value (aka byte)
As,
Delta_G:
"0x50" as a string is an array with 5 values. That's a completely different thing.
right!!
It was all about a byte vs a String... and i was looking for a byte... and 0x50 was a sample/example. Like I can send "ACK" or 0x00 as A C K = 3 byte and 0x00 is a single byte. [apart from other overheads]
