[riot-notifications] [RIOT-OS/RIOT] cpu/rpx0xx: port RIOT to the Raspberry Pi RP2040 MCU (#16609)

Marian Buschsieweke notifications at github.com
Fri Jul 9 16:42:26 CEST 2021


@maribu commented on this pull request.



> +void uart_poweron(uart_t uart)
+{
+    uint32_t reset_bit_mask = (uart) ? RESETS_RESET_uart1_Msk : RESETS_RESET_uart0_Msk;
+    periph_reset(reset_bit_mask);
+    periph_reset_done(reset_bit_mask);
+}
+
+void uart_poweroff(uart_t uart)
+{
+    uart_deinit_pins(uart);
+    periph_reset((uart) ? RESETS_RESET_uart1_Msk : RESETS_RESET_uart0_Msk);
+}

Oh, [it is actually documented](https://api.riot-os.org/group__drivers__periph__uart.html ):

> After initialization, the UART peripheral should be powered on and active. The UART can later be explicitly put to sleep and woken up by calling the uart_poweron() and uart_poweroff() functions. Once woken up using uart_poweron(), the UART should transparently continue it's previously configured operation.

Just not at the API of the functions. I still wonder why a low level driver is burdened with backing up the device state. Especially since in most case the compiler will not be able to optimize the RAM used for this out, even if it is never used.

-- 
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/16609#discussion_r667002256
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210709/2b9c9a9b/attachment.htm>


More information about the notifications mailing list