Firmware refactoring for digital inputs

[GioCC]

Looking at the current firmware code (also including coming input shifter management), I noticed that every source for digital inputs (buttons, encoders, input shifters...) has the very same mechanisms in place after the actual data is read:

• store data in private buffer
• check difference with previous data
• invoke callback.

Callbacks seem very redundant:

• bound to objects, while they could be static
• usually, there is a callback entry for different events - which in a general case might make sense - but all entries point to the same function (eg. btnOnRelease->handlerOnRelease, btnOnpress->handlerOnRelease). Encoders have 4(!) callbacks each, all pointing to the same function.
• callback functions mostly do the same thing and could be replaced with a single common function.

Besides, every input "block" type has its own buffer with its management functions, mostly all very similar (if not the same).

Proposal:

For consistency, all (digital) inputs from any source could be written to a common buffer (let's call it a "flag" buffer to distinguish them from physical inputs); the change detection and reporting could be run just once, by a single function, on this buffer.

This way the information about the source of the flags is lost, but I see no reason why an input coming from a button should be treated differently from one coming from a shifter or e.g. a multiplexer.

Some sensitive inputs (encoders) could still be read/scanned more frequently.

I have more details figured out (and tested classes ready to use), but they can be discussed later.

I believe there are several merits to this changes in implementation:

• memory gain (both flash and RAM)
• more modular structure
• clearer code

On a related note, this would also benefit the implementation of Multiplex support.

As correctly pointed out on Discord, of course this should wait until after support for input shifters is finally merged.

[neilenns]

Sounds promising!

[elral]

While thinking about a key matrix and setting this up I also realized that a "central" storage of all inputs would be helpfull. In the end I came also up with a "bit array" where all inputs are representd by one bit. As far as I remember a class was always presented by Edwardz(?) in the development channel from discord (unfortenutelly I lost the link). An easy and fast! solution should be set up w/o high effort.

But this would mean that the button and encoder routine must be split up. The values must be read in the required time frame (10ms buttons, 1ms encoders) from the bit array, within the main loop() the digital I/O's must be read and stored into the array. Same for the shifters, they must be read "continously" there values into the array, and the button routine can also read these "vituell" pin numbers. There must be only once a definition which input device writes into which bit in the array.
A little bit concerned am I about the encoders as there inputs should be read every ~1ms. Some more investigations about the timing in regard of input shifters are required.
Same would also apply to other input methods like e.g. input shifters and keymatrixes. Once defined in which position in the "bit array" they are stored they can be used like a normal button.

Special care has to be taken on the max. size of the configuration, espacially at the promicro. This will limit the number of inputs. Assuming 20 bytes are required for each button (name, pin and overhead) and increasing the config size to 512 Byte (promicro) the max number of buttons are 25 unless "other" inputs (shift register, MPX, keymatrix) transfer only a "general" name (shifter xyz) and the pin number. But this would make the requirement for a "bit array" obsolete ;)

[GioCC]

Hi @elral ,
in the light of more recent developments, I think that this proposal of mine is no longer convenient (if at all applicable).
Most of the issues related to callbacks are now solved in other ways; and this issue (as is also apparent from your considerations) is also bound to the other topic about the naming problem.
I promise will try and elaborate further as soon as I have a little time.