Proposal: Define i2c ops with text config rather than new code #341
Description
One of the most frequent avenues for customization of the Teletype firmware lately has been adding new i2c ops. This is a) awesome but b) clearly unsustainable; either the core firmware grows to support all possible devices, or individual forks develop to support new devices and users have to curate their own fork with the various patches necessary to support the collection of hardware in their rack.
A proposal to head either of these futures off: recognizing that most of the i2c code is quite similar, we move it all from individually implemented C functions to a config-driven generic I2C implementation that still allows for custom OPs but allows alteration/expansion without rebuilding the firmware.
This could work something like this:
- Individual I2C op definitions are removed from the C source and replaced with one or more i2c-operation meta-handlers that:
- optionally scale inputs to wire format
- send N bytes including provided constants
- optionally receive M bytes
- optionally scale and return response
- A config struct is held in NVRAM that lists op names and what input arguments should be fed to the meta-handler.
- This config struct is parsed from disk, similar to a scene file. The usb disk menu gets a new option "load i2c config" which parses a file from the usb storage and loads it into NVRAM/RAM if parsing succeeds.
- Users who want to add support for new i2c hardware can name and construct new OPs by adding additional lines to the config file without writing any C code.
- There will be a reasonable upper bound on the total number of ops that can be defined at once, so users can choose the subset that matches the hardware in their setup.