[riot-notifications] [RIOT-OS/RIOT] sys: make uart_stdio RX optional (attempt #2) (#11310)

Kaspar Schleiser notifications at github.com
Mon Apr 1 16:31:44 CEST 2019


> I'm not familiar with STM32, but googling around seems to indicate that it has the ability to be woken up from the UART. If that is the case then it is something that should be addressed by the periph implementation.

This usually loses the first byte, which may or may not be acceptable.

> Ok, but what happens if the block is ignored and the device sleeps? Does anything break? Will the RX work after it wakes up again?

On stm32 (and most platforms I know), yes, unless the MCU sleeps too deep. On stm32, there's e.g., the standby mode, which would lose IO configuration and all RAM contents.

> If it is OK for a certain application to not have RX, then it does not matter if the answer is yer or no, and ignoring the blockage is enough to fix the issue (or, rather, work around the lack of low power uart in stm32).

There's many ways to tackle this issue. As of now, if uart is initialized and powered with an RX callback, RX works, but blocks LPM. As long as we don't have a way to specify that losing bytes is acceptable, it should be that way.

"certain applications" should not initialize uart with RX enabled (e.g., they should *not* pass an rx callback).

This PR tackles the issue by making *stdio* RX optional, by not configuring it trough an RX callback.

More elaborate alternatives would make stdio RX sleep controllable. Maybe make it only active when someone is waiting in a read() call comes to mind.
IMO, until we have that functionality, making this a compile-time option makes sense. This is also nice for output-only applications that want to save the RX buffer.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/11310#issuecomment-478603766
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190401/1209a92a/attachment.html>


More information about the notifications mailing list