ChibiOS Free Embedded RTOS

Hello,

I wanted to discuss this topic, the new SIO driver.

It is the 3rd driver that uses the USART, we already had the SERIAL and UART drivers so why a 3rd one?

My reasoning:
- Serial is easy to use but it suffers from bad performance because SW FIFOs.
- Serial does not leverage HW FIFOs very well because it assumes SW FIFOs (you cannot do a serial driver without those, are part of the model).
- Serial is not able to use callbacks nor to be used from ISR (easily).
- Events handling is hard in serial driver.
- UART is hard to use and is meant to handle very specific scenarios.

Now the SIO driver:
- It implements a stream like serial so you can use chprintf() and so on.
- It is callback-able.
- If callbacks are not used then interrupts are not enabled and can be used in polled mode.
- Read and write are always asynchronous.
- It has synchronization APIs for synchronous operations.
- It leverages internal FIFOs and thresholds so it can operate at high speed with few interrupts served (depends on the FIFO depth and threshold settings),
- A Serial driver equivalent can be built on top of a SIO implementation. We could create an adapter driver later, serial could be removed too (much later).
- It can also use DMAs with SIO but DMA API has to be called from application, SIO does not use DMA directly. UART driver could also be emulated using some kind of wrapper driver.
- It uses that new HAL paradigm we discussed in another topic.

The code is on SVN now, I am starting tests. Probably it will change some more in next days.

Giovanni

Hello,

that's nice.

Hardware fifo is mandatory for this driver ?

Another field which is not well covered by drivers is continuous reception using half buffer ISR, that has been add to SPI recently, but still missing for UART.

Alexandre

Hi,

It could be implemented on UARTs without HW FIFOs but would have no advantages over the serial driver, still one interrupt per byte exchanged.

About DMA, you can setup DMA as you wish, including half buffers, this is done outside the driver.

Giovanni

An interesting development. Some time ago I modified the serial driver to have optional callbacks (it's posted somewhere here), and that seems to address some of your early comments at the cost of a small amount of additional code. Basically I had two different requirements, one of which had to be selectable at run time. The first, which I will call terminal mode, uses the standard serial calls for both transmit and receive. The second, which I call 'protocol' mode, requires knowledge of each received character as it arrives. While this could use the standard receive software FIFO, with or without events, it adds quite a lot of overhead, so I added some callbacks. The transmit side just fills the transmit FIFO with a single multi-character response; so this could be sent using DMA.

For me, I'm typically using 9600-38400 baud serial, so interrupts aren't a major overhead. With faster data rates one can possibly make assumptions about the volume of data to support use of DMA on both transmit and receive; probably based on half buffers.

Hi,

Yes, I remember that change but I didn't want to modify the legacy serial driver, this is why I added SIO (as a model) a while ago but I never proceeded with an implementation.

A recent development gave me a chance to invest some time on this. Serial could be obsoleted at some point and just become a wrapper module around SIO adding SW queues and events.

Giovanni

Hi,

I added SIO for USARTs without FIFO under USARTv2, the FIFO implementation is under USARTv3. I am not sure how useful this is unless the application provides buffering or DMA support on top of SIO.

Note that mcuconf.h files have not yet been updated with new settings, will be updated during weekend. I am also thinking to update all demos to use SIO in place of the old serial driver (for devices with FIFOs).

Both SIO and Serial implement the BaseChannel interface so it does not change much at application level, just replace this:

sdStart(&SD1, NULL);

with this:

sioStart(&SIOD1, NULL);
sioStartOperation(&SIOD1, NULL);

Feedback is welcome.

Giovanni

Can the SIO driver be used from within the ISR context?

I'd like to print some diagnostics after a hardfault, but this is difficult (or not possible?) with the Serial driver.

Nice work as always Giovanni! Your code is such a pleasure to read.

Hi,

It is possible to read and write from ISR context but, of course, you cannot "wait" in ISR context so, for example, if the TX FIFO is full, you cannot write in that moment.

Giovanni

Just came upon that promising feature.
Is there a time-line for inclusion of SIO in a release? I do not think I have seen that yet.

Hi,

It will be in release 21.x.

Giovanni