Button presses are polled, not interrupt-driven

[rdancer]

This project will need substantial rewrite. The wireless project also?

The processing seems to use single thread, one dispatch loop that polls RTC and every 100ms or so polls UART data; every 20ms or so polls for a button being pressed.

There seems to be something weird going on as well. Pressing fast repeat:

• up/down buttons are processed reliably on Home Screen
• in Home Screen field editing the power button loses some presses
• In settings, the menu button is unreliable & up/down loses presses

[rdancer]

The processor supports various flavours of interrupts

Unsuitable:

• RTC periodic interrupt has resolution of 1s
• ditto RTC alarm interrupt

Interesting:

• Out of Range Comparator
• Analog Comparator

[rdancer]

• SW102 (nRF51) and wireless controller (nRF52) can use Nordic SDK GPIOTE abstractions (in C).

• 850C & 860C use the GigaDevice GD32F103xx SoC, which is not well documented, and only in assembler. Problem being, ARM only half-standardises its interrupt handling for GPIOs, and vendors are supposed to provide the other half. We do have some interrupt handlers in our codebase, so maybe a question of finding out if there is some GPIO input sample code in wherever those pieces of code came from, and guessing based on disassembled code. There has to be some code somewhere, either source or binary that can be disassembled.

• Mbed OS provides some abstraction for GPIO input interrupt, it seems; should we port our codebase on top of it, would that work? Do we even have enough flash/RAM? Can we borrow some of their libraries?

We only need input on GPIOs, and only for four buttons at a time. Could add more buttons, though, say a dedicated lights or cruise button. What we are doing is basically implementing a keyboard controller on the main CPU, which normally would be handled by a separate IC that would expose a nicely ordered byte stream of keystrokes, with a short buffer, and a single interrupt when there were keystrokes available. We can easily do this on the microcontroller, because no-one is gonna strike 60 words per minute on the keypads we use, and because key handling is low-compute-intensive on 2021 hardware. But we still need to do it at a higher priority than the normal code, and we still need to provide a nicely ordered keystroke buffer, and a single interrupt when there are keystrokes available. Or maybe we can directly execute event handlers, and swap the event handlers in and out depending on context, at least for some keystrokes:

• long-press <+> -> ui_vars.ui8_lights = !ui_vars.ui8_lights ? true : false
• press <+> -> ui_vars.ui8_assist_level = min(ui_vars.ui8_number_of_assist_levels, ui_vars.ui8_assist_level + 1)
• etc.