19368: debug: add DEBUG_BREAKPOINT() macro, set breakpoint on failed assertion r=benpicco a=benpicco
19529: cpu/stm32/periph/dac: optimize setting DAC r=benpicco a=Enoch247
### Contribution description
The current implmentation right shifted the 16 bit value passed into `dac_set()` down to the 12 bits that the DAC is actually capable of. This patch drops the shift and instead writes the 16 bit value to the DAC's left aligned 12 bit wide data holding register.
### Testing procedure
do something like:
``` c
#include "perip/dac.h"
int main(void)
{
dac_set(DAC_LINE(0), 0xffff/2);
return 0;
}
```
- observe DAC's output is half of vref
### Issues/PRs references
- none known
19531: tests/unittests: allow passing `UNIT_TESTS` via env r=benpicco a=kaspar030
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in
on log messages such as
[mutex] waiting for thread 1 (pc = 0x800024d)
being added whenever `mutex_lock()` blocks. This makes tracing down
deadlocks easier.
Make sure both the stack and TLS blocks are correctly aligned by
adjusting the TLS base address to the most strict alignment of the TLS
block and the stack.
Signed-off-by: Keith Packard <keithp@keithp.com>
18472: drivers/mrf24j40: add support for IEEE 802.15.4 Radio HAL r=benpicco a=jia200x
19175: drivers/periph_common/flashpage: fix silent error r=benpicco a=Enoch247
### Contribution description
This patch removes a test that silently hides failed writes to NULL. Instead, assert is used to ensure that the address is not NULL.
### Testing procedure
I am not certain how to update the tests to catch asserts. If this is possible, I will add a test, if someone will point me to a good example to learn from.
### Issues/PRs references
- none
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
19156: core/compiler_hints: add likely() / unlikely() hints r=kfessel a=benpicco
19174: tests/periph_spi clearly say when init succeeds r=benpicco a=jdavid
When the `tests/periph_spi` program succeeds the output can be interpreted as an error happened.
This PR makes it clearer when it does succeed.
### Contribution description
In `tests/periph_spi`:
- Explicitely say that the init operation was successful
- Rephrase the note to avoid misinterpretations
### Testing procedure
Run the `tests/periph_spi` program.
There is not much to test, just to verify the output, should be like this:
```
2023-01-19 10:42:33,768 # Trying to initialize SPI_DEV(1): mode: 0, clk: 0, cs_port: 0, cs_pin: 0
2023-01-19 10:42:33,777 # (if below the program crashes with a failed assertion, then it means the configuration is not supported)
2023-01-19 10:42:33,779 # Success.
```
### Issues/PRs references
Issue https://github.com/RIOT-OS/RIOT/issues/19025
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: J. David Ibáñez <jdavid.ibp@gmail.com>
The macros CONCAT(), MIN(), and MAX() are defined over and over again in
RIOT's code base. This de-duplicates the code by moving the macros to a
common place.
The mbox code contains a race condition in `mbox_put()`: When it
waits for a slot in the queue to become available, it is woken up with
IRQs enabled. It disables IRQs again as first thing, but by then
another thread may already have preempted the running thread and filled
the queue back up. In this case, a message in the queue would be
silently overwritten.
This restores a pre-existing design decision to implement both
blocking and non-blocking mutex locking with the same code. Those
implementations have been split prior to the introduction of
the `core_mutex_priority_inheritance` module when `mutex_trylock()`
indeed was trivial. This decision didn't age well, so undo it.
Presently, RIOT just emits a warning when a stack overflow is
encountered but still resumes execution. In my view, execution should be
aborted as the detection of a stack overflows via the heuristic provided
by the scheduler is an unrecoverable error.
I ran into this while performing automated tests of a RIOT application
where a stack overflow occurred but I only noticed this after inspecting
the application output more closely.
Similar to SSP failures, I added crash_code for stack overflows.
This fixes https://github.com/RIOT-OS/RIOT/issues/18545 as the code
previously relied on `sched_change_priority()` not directly scheduling
a new thread while IRQs are disabled, but rather later when IRQs are
restored. This is true for Cortex-M MCUs (where the PendSV IRQ is used
to trigger the scheduler), but not e.g. for AVR.
An `1 << x` with `x >= 15` is undefined behavior on 8-bit / 16-bit
machines (which typically have `sizeof(int) == 2`).
Using `1UL << x` is safe for `x <= 31`, which is large enough to make
use of the full 32 bits in `runqueue_bitcache`.
In addition, a `static_assert()` is added to enforce that
`SCHED_PRIO_LEVELS` is never set to anything larger than 32.
This is intended for the bootloader module where we don't enter thread
mode, so mutex must never attempt to switch context.
Instead use a simple busy wait that is enough to make the possible mutex
users (e.g. interrupt based SPI) in bootloader mode work.
Use `uintptr_t` for arithmetic rather than `const char *` to fix the
following warning:
> comparePointers: Subtracting pointers that point to different objects
- activate THREAD_CREATE_STACKTEST also if test_utils_print_stack_usage
is used
- make thread_measure_stack_free() available unconditionally
- if DEVELHELP is active, call test_utils_print_stack_usage() on any
thread exit
- if DEVELHELP is active, call test_utils_print_stack_usage() after main
for the idle thread, if that is used
Replace use of C11 atomics with atomic utils. This fixes
> error: address argument to atomic operation must be a pointer to a
> trivially-copyable type ('_Atomic(int) *' invalid)
error when compiling on AVR with LLVM.
This adds a simple macro to check (at C level) whether a given
expression is proven to be compile time constant and suitable for
constant folding. This allows writing code like this:
```C
int gpio_read(gpio_t pin) {
if (IS_CT_CONSTANT(pin)) {
/* this implementation should even be able to use the port and
* pin number as immediate in inline assembly */
}
else {
/* less efficient implementation that cannot use port and pin
* number as immediate in inline assembly */
}
}
```
This provides the same functionality as `static_assert()` provided by
C11 and has no advantages compared to it. Hence, encourage users to use
standard C functionality instead.
For the caller there should be no difference if there is no message
in the queue and if there can't be a message in the queue.
The current API works as one would expect if there is a message queue,
but once called from a thread that does not have a message queue
configured, code that does
while (msg_avail())
will end up in an infinite loop.
Remove this foot-gun from the API by making the return value of
msg_avail() independend of the availability of a message queue.
`WITHOUT_PEDANTIC(expr)` disables `-Wpedantic` for `expr`, but switches
back to the previous diagnostic settings afterwards. This helps defining
macros that are not strictly ISO compliant without having to drop the
`-Wpedantic` flag entirely.
`DECLARE_CONSTANT(identifier, const_expr)` declares an anonymous `enum`
constant named `identifier` and assigns it the value `const_expr`. Here,
`const_expr` has to be a compile time constant, but is not needed to be
an integer constant expression. It basically is a tool to magically
convert a non-integer constant expression into a integer constant
expression.
Calculate the size of the element based on the array given, not based
on the element pointer.
The element might as well be given as a `void *` via a callback.
In that case, if the user forgets to cast the `void *` to the array
element type, the calculation returns false values.
Disarm this foot gun by basing the element size off the given array.
