- Adds capabilities for each PHY mode. Converts the uint16_t caps field to an
uint32_t in order to hold all capability bits, size of the structure remains
unchanged due to alignment.
- Modifies the test application to configure the PHY mode using the shell
command. Also adds the PHY modes to the capabilities shell command.
- Updates the nrf802154 and cc2538 radio drivers to specify the PHY mode
supported.
Signed-off-by: Jean Pierre Dudey <me@jeandudey.tech>
If we call `netif_register()` before we can be sure that the interface
can be configured, a 'zombie' interface remains in the list, causing
all kinds of trouble down the line.
Only call `netif_register()` if `init()` was successful.
In case of an error, the tx sync packet snip could previously have been
released twice. This moves re-attaching the tx sync snip down after the
last `goto error` to avoid this.
The URI is passed as a string to `suit_coap_get_blockwise()`.
It may contain query parameters, those will not be translated
properly to CoAP options if `coap_opt_put_uri_path()` is used.
Instead use `coap_opt_put_uri()` to handle both path and query
parameters.
Lists state, link type, v4/v6 addresses.
Currently read-only.
Using lwIP debug system to print addresses, to limit dependencies
and work with dual stack setup. Most other code seems to only
allow either v4 or v6 networking. For that to compile I
had to change the `SZT_F` format string due to this error:
```
error: format '%lu' expects argument of type 'long unsigned int',
but argument 2 has type 'size_t {aka unsigned int}'
```
Switching to the lwIP default format string here.
Outputs the following on my ESP32 board with Ethernet,
when both v4 and v6 are enabled in examples/paho-mqtt:
```
> ifconfig
Iface ET0 HWaddr: 24:0a:c4:e6:0e:9f Link: up State: up
Link type: wired
inet addr: 10.4.4.81 mask: 255.255.254.0 gw: 10.4.4.1
inet6 addr: fe80:0:0:0:260a:c4ff:fee6:e9f scope: link
inet6 addr: 2001:db8:1000:0:260a:c4ff:fee6:e9f scope: global
Iface ET1 HWaddr: 24:0a:c4:e6:0e:9c Link: up State: up
Link type: wireless
inet addr: 10.4.4.82 mask: 255.255.254.0 gw: 10.4.4.1
inet6 addr: fe80:0:0:0:260a:c4ff:fee6:e9c scope: link
inet6 addr: 2001:db8:1000:0:260a:c4ff:fee6:e9c scope: global
>
```
Otherwise the local mallocs variable is not decremented correctly (if
TEST_SUITES is defined) and the fuzzing setup (i.e. when MODULE_FUZZING
is defined) does not terminate. This regression was introduced in
3970b667aa.
While the for-loop condition does contain a bounds check, the pointer is
independently increment in the for-loop body. This increment therefore
requires a separate bounds check. Otherwise, the parsing loop may access
data outside the given buffer boundaries.
The new `gnrc_tx_sync` module allows users of the GNRC network stack to
synchronize with the actual transmission of outgoing packets. This is directly
integrated into gnrc_sock. Hence, if `gnrc_tx_sync` is used, calls to e.g.
sock_udp_send() will block until the network stack has processed the message.
Use cases:
1. Prevent packet drop when sending at high rate
- If the application is sending faster than the stack can handle, the
message queues will overflow and outgoing packets are lost
2. Passing auxiliary data about the transmission back the stack
- When e.g. the number of required retransmissions, the transmission time
stamp, etc. should be made available to a user of an UDP sock, a
synchronization mechanism is needed
3. Simpler error reporting without footguns
- The current approach of using `core/msg` for passing up error messages is
difficult to use if other message come in. Currently, gnrc_sock is
busy-waiting and fetching messages from the message queue until the number
of expected status reports is received. It will enqueue all
non-status-report messages again at the end of the queue. This has
multiple issues:
- Busy waiting is especially in lower power scenarios with time slotted
MAC protocols harmful, as the CPU will remain active and consume
power even though the it could sleep until the TX slot is reached
- The status reports from the network stack are send to the user thread
blocking. If the message queue of the user thread is full, the network
stack would block until the user stack can fetch the messages. If
another higher priority thread would start sending a message, it
would busy wait for its status reports to completely come in. Hence,
the first thread doesn't get CPU time to fetch messages and unblock
the network stack. As a result, the system would lock up completely.
- Just adding the error/status code to the gnrc_tx_sync_t would preallocate
and reserve memory for the error reporting. That way gnrc_sock does not
need to search through the message queue for status reports and the
network stack does not need to block for the user thread fetching it.
RISC-V support semihosting in very similar way as the cortex-m
microcontrollers. The code calls a breakpoint instruction and the
attached debugger reads/writes registers and memory for stdio.
The RISC-V architecture doesn't support a call number with the EBREAK
instruction, to allow the debugger to detect a semihosting break point,
the EBREAK instruction is wrapped in a SLLI and SRAI instruction. These
use x0 as output register, making them NOP instructions.
One caveat when using this is that the RISC-V core traps the EBREAK
instruction with trap code 3 when no debugger is attached. Restarting
the application with the debugger attached avoids this.
