* Refactor and document the Watchdog driver to make it more readable.
Fix the configuration of the behaviours configuration that was not properly implemented (but it didn't cause any side effect since the correct value was eventually set in NRF_WDT->CONFIG).
Fix the wrong interpretation of the reset reasons caused by implicit conversions of int to bool.
New implementation of the heart rate sensor data processing using a frequency based PPG algorithm.
The HRS3300 settings are fine-tuned for better signal to noise at 10Hz.
The measurement delay is now set to 100ms.
Enable and use the ambient light sensor.
FFT implementation based on ArduinoFFT (https://github.com/kosme/arduinoFFT, GPLv3.0).
Replace custom FreeRTOS inactivity timers with LVGL inactivity timers.
DisplayApp: Trigger display activity on timer done.
inactivity: Add additional checks
The backlight could be turned on by RestoreBrightness() on ble connect
event.
inactivity: Trigger activity on screen switch
A notification timing out could put the watch to sleep immediately.
While this could be ideal behaviour, it was caused by delay in
processing the EnableSleeping event and pushing RestoreBrightness to
DisplayApp.
Fixes#1467 "Double tapping PineTimeStyle steps style button sends watch to sleep"
Double tap is disabled on the color settings screen by checking if the Rnd button is visible, but this didn't work for the options screen as the Rnd button isn't visible. I've changed it to check if the Close button is visible instead, which is used on both settings screens, and resolves the bug. I also changed the button used to disable the long press behaviour which was an as-yet-undiscovered bug which would have allowed the long press action to be used when the options screen was visible.
I don't think this badge has shown the actual status of the current
workflows for a long time. The real status can easily be seen by
clicking on the checkmark or cross icon on the front page. It's also
supposed to show the status of the master branch, not develop (default).
Previously, the LVGL driver for the filesystem was initialized in the class FS. However, since 6f942e2, the order of the initializations was incorrect : the driver was initialized (FS::LVGLFileSystemInit()) before LVGL (LittleVgl.Init()), which means that the driver registration was probably dropped when LVGL was initialized.
The LVGL driver is now initialized in LittleVgl.Init(), which seems to make much more sense, since all LVGL drivers are initialized there. This way, we ensure that the initialization of the drivers is consistent.
