Previously, uart_poweroff() and uart_poweron() were no-ops. This
replaces them with the logic to indeed power on and power off the UART
device.
Co-authored-by: crasbe <crasbe@gmail.com>
Replace elf2uf2 usage with picotool, fix compilation when arm g++ is installed, adjust documentation to new workflow, picotool udev warning (thanks to crasbe)
The native CAN implementation relies on the underlying OS to implement
CAN, so we can leave handling the nitty-gritty details such as the loop
delay to the underlying implementation.
Allowing to configure the CAN controller to start in monitor mode right
away reduces the risk to change traffic (e.g. by sending an ACK)
between initialization and the switch to monitor mode, if intneded to
be a passivle listnener only.
Being able to specify the bitrate from the peripheral config makes
a lot more sense than starting up the CAN with an incorrect bitrate and
letting the app change it later on.
Allow the board to configure whether the transmit pause feature of the
CAN controller should be used or not.
The default is to not enable transmit pause feature for consistency with
other CAN controllers. For many use cases enabling the transmit pause is
the better option though, as it will only slightyly decrease the maximum
throughput by inserting a 2 bit time pause between two subsequent
frames to send. The benefit is that it will ensure that nodes on the CAN
bus with a lower priority (according to their CAN ID) will not starve,
effectively prevending the "Babbling Idot Syndrome".
Allow the board to configure whether automatic retransmission is to be
used or disabled.
This also changes the default to enabling automatic retransmission, as
this is the best choice for most use cases.
`pid_t` is provided e.g. by `<sys/types.h>`. It seems that on glibc,
`<stdlib.h>` will also provide `pid_t`. But this way it should work on
both musl and glibc.
The real_read() function will block the thread but won't preempt it.
That means all other thereads on the same (or higher) priority level
are blocked as RIOT still consideres the thread that called stdio_read()
as running.
Use async_read/isrpipe to properly block the thread when reading from
stdin.
