drivers/periph/uart: add uart_write_byte() & uart_write_string() functions

[benpicco]

Contribution description

When implementing the serial bootloader feature, I added some UART convenience functions.

• uart_write_byte() to send a single byte over UART
• uart_write_string() to send a string of text. This is especially useful for debugging with no stdio

Both are implemented as common fallback functions in drivers/periph_common but can be implemented by the CPU.
An implementation for sam0 is provided for uart_write_byte().

Testing procedure

Issues/PRs references

[aabadie]

You may want to extend tests/periph_uart with these additional functions.

[benpicco]

Good idea, that makes the code a bit nicer to read.

[fjmolinas]

Can't this simply be a static inline around uart_write?

[benpicco]

Sure, moved it there.

[fjmolinas]

I'm somehow unsure about this PR, it cutters the API a bit against for some convenience functions that are actually quite simple, and already implementable with one liners uart_write(uart, (uint8_t*)s, strlen(s)); and uart_write(uart, &data, 1);

RIOT/drivers/include/periph/uart.h

Lines 14 to 17 in 0ad56d4

	* This is a basic UART (Universal Asynchronous Receiver Transmitter) interface
	* to allow platform independent access to the MCU's serial communication
	* abilities. This interface is intentionally designed to be as simple as
	* possible, to allow for easy implementation and maximum portability.

So I'm kind of looking to be convinced :) (but if someone else ACKs it I won't say anything either)

[benpicco]

Well unless an optimized version is to be provided, there is no additional implementation work to be done.

My original idea (besides convenience and nicer looking code) was that only using uart_write_byte in riotboot_serial might save a few bytes if the CPU provides a dedicated implementation.

[kaspar030]

I'm also a bit unsure about this PR. Can we maybe split it:

1. provide the two functions as plain wrappers around uart_write(), in periph_common (or just static inlines), without any way of overriding or providing optimized variants.

IMO, I think that should be good enough.

2. See all the infra necessary for the optimized versions. This allows seeing the impact both on lines of code and possible savings.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.