My Arduino drives a little robot. The commands come via serial (USB) from as Raspberry Pi.
The Pi has a queue of commands (e.g. move 1cm forward) that it sends one by one to the Arduino. But since my Arduino logic has no means to store multiple commands I send a serial command from the Arduino to the Raspberry Pi every 10ms that polls for the next command. When a command is still being executed, the serial command is not issued. That way the Pi does not send commands when the Arduino is still chewing on a command.
This effectively means that the Arduino sends out a serial command (Serial.write("mor") 100 times a second when there is nothing to do.
Edit: I should add that the project requires that many small commands are sent. There will be hundreds of little commands that make up one continous motion. This is why I created such a short polling interval.
I am wondering: is sending such a constant stream of serial commands from the Arduino a bad thing? Does it consume a lot of energy? (Since I am creating a battery powered robot, this could be an issue.) Is there a more clever way to do this?
This effectively means that the Arduino sends out a serial command (Serial.write("mor") 100 times a second when there is nothing to do.
Why? You should send a request (for more) only when the last one has been executed. Then, you should wait for a new command before doing anything else.
Sending requests for more data using a timer is silly.
You don't see bank tellers calling the next customer that way, do you?
Thanks, PaulS, for your suggestions. I modified the code. Arduino only asks for new commands once now. The Pi, on the other hand, now has a way of storing this state ("Arduino is waiting for a new command"). This is important since there may not be a command when the Arduino asks for it but only at some point later in time.
Robin2, thanks. There is not a lot of delay right now. I might implement this solution in the future if I need it.