The private parts need USB definitions (and are thus preferably used
from USB_H_USER_IS_RIOT_INTERNAL compilation units). Functions like
usb_board_reset_in_bootloader do not depend on USB headers for their
definitions and are fair game throughout the application even for
generic RIOT USB devices.
Currently when the shell receives EOF on `native`, sending EOF
(ctrl + D) closes the stdin file descriptor, leading to all
consecutive reads to also return EOF.
The result is that `shell_run_forever()` will re-start the shell
forever in a loop, filling up the terminal with
> > > > > > > > > > > > > > > > > > > > > > …
until the user hits ctrl + C.
This is annoying.
Instead, cleanly shutdown RIOT when receiving EOF on native, which
should match the expected behaviour of most users.
Co-authored-by: Peter Kietzmann <peter.kietzmann@haw-hamburg.de>
Co-authored-by: Jose Alamos <jose.alamos@haw-hamburg.de>
Co-authored-by: Michel Rottleuthner <michel.rottleuthner@haw-hamburg.de>
This
* renames DEFAULT_xID to USB_xID_TESTING as it is not really a default
(if anyting, the 7D00 is, and it's not that)
* moves the check into Makefile
* generalizes the check to all test PID/VID pairs
* in doing so, fixes the "or" (which would have ruled out warning-free
use of an allocated pid.codes number), and compares to the actual
testing PID rather than the RIOT-peripheral PID
* removes all occurrences of duplicated checks in examples or tests,
leaving definitions only where they are needed
* moves the Kconfig defaults of the usbus_minimal example into the main
Kconfig, as these are good defaults for all cases when USB is enabled
manually
Closes: https://github.com/RIOT-OS/RIOT/issues/12273
Since `min(a,b)` is a very frequently used function, several libraries such as ESP8266 SDK define a `MIN` macro in their header files. Therefore the `MIN` macro should be undefined before its definition to avoid compilation errors if it is defined anywhere else before.
Previously, sched_statistics_cb() was always called with two valid PIDs.
Now it is possible (when the idle thread is not used) that one of the
two might be KERNEL_PID_UNDEF, as the callback might be called when
descheduling the last thread, or scheduling the first.
The code for traversing arrays of shell commands (used to print help messages
and to search for commmand handlers) was needlessly complex.
Co-authored-by: Juan Carrano <j.carrano@fu-berlin.de>
Factor out common code for quoted and unquoted tokens. This makes the code
slighly less clear, but it also eliminates repetition (which may improve
clarity).
Co-authored-by: Juan Carrano <j.carrano@fu-berlin.de>
The DHCPv6 server might send reponses multiple times.
The DHCPv6 client will only handle the first response, if additional
responses are comming in they are left in the RX queue.
That results in the client always reading the response of a previous
transaction on any subsequent transactions.
In this case the client will try again, creating a new transaction - that
will again only read the previous response.
To fix this, discard previous responses by flushing the RX queue before
sending a new message to the DHCPv6 server.
fixes#13834
When using convert_frac to slow down a timer, the extension machinery is
used to prevent converting values that would be larger than, after
conversion, 2**32. In order to calculate the maximum value, UINT32_MAX
is converted.
Previously, this was mistakenly converted by multiplying with the
fraction used to scale up a value. E.g., when using convert_frac to
slow down a 1us timer to provide a 1ms timer, UINT32_MAX was multiplied
by 1000. As the result is used % UINT32_MAX, this lead to a wrong value
close to UINT32_MAX, as ((UINT32_MAX * N) % UINT32_MAX = (UINT32_MAX - N - 1)).
This PR fixes the calculation so max_value is determined by multiplying
with the fraction used to scale down a value.
Modelled GNRC_MAC_ENABLE_DUTYCYCLE_RECORD as bool. Introduced
CONFIG_GNRC_MAC_DISABLE_DUTYCYCLE_RECORD to invert the logic.
Tagged GNRC_MAC_ENABLE_DUTYCYCLE_RECORD for deprecation.
This changes the configuration macro to be the exponent of 2^n, as the
mbox buffer size needs to be always power of 2. The macro now has the
GNRC prefix.
Also a compile configuration documentation group is created.
This changes the configuration macro to be the exponent of 2^n, as the
mbox buffer size needs to be always power of 2.
Also a compile configuration documentation group is created.
This changes the configuration macro to be the exponent of 2^n, as the
message queue size needs to be always power of 2.
Also a compile configuration documentation group is created.
This changes the configuration macro to be the exponent of 2^n, as the
message queue size needs to be always power of 2.
Also a compile configuration documentation group is created.
