* 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>
Unfortunately, the crippled versions of “Bluepill” boards with
STM32F103C6xx chips instead of STM32F103C8xx are now sold all over the
place, sometimes advertised in a confusing way to make the difference
not noticeable until too late. Add minimal support for these MCUs in
the common “Bluepill with stm32duino” configuration, so that it could be
possible to make something useful from those boards (although fitting
QMK into the available 24 KiB of flash may be rather hard).
(In fact, I'm not sure whether the “STM32” part of the chip name is
actually correct for those boards of uncertain origin, so the onekey
board name is `bluepill_f103c6`; another reason for that name is to
match the existing `blackpill_f401` and `blackpill_f411`.)
The EEPROM emulation support is not included on purpose, because
enabling it without having a working firmware size check would be
irresponsible with such flash size (the chance that someone would build
a firmware where the EEPROM backing store ends up overlapping some
firmware code is really high). Other than that, enabling the EEPROM
emulation code is mostly trivial (the `wear_leveling` driver with the
`embedded_flash` backing store even works without any custom
configuration, although its code is significantly larger than the
`vendor` driver, which may also be important for such flash size).
From the ChibiOS HAL I2C driver pages:
After a timeout the driver must be stopped and restarted because the bus is in
an uncertain state.
This commit does that stopping explicitly on any error that occurred, not only
timeouts. As all the i2c functions restart the peripheral if necessary it is
safe to do so.
Co-authored-by: Dasky <32983009+daskygit@users.noreply.github.com>
Co-authored-by: Dasky <32983009+daskygit@users.noreply.github.com>
* Use polled waiting on platforms that support it
Due to context switching overhead waiting a very short amount of time on
a sleeping thread is often not accurate and in fact not usable for timing
critical usage i.e. in a driver. Thus we use polled waiting for ranges
in the us range on platforms that support it instead. The fallback is
the thread sleeping mechanism.
This includes:
* ARM platforms with CYCCNT register (ARMv7, ARMv8) this is
incremented at CPU clock frequency
* GD32VF103 RISC-V port with CSR_MCYCLE register this is incremented at
CPU clock frequency
* RP2040 ARMv6 port which uses the integrated timer peripheral which is
incremented with a fixed 1MHz frequency
* Use wait_us() instead of chSysPolledDelayX
...as it is powered by busy waiting now.
* Add chibios waiting methods test bench
mpaland printf implementation was abandoned in ~2019 and the fork by
eyalroz is now regarded to be the goto replacement of it. So this commit
incoporates the changes needed to use this fork in QMK.
Note that pointer ptrdiff_t is always supported since commit
51c90f93a97fdaef895783ecbe24569be0db7cb8
* Tentative Teensy 3.5 support
* Set firmware format to .hex for ARM Teensys
* Got to "device descriptor failed" by comparing with Teensy 3.6 code
* Drop down to 96MHz...
* Bump back up to 120MHz
* 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>
* avr i2c_master: Fix 1ms timeout
i2c_start() produces a minimum time_slice of 1ms for use as timeout
value.
The timer granularity is 1ms, it is entirely possible for timer_count
to tick up immediately after the last timer read and falsely trigger
timeout with a '>= 1' comparison.
* avr/drivers/i2c_master: Use timer_elapsed()
* Fix platforms/avr/drivers/ws2812.c
`platforms/avr/drivers/ws2812.c` has been changed to use `DDRx_ADDRESS()` and `PORTx_ADDRESS()` instead of `_SFR_IO8()` in #8646. To use them, `#include <pin_defs.h>` is required.
## Error Log
* create new keyboard
```shell
bash-3.2$ qmk new-keyboard
Ψ Generating a new QMK keyboard directory
Name Your Keyboard Project
For more infomation, see:
https://docs.qmk.fm/#/hardware_keyboard_guidelines?id=naming-your-keyboardproject
Keyboard Name? ws2812_test
..................................
36. WB32F3G71
Please enter your choice: [12]
Ψ Created a new keyboard called ws2812_test.
Ψ To start working on things, `cd` into keyboards/ws2812_test,
Ψ or open the directory in your preferred text editor.
Ψ And build with qmk compile -kb ws2812_test -km default.
```
* Enable RGBLIGHT.
```shell
bash-3.2$ echo RGBLIGHT_ENABLE=yes >> ./keyboards/ws2812_test/rules.mk
bash-3.2$ echo '#define RGB_DI_PIN B1' >> ./keyboards/ws2812_test/config.h
bash-3.2$ echo '#define RGBLED_NUM 6' >> ./keyboards/ws2812_test/config.h
```
* Compile
```shell
bash-3.2$ make ws2812_test:default
QMK Firmware 0.16.9
Making ws2812_test with keymap default
avr-gcc (Homebrew AVR GCC 8.4.0_2) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
.....................
Compiling: quantum/process_keycode/process_rgb.c [OK]
Compiling: platforms/avr/drivers/ws2812.c platforms/avr/drivers/ws2812.c: In function 'ws2812_setleds':
platforms/avr/drivers/ws2812.c:40:5: error: implicit declaration of function 'DDRx_ADDRESS' [-Werror=implicit-function-declaration]
DDRx_ADDRESS(RGB_DI_PIN) |= pinmask(RGB_DI_PIN);
^~~~~~~~~~~~
In file included from <command-line>:
./keyboards/ws2812_test/config.h:21:20: error: 'B1' undeclared (first use in this function); did you mean 'PB1'?
#define RGB_DI_PIN B1
^~
platforms/avr/drivers/ws2812.c:40:18: note: in expansion of macro 'RGB_DI_PIN'
DDRx_ADDRESS(RGB_DI_PIN) |= pinmask(RGB_DI_PIN);
^~~~~~~~~~
./keyboards/ws2812_test/config.h:21:20: note: each undeclared identifier is reported only once for each function it appears in
#define RGB_DI_PIN B1
^~
platforms/avr/drivers/ws2812.c:40:18: note: in expansion of macro 'RGB_DI_PIN'
DDRx_ADDRESS(RGB_DI_PIN) |= pinmask(RGB_DI_PIN);
^~~~~~~~~~
platforms/avr/drivers/ws2812.c:42:47: error: implicit declaration of function 'PORTx_ADDRESS' [-Werror=implicit-function-declaration]
uint8_t masklo = ~(pinmask(RGB_DI_PIN)) & PORTx_ADDRESS(RGB_DI_PIN);
^~~~~~~~~~~~~
In file included from /usr/local/Cellar/avr-gcc@8/8.4.0_2/avr/include/avr/io.h:99,
from /usr/local/Cellar/avr-gcc@8/8.4.0_2/avr/include/avr/interrupt.h:38,
from platforms/avr/drivers/ws2812.c:24:
platforms/avr/drivers/ws2812.c: In function 'ws2812_sendarray_mask':
./keyboards/ws2812_test/config.h:21:20: error: 'B1' undeclared (first use in this function); did you mean 'PB1'?
#define RGB_DI_PIN B1
^~
platforms/avr/drivers/ws2812.c:167:69: note: in expansion of macro 'RGB_DI_PIN'
: "r"(curbyte), "I"(_SFR_IO_ADDR(PORTx_ADDRESS(RGB_DI_PIN))), "r"(maskhi), "r"(masklo));
^~~~~~~~~~
cc1: all warnings being treated as errors
[ERRORS]
|
|
|
make[1]: *** [.build/obj_ws2812_test_default/ws2812.o] Error 1
make: *** [ws2812_test:default] Error 1
Make finished with errors
```
* change include order
* chibios/timer: Move the 16-bit timer handling into a separate function
Extract the code which effectively makes a 32-bit tick counter from a
possibly 16-bit ChibiOS system timer into a separate function. Does
not really change the behavior of the timer API, but makes the actions
done in `timer_clear()` and `timer_read32()` more obvious.
* chibios/timer: Rename some variable to better reflect their role
* chibios/timer: Fix 32-bit tick counter overflow handling
The QMK timer API implementation for ChibiOS used a 32-bit tick counter
(obtained from the ChibiOS system timer) and then converted the value to
milliseconds to produce the timer value for QMK. However, the frequency
of the ChibiOS timer is above 1000 Hz in most cases (values of 10000 Hz
or even 100000 Hz are typically used), and therefore the 32-bit tick
counter was overflowing and wrapping around much earlier than expected
(after about 5 days for 10000 Hz, or about 12 hours for 100000 Hz).
When this wraparound happened, the QMK timer value was jumping back to
zero, which broke various code dealing with timers (e.g., deferred
executors).
Just making the tick counter 64-bit to avoid the overflow is not a good
solution, because the ChibiOS code which performs the conversion from
ticks to milliseconds may encounter overflows when handling a 64-bit
value. Adjusting just the value converted to milliseconds to account
for lost 2**32 ticks is also not possible, because 2**32 ticks may not
correspond to an integer number of milliseconds. Therefore the tick
counter overflow is handled as follows:
- A reasonably large number of ticks (the highest multiple of the
ChibiOS timer frequency that fits into uint32_t) is subtracted from
the tick counter, so that its value is again brought below 2**32.
The subtracted value is chosen so that it would correspond to an
integer number of seconds, therefore it could be converted to
milliseconds without any loss of precision.
- The equivalent number of milliseconds is then added to the converted
QMK timer value, so that the QMK timer continues to count
milliseconds as it was before the tick counter overflow.
* chibios/timer: Add a virtual timer to make 16-bit timer updates more reliable
The code which extends the 16-bit ChibiOS system timer to a 32-bit tick
counter requires that it is called at least once for every overflow of
the system timer (otherwise the tick counter can skip one or more
overflow periods). Normally this requirement is satisfied just from
various parts of QMK code reading the current timer value; however, in
some rare circumstances the QMK code may be blocked waiting for some
event, and when this situation is combined with having a rather high
timer frequency, this may result in improper timekeeping.
Enhance the timer reliability by adding a ChibiOS virtual timer which
invokes a callback every half of the timer overflow period. The virtual
timer callback can be invoked even when the normal QMK code is blocked;
the only requirement is that the timer interrupts are enabled, and the
ChibiOS kernel is not locked for an excessive time (but the timer update
will eventually work correctly if the virtual timer handling is not
delayed by more than a half of the timer overflow period).
Keeping a virtual timer always active also works around a ChibiOS bug
that can manifest with a 16-bit system timer and a relatively high timer
frequency: when all active virtual timers have delays longer than the
timer overflow period, the handling of virtual timers stops completely.
In QMK this bug can result in a `wait_ms()` call with a delay larger
than the timer overflow period just hanging indefinitely. However, when
the timer update code adds a virtual timer with a shorter delay, all
other virtual timers are also handled properly.
* Create a build error if no bootloader is specified.
* Update builddefs/bootloader.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Don't make EEPROM size assumptions with dynamic keymaps.
* Add support for checking against emulated flash, error out if someone attempts to build a board without specifying EEPROM size.
* Reorder defines so that MCU is considered last.
* Refactor EEPROM definitions for simplicity.
* Fix max sizing of kabedon/kabedon980.
* Fix max sizing of mechlovin/olly/jf.
* Fix unit tests.
* Review comments, add messages with values during build failures.
