Robin2:
And this is a complete non-issue if the Arduino code is designed sensibly
Could you develop please ?
Robin2:
Also the whole concept underlying the Arduino system is simplicity. Why would you force people go to the trouble of using a Make file when they could more easily use a .ino file.
Robin2:
I changed the name of slave.cpp to slave ,ino and it compiled without any error. Then I realized that it does not need the file slave.h so I commented out the line #include "slave.h" and it compiles fine.
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.
Robin2:
I have to say I do not believe your code is as robust as you would like to think because you have no means to identify the start and end of a message or to validate the content of a message. And you attempt to read multiple bytes even though you only check that there is at least one available.
Robin2:
Another problem I have with your code is the use of wait_for_bytes() to wait for a number of bytes to arrive. Serial is very slow by Arduino standards (even at 500,000 baud) and it is a waste of resources to wait for data to arrive.
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).
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.
Concerning content validation, as stated in the possible improvements, there is no checksum for now. Also, if there is a shift once, it may shifts everything (because we don't do synchronisation twice). In practice, i never experienced such a problem.
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.
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.
Robin2:
As you mentioned earlier it is designed to work with text rather than binary data but it is equally possible to implement a similar system for binary data. I have also used a system in one of my own projects that converts numbers to a sort of base64 code and sends them as ascii data - 3 characters can represent numbers up to about 266,000. By sticking with human readable characters debugging is much easier and the conversion to "proper" numbers is much faster than the atoi() function.
Well, most of the debugging part was done creating this library: i looked at binary representation of numbers at the beginning and error were mostly easy to spot. Also, numbers (that is the output of the different functions) are still human readable. Finally, this protocol is not an attempt to replace the "Serial.println()" that is really useful for debug.