araffin:
Could you develop please ?
Study the code in the 2nd and 3rd examples in Serial Input Basics. By changing the value of the constant numChars any amount of data can be received.
I use Makefile only for convenience (it removes the Arduino IDE dependency). As you discovered it, you can just renamed it to .ino and it will work.
This is the Arduino Forum and your project is aimed at Arduino users so I should not have needed to rename anything.
For everything that is start, end and content validation, the low-lewel RS232 serial protocol already implements mechanisms (start bit, end bit and parity bit).
That is only relevant for a single byte. It does nothing to identify the start or end of a message.
If you keep the same logic between your arduino/computer code (i.e. same number and type for each parameter of an order), you know the start, thanks to the "Order" message and you know the end because of the fixed length of the parameters.
A the very beginning of the communication, there is also an important synchronisation step (the "hello" exchange) that makes it work.
That makes the big assumption that there is never an error in transmission or loss of communication. It is very easy for two systems to get out of sync.
I should have maybe defined what i meant by "robust". I meant "robust" regarding the buffer overflow issue: even when sending lots of messages (e.g. for remotely controlling a car) the communication continues to work and no messages are lost because of that buffer.
I have not seen anything unusual in your program to deal with buffer overflow. As as I can see you just send short messages - which is perfectly sensible, but hardly needs a GIT project.
wait_for_bytes() is mandatory as you point it out when we want to read multiple bytes. This allow to be sure that we have enough bytes in the buffer before reading a 32-bits int for example.
I don't see that as a waste of ressource because in many cases, you need to receive messages (e.g. motor speed) before continuing the program.
I understand that you need to receive all the bytes to make up a multi-byte message. But there is no need to stand around on the street corner chewing gum while that happens. You don't sit in front of the oven while it cooks a chicken.
And, to think about this in terms of controlling a robot - why not use the time between bytes to check for an obstacle, or to check and correct the RPM of the motor.
...R