pico_stdio_deinit doesn't necessarily use the right uart instace/pins #3173

New issue

Open

opened 2026-09-03 16:57:05 -05:00 by kilograham · 2 comments

kilograham commented

2026-09-03 16:57:05 -05:00

(Migrated from github.com)

These APIs seem to have evolved over time; i just noticed this in passing...

there may not actually be a bug here, though i suspect there is... there are multiple paths of pico_stdio_uart_init/pico_stdio_uart_init_full some of which come from stdio_init_all and similarly for de-init. It doesn't look like we do the right thing in all cases. One correct-ish solution might be to record then pins used (we already record the instance, though don't actually use it in de-init), though i'm loathe to increase the code/data size for this (most people dont call deinit after all)

So maybe we just need to be clearer in the comments which paths are/aren't supported, and make sure there aren't other places in the code that blindly call pico_stdio_uart_deinit() or at least we should make sure we describe (and bless) what that is supposed to do (I'm looking at you stdio_deinit_all() !)

See also #3173

These APIs seem to have evolved over time; i just noticed this in passing... there may not actually be a bug here, though i suspect there is... there are multiple paths of `pico_stdio_uart_init`/`pico_stdio_uart_init_full` some of which come from `stdio_init_all` and similarly for de-init. It doesn't look like we do the right thing in all cases. One correct-ish solution might be to record then pins used (we already record the instance, though don't actually use it in de-init), though i'm loathe to increase the code/data size for this (most people dont call deinit after all) So maybe we just need to be clearer in the comments which paths are/aren't supported, and make sure there aren't other places in the code that blindly call `pico_stdio_uart_deinit()` or at least we should make sure we describe (and bless) what that is supposed to do (I'm looking at you `stdio_deinit_all()` !) See also #3173

will-v-pi commented

2026-09-04 07:22:39 -05:00

(Migrated from github.com)

I think the only unsupported paths would be calling the stdout/stdin version of _uart_init() and then calling a different stdio/stdout/stdin version of _uart_deinit() after, because the deinit will isolate the unused pin (e.g. calling stdout_uart_init() followed by stdin_uart_deinit() will result in PICO_DEFAULT_UART_RX_PIN being isolated).

I'll add documentation to the functions to make this clear, but I don't think it's enough of an issue that it needs any code changes, as it is just the isolation latches which are affected

I think the only unsupported paths would be calling the `stdout/stdin` version of `_uart_init()` and then calling a different `stdio/stdout/stdin` version of `_uart_deinit()` after, because the deinit will isolate the unused pin (e.g. calling `stdout_uart_init()` followed by `stdin_uart_deinit()` will result in `PICO_DEFAULT_UART_RX_PIN` being isolated). I'll add documentation to the functions to make this clear, but I don't think it's enough of an issue that it needs any code changes, as it is just the isolation latches which are affected

lurch commented

2026-09-04 07:38:04 -05:00

(Migrated from github.com)