L'Hexapod: Arduino multiple serial disappointment

Tonight I took a look at the ‘software serial’ support in the Arduino. I can’t say I’m that impressed…

The Arduino has a built in hardware UART (a hardware serial port) which works as expected. It allows you to talk to external serial devices but there’s only one of it so if you want to have an external device talk to you via a serial port and then you want to talk to something else via another serial port then you’re out of luck. Serial ports (at the microcontroller level) are, essentially, just about sending a set of signals of a pre-agreed duration out of an I/O pin. This is where the software serial library for the Arduino comes in (by the way, ignore the page you find if you google for “software serial arduino”,you want this one, not that one. The software serial library allows you to send and recv serial data on any of the Arduino’s I/O pins, or so they say… This would be handy if you’re already using the built in UART for something else.

Unfortunately the devil is in the timing when you’re doing serial communications. Whilst the Arduino can manage to send data reasonably well it’s slightly more challenged to receive it. Especially if you want to do something with it once you get it. The problem boils down to timing. The signals on the serial line don’t wait and so if you’re waiting for data and then doing something with that data you’re likely to miss any other data that comes in whilst you’re processing the data you just got… Since I come from a PC background I’m used to my serial data being buffered for me and, well, it just working.

In summary the software serial code for the Arduino will likely work nicely if you define an appropriately anal protocol between the sender and receiver. You, the Arduino on the software serial port need to tell the other end when you’re ready to receive data. You then need to receive a known quantity of data and once you have it the sender can’t send any more until you’ve processed the data you have and then give it the all clear to send some more. Ideally, you need a flow control line between you and the sender for it to work reliably or you need to drive the software serial recv code from an interrupt and buffer the inbound data (and even then you’d need the flow control line to be reliable given data that exceeds your buffer space). Now, this is all possible to do but takes up another I/O pin for the flow control line and I’d need to write code to do it as the software serial library doesn’t support it out of the box….

Anyway….

What I thought I could do is switch to simply sending from the software serial port (which is less likely to be affected by me doing other things, as I can’t do other things whilst I’m sending!) and send and recv on the hardware UART… Unfortunately this evenings tests seem to imply that this approach is also unreliable…

So, right now I am relying on the fact that both serial connections that I require are uni-directional, I’m receiving from the PC and sending to the servo controller… Because of this I can use the hardware UART for both links and use it half-duplex on each. However, this is hardly ideal…

One good thing about tonight is that this evening’s journey has exposed me to how cute the Arduino’s hardware support libraries are. You simply drop some C/C++ code in a directory and it gets built automatically and made available to the Arduino development GUI. Creating new libraries looks stupidly easy and patching existing ones is just a case of editing the source files… A very nice interface for people who know how to customise the environment and an equally nice interface for those who don’t.