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.
Introduced a bool 'LORAMAC_DEFAULT_PRIVATE_NETWORK' to invert
the semantics of 'LORAMAC_DEFAULT_PUBLIC_NETWORK'. Move
'LORAMAC_DEFAULT_PRIVATE_NETWORK' to 'CONFIG_' namespace.
Added `CONFIG_SKALD_ADV_CHANNELS` which is then parsed to
and ordered list `SKALD_ADV_CHAN`
Co-authored-by: Leandro Lanzieri <leandro.lanzieri@haw-hamburg.de>
The driver uses the netdev interface. Due to the limited
capabilities of the transceiver (32 byte FIFO and no source address in the layer2 frame),
it relies on 6LowPAN compression and adds the source address to the frame for that.
CPU_HAS_SRAM_BITBAND can be used to check whether bit-banding is supported for
all of SRAM. With partially supported bit-banding, this feature is more of a
foot gun that a valuable tool.
It is often desiderable to sync on multiple threads, e.g. there can be a controller
thread that waits for `n` worker threads to finish their job.
An inverse semaphore provides an easy primitive to implement this pattern.
After being initialized with a value `n` (in counter mode), a call to `sema_inv_wait()`
will block until each of the `n` threads has called `sema_inv_post()` exactly once.
There are situations where workers might post an event more than once
(unless additional state is introduced).
For this case, the alternative mask mode is provided.
Here the inverse semaphore is initialized with a bit mask, each worker can clear one
or multiple bits with `sema_inv_post_mask()`. A worker can clear it's bit multiple times.
Previously a value of 0 was used for the RSSI to signal that this value is not
present in `gnrc_netif_hdr_t`. However, an RSSI of 0 dBm is legal and even very
plausible data.
This commit defines `GNRC_NETIF_HDR_NO_RSSI` as `INT16_MIN`, which is below the
noise floor in the vacuum of outer space and hence impossible to receive.
For consistency, also GNRC_NETIF_HDR_NO_LQI is defined.
When dumping memory the printed addresses always start with `00000000`.
This can be very confusing and lead to errors.
Allow the user to specify a starting address of the printed memory that
will be used instead.
By introducing a wrapper function, existing users are unaffected.
This adds compile-time options to configure the serial of an USB
peripheral. The serial be autogenerated with a configured number of
bytes. It is also possible to configure a fixed serial string for a
device and disable the autogeneration of the serial.
Update the `atomic_fetch_<OPERATION>_u<WIDTH>()` functions to return the old
value the target contained prior to applying the operation. This makes this
API much more versatile and closer to C11 atomics.
