Commit Graph

5 Commits

Author SHA1 Message Date
Dasky
5c85271e48
Add timer_save and _restore functions. (#23887)
Co-authored-by: Sergey Vlasov <sigprof@gmail.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
2024-10-25 18:10:17 +01:00
Nick Brassel
44f1bd9b3a
ChibiOS 21.11.1 update. (#16251)
* ChibiOS 21.11.1 update.

* `uf2-tinyuf2` => `tinyuf2`

* Updated chibios-contrib, fixup preprocessor for tinyuf2 bootloader.

* Fixup keychron L433 boards.

* Makefile cleanup.

* RISC-V build fixes.

* Fixup RISC-V build.
2022-03-07 21:04:22 +11:00
QMK Bot
63646e8906
Format code according to conventions (#16322) 2022-02-12 18:29:31 +00:00
Sergey Vlasov
580ef6d88f
ChibiOS timer fixes (#16017)
* 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.
2022-02-05 05:08:50 +11:00
Joel Challis
2728603fe6
Move tmk_core/common/<plat> (#13918) 2021-11-19 10:41:02 -08:00