cpu/nrf5x/uart: run STOPTX task after finished tx

[jue89]

Contribution description

The examples/hello-world shows a power consumption of 400uA on the nrf52dk board, even though stdin isn't wired and, thus, RX of the periph_uart isn't wired.

This PR makes sure that TASKS_STARTTX is called before a transmission. After completion the TASKS_STOPTX is run allowing for entering low power mode.

Testing procedure

nrf51 and nrf52 CPUs should be able to transmit octets using periph_uart with and without the uart_nonblocking feature.

Issues/PRs references

[maribu]

lgtm, trusting your testing. I have one style suggestion. Please squash right away.

[kaspar030]

is there any way to test if this affects parallel printing? (two threads printing at the same time, one stopping tx after finishing, killing tx for the other)

[jue89]

is there any way to test if this affects parallel printing? (two threads printing at the same time, one stopping tx after finishing, killing tx for the other)

Well, parallel printing would crash anyway - for the nrf52 the driver is using DMA. To remove this race, we would need mutexes, I guess?

[jue89]

I'll try to come up with a solution. Something like this:

• nrf51: reference count the parallel uart_write() calls. Call run TASKS_STOPTX only if all calls have returned.
• nrf52: spin-lock if another DMA process is currently on-going.

What do you think? Do you have better ideas?

[maribu]

Note that UART is slow. If the DMA is still busy with shuffling many many bytes out of the slow UART, it likely is better to just switch to another thread.

I'd just go for a mutex. They are super-duper fast in the hot path, and still well optimized when they actually need to block.

I'd also say that parallel UART access is a rare corner case. So most of the time the mutex will be in the super-duper fast hot path.

[haukepetersen]

LGTM as well.

Regarding the Mutex: IMHO there is no need for the (low-level) UART driver to be thread safe. This should be handled by the module acutually using the UART, e.g. STDIO or something like a Modbus library etc. However this should of course be documented (if it is not already) :-)

[maribu]

This should be handled by the module acutually using the UART

Agreed! Having this implemented once e.g. in stdio rather than for each and every UART driver makes much more sense.

[haukepetersen]

Also one might want to use periph_uart in ISR context, and that won't work too well with mutexes involved, right?!

[jue89]

This should be handled by the module acutually using the UART

Agreed! Having this implemented once e.g. in stdio rather than for each and every UART driver makes much more sense.

Is stdio thread-safe? I see exactly this case: a thread is interrupted while printing to stdout and the ISR also logs something to stdout.

[jue89]

I'd just go for a mutex. They are super-duper fast in the hot path, and still well optimized when they actually need to block.

But how to handle ISRs calling uart_write()? Afaik are mutex_lock() and ISRs no friends ...

[maribu]

stdio from ISR is only allowed for debugging. And in that case, one wants to use stdio_rtt (which is now also supported with OpenOCD, btw.) anyway to reduce the risk of delaying the ISR too much to reproduce the bug.

[jue89]

So keep this PR like it is and wait for Murdock?

[riot-ci]

Murdock results

✔️ PASSED

3da1fac cpu/nrf5x/uart: run STOPTX task after finished tx

Success	Failures	Total	Runtime
117849	0	117849	01h:56m:03s

Artifacts

• Documentation preview

[jue89]

Murdock is green. I would merge, if nobody objects?

The nrf5x periph_uart wasn't thread-safe before this PR and this PR doesn't change this.
If this needs to be changed, I'd do that in a follow-up PR.

[jue89]

Thank you all :)