When either `gnrc_sixlowpan_iphc_nhc` or `gnrc_udp` is not compiled
in `_compressible()` never returns `true`. This causes the
`dispatch` snip in `gnrc_sixlowpan_iphc_send()` to be of length 0,
meaning `dispatch->data` is `NULL`, causing possible crashes when
trying to send IPv6 packets over 6LoWPAN without NHC or UDP.
The default macros GPIO_PIN and GPIO_UNDEF do not have to be overridden. The GPIO_PIN macro definition was even wrong for 40 GPIOs without splitting into ports, even if that did not lead to erroneous behavior.
Loosely based on [the original ping] and [netutil]'s ping
New features (compared to old RIOT version):
- non-positional parameters
- Better duplicate detection (addresses #9387)
- Better asynchronous behavior
- Potential for future move to `sock_ip`
- (Optional) DNS-support
- Multithreading-safe (in case shell-command handler gets called
from multiple threads)
[the original ping]: http://ftp.arl.army.mil/~mike/ping.html
[netutil]: https://www.gnu.org/software/inetutils/
When IPv6 is enabled, the MTU is given. So users(*) sending IPv6 packets can
easily figure out what the supported maximum protocol unit is.
However, when IPv6 is disabled and a user wants to send layer 2 frames directly,
no information about the maximum PDU is available using the shell.
When 6LoWPAN is used, a user may be interested in the layer 2 PDU as well in
order to avoid layer 2 fragmentation.
This PR adds the L2-PDU info to the output of the ifconfig shell command, which
is printed regardless of the use of IPv6.
(*): Here "users" refers to human beings interacting with the shell.
Applications can get the maximum PDU of each layer more easily using
gnrc_netapi_get() with NETOPT_MAX_PACKET_SIZE instead of using a shell command.
This the first step in moving the collection of layer 2 netstats from
the low level driver to a central location, ie. gnrc_netif, to avoid
code duplication.
Add command mode that will be used like this:
mode <dev> <data bits> <parity> <stop bits>
This command must be called after init otherwise
the UART won't be fully initialized.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Add support for specifying data bits, stop bits and parity at
runtime.
Introduce feature periph_uart_modecfg for uart_mode() till all
other CPUs implement it.
STM32 L1, F1, F2, F4 supports following modes:
* 7E1, 7E2
* 7O1, 7O2
* 8N1, 8N2
* 8E1, 8E2
* 8O1, 8O2
STM32 L0, L4, F0, F3, F7 supports following modes:
* 6E1, 6E2
* 6O1, 6O2
* 7E1, 7E2
* 7O1, 7O2
* 7N1, 7N2
* 8N1, 8N2
* 8E1, 8E2
* 8O1, 8O2
Use USART_CR1_M1 macro to detect 7-bit support because
even inside one family there could be devices that don't
support 7-bit mode. So just using a family macro is not
enough.
As stated in the datasheets for L0, L4, F0, F3, F7 devices,
data bits can only be changed when UART is disabled (UE=0).
Introduce uart_stop() routine to satisfy this requirement.
STM32 UART adds parity to the MSB of a byte to send. The same
also applies to the received bytes. As a result this bit must
be masked in order to get the pure data.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
As suggested in PR#5899 add a routine uart_mode() that will
setup data bits, stop bits and parity at runtime.
uart.h provides a set of enums defining these settings and each
platform will override them to specify values corresponding to
its configuration registers.
The idea behind the enums is to specify default settings i.e. 8N1
through the 0 value item. Invoking uart_mode(uart, 0, 0, 0) will
setup 8N1 mode.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
