Riot: UART API: polled read function

[dylad]

I would like to know why there is no uart_read function within the API. I'm ok with ringbuffer and interrupt but why UART is the only one which don't have a polled read ? Is there any historical reason ?

I'm currently porting some code from Atmel Studio with polled read uart. Not having a polled read is a bit frustrating.

[kbumsik]

I am wondering too. Is there any specific reason not providing polling UART read function?

[OlegHahm]

I cannot see a reason against it right now and from my understanding it shouldn't be too difficult to implement. Have you considered to open a RFC-PR that updates the API accordingly?

[dylad]

Yes I do, but I would like to know the community's opinion first :)

[haukepetersen]

Yes, there are reasons for this (though they might of course be debatable):

• the API should be as slim as possible -> any function (that is not there) counts
• the periph APIs should be as slim as possible and with this their implementations should not require any buffers -> but a polling uart_read function is not very useful without buffering

The concept in general is to keep the periph APIs and their implementations as slim as possible (i.e. no buffering, multiplexing), and do additional functionality on top of this. So the conceptual solution for having a buffered, polling read function is to simply put a wrapper on top of the existing periph/uart interface, that allows for this behavior. Or simply just use the uart in conjunction with the isrpipe module (as done e.g. in sys/uart_stdio).

[dylad]

I can understand your vision. Though I'm a bit confuse about it.

the API should be as slim as possible -> any function (that is not there) counts

I agreed with you.

their implementations should not require any buffers

Yes we need a buffer for storing data using a read but isn't it the same for SPI & I2C ?

Of course, write specific wrappers is the best option when you need to grab some piece of code from outside into your RIOT app. But I think a basic polled read could help newcomers to have a better apprehension of RIOT.

In fact, there is something that make me feel uncomfortable : why SPI can have a polled read function within the API while UART cannot ?

[haukepetersen]

why SPI can have a polled read function within the API while UART cannot ?

a) SPI is synchronous, UART is not
b) using SPI (we are talking about RIOT being the bus master), the amount of bytes that are to be transfered is known ahead of time, same goes for e.g. I2C

[haukepetersen]

Again, it would be simple to build a 'buffered_uart' module on top of the uart interface, which then provides buffering and the ability for polled reading.

[kaspar030]

There's isrpipe.

These are the steps to read from uart, not polled but with a buffer:

static char _rx_buf_mem[BUFSIZE];
isrpipe_t uart_stdio_isrpipe = ISRPIPE_INIT(_rx_buf_mem);
[...]
    uart_init(uart_dev, baudrate, (uart_rx_cb_t) isrpipe_write_one, &uart_stdio_isrpipe);
    isrpipe_read(&uart_stdio_isrpipe, buffer, count);
[...]

We could think about wrapping that a little more nicely...

[dylad]

Well, I'm fine with both proposed solutions. As long as we have the relevant documentation with it !
Would be great to have a ready-to-use solution :)

[PeterKietzmann]

@dylad would you consider this issue addressed? If not, any chance you provide a fix? I'd like to close this issue then...

[dylad]

Well I've got my answer. Maybe I'll come with a buffered UART read as module using isrpipe someday :)