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.
- The tool compatibility matrix got super large
- split out all "single-purpose" tools and list them per platform
- Highlighting code via backticks in titles doesn't render well with
Doxygen
- replace all `int`s and `unsigned`s with integers with fixed width
- replaced all signed integers of sizes with unsigned ones (sizes
cannot be negative)
- made bitshifts 8-bit safe (e.g. `1 << 24` is valid on 32-bit, but
undefined behavior on 8-bit, as a 16 bit wide `int` would be shifted
by more than the type width)
- use `void *` / `const void *` for data buffers to ease use
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.
Otherwise if the cable is connected at boot the immediate NETDEV_EVENT_ISR
event signaling connection will not trigger the isr, and the netdev will not
clear its pending event.
This explains why the connect/rx event clash seen in "esp32/eth: Don't
overwrite queued event with RX packet" (95196fb7e4) only happened
with lwIP.
Now on my ESP32 board with Ethernet the issue was the opposite (since IDF
upgrade), the stuck connected event blocked receive from working. After
this change 95196fb7e4 can be reverted since even early events are
consumed properly.
Enables the SDL driver for LVGL to utilize a user prescribed width/height for display resolution when utilizing SDL, or rely on the SDL_HOR/VER_RES provided by lv_drv_conf.h in lv_drivers
If module `core_mutex_priority_inheritance` is enabled, the scheduling has to be active to lock/unlock the mutex/rmutex used by FreeRTOS semaphores. If scheduling is not active FreeRTOS semaphore function always succeed.
