In #18631 some IN notification callbacks that were doing nothing were
removed, which should be a valid thing to do (ChibiOS HAL checks the
`in_cb` and `out_cb` pointers for being non-NULL before invoking those
optional callbacks). However, it turned out that some less popular USB
LLDs (KINETIS and MIMXRT1062) have their own checks for those pointers,
and (incorrectly) skip the ChibiOS callback handling when those pointers
are NULL, which breaks the code for the `USB_USE_WAIT` configuration
option (the waiting thread never gets resumed if the corresponding
callback pointer is NULL).
Add those dummy callbacks again (but use a single function for all of
them instead of individual ones for each endpoint); this restores the
KINETIS and MIMXRT1062 boards to the working state while the LLDs are
getting fixed.
* Move Bluetooth-related function calls up to host/keyboard level
* Remove pointless set_output() call
* Move bluetooth (rn42) init to end of keyboard_init()
* Enable SPI/UART for ChibiOS targets
* Some more slight tweaks
* Add ARRAY_SIZE and CEILING utility macros
* Apply a coccinelle patch to use ARRAY_SIZE
* fix up some straggling items
* Fix 'make test:secure'
* Enhance ARRAY_SIZE macro to reject acting on pointers
The previous definition would not produce a diagnostic for
```
int *p;
size_t num_elem = ARRAY_SIZE(p)
```
but the new one will.
* explicitly get definition of ARRAY_SIZE
* Convert to ARRAY_SIZE when const is involved
The following spatch finds additional instances where the array is
const and the division is by the size of the type, not the size of
the first element:
```
@ rule5a using "empty.iso" @
type T;
const T[] E;
@@
- (sizeof(E)/sizeof(T))
+ ARRAY_SIZE(E)
@ rule6a using "empty.iso" @
type T;
const T[] E;
@@
- sizeof(E)/sizeof(T)
+ ARRAY_SIZE(E)
```
* New instances of ARRAY_SIZE added since initial spatch run
* Use `ARRAY_SIZE` in docs (found by grep)
* Manually use ARRAY_SIZE
hs_set is expected to be the same size as uint16_t, though it's made
of two 8-bit integers
* Just like char, sizeof(uint8_t) is guaranteed to be 1
This is at least true on any plausible system where qmk is actually used.
Per my understanding it's universally true, assuming that uint8_t exists:
https://stackoverflow.com/questions/48655310/can-i-assume-that-sizeofuint8-t-1
* Run qmk-format on core C files touched in this branch
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
* Disable RESET keycode because of naming conflicts
* Add Pico SDK as submodule
* Add RP2040 build support to QMK
* Adjust USB endpoint structs for RP2040
* Add RP2040 bootloader and double-tap reset routine
* Add generic and pro micro RP2040 boards
* Add RP2040 onekey keyboard
* Add WS2812 PIO DMA enabled driver and documentation
Supports regular and open-drain output configuration. RP2040 GPIOs are
sadly not 5V tolerant, so this is a bit use-less or needs extra hardware
or you take the risk to fry your hardware.
* Adjust SIO Driver for RP2040
* Adjust I2C Driver for RP2040
* Adjust SPI Driver for RP2040
* Add PIO serial driver and documentation
* Add general RP2040 documentation
* Apply suggestions from code review
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
...when attempting to start a receiving USB transfer. Previously, we would
check on the IN endpoint which is the transmitting part of the USB endpoint.
This is wrong and lead to two USB transfers being started immediately
after each other in case of e.g. RAW HID endpoints:
1. When finishing an OUT transfer the low level USB driver calls the out_cb
callback, which in turn initiates another OUT transfer by calling
qmkusbDataReceived.
2. When the raw hid receive channel runs empty inside the raw_hid task,
another OUT transfer is started to potentially fill the channel again. This
happens by calling ibnotify.
Both events occur directly after each other, thus triggering the bug.
* the size variable was redeclared (hiding the variable of the outside scope) and therefore the while check was always false, so the compiler just removed the do while loop, but it would be better to read all data and only exit the task, after this is done
* ChibiOS: add support for HID Programmable Buttons
Fixes#15596
* Enable SHARED_ENDPOINT when PROGRAMMABLE_BUTTON is enabled
The Programmable Button driver expects the shared EP to be enabled.
So enforce this invariant.
* Add support for building against ChibiOS svn/trunk.
* Swap to 21.6.x
* Update to latest branch revision as released version is broken.
* Updated configs.
* Conf updates.
* Updated ChibiOS
* Convert STM32L422 to actual L422 ChibiOS platform.
* Downgrade to 20.3.4 as ChibiOS 21.6.x is being aborted.
* Rollback L422-based boards.
