"Stub" device for custom peripheral boards

[GioCC]

Just a thought I had a few days ago.
It has been suggested several times that, in order to attach custom output boards (like e.g. OLED displays), the firmware can be customized by exploiting the standard messages used for the LCD, which have a plain "address+string" content and are therefore very flexible. This at least avoids the need to modify the connector.

What if we added, to both Connector and FW, a very simple device that just passes data through to the custom board via I2C or SPI (as option)?
This way, everybody could benefit from attaching his/her own custom board without any modification to the FW. The impact in terms of space in Flash/RAM would be negligible.
That's nothing really new, simply a refinement of the "LCD shortcut", but incorporated as standard option.
The idea could be later extended to include also some kind of input devices.

This is how I'd figure it:
Connector: a new device where the user can select either an I2C output (specifying an address; same std I2C pins as the LCD) or a serial output (specifying the pins like for output shifters). This device would have a completely custom string as input, similar to an LCD.
FW: The configuration message would take the parameters described above for the Connector.
For data, a specific serial message, identical to the one used for LCDs. Depending on the output channel, this message would be simply forwarded to the I2C bus or to the chosen serial pins.

[elral]

There are already some thoughts in MobiFlight/MobiFlight-Connector#331

[GioCC]

Thanks for the pointer, I had completely missed that!

I think my suggestion above could be considered an alternative variation, here's where it differs:

• A user would not need to extend the mobiflight firmware;
• Custom devices could be added through the UI (in fact they should, since the user would have no way to insert them in the configuration inside the FW)
• MobiFlight Firmware with one or more custom devices would be automatically updated by MobiFlight

That however comes with a peculiar limitation:

• the custom board should be an "intelligent" and autonomous unit (e.g. another Arduino or similar) , because it should be able to receive commands via I2C/SPI and process their logic.

This drawback is inherent to the advantage: if the custom peripheral were any "basic" IC (e.g. a LED driver chip, a graphical LCD/OLED driver, an I/O expander...) then it would most probably require a specific driver to be added to the firmware.

Several other considerations you made also apply here, e.g. the limit of custom devices that can be attached (even if in this case enforcing a hard limit might not be so important) or the limitation of the string buffer size.

Should we maybe join these two discussions in a single place?

[elral]

Should we maybe join these two discussions in a single place?

I personally would prefer this.

[GioCC]

Since this comment by @DocMoebiuz fully applies here, I'd like to comment it below.

Your vision is indeed clear, however it looks like it gives little value to having a solution that doesn't involve crafting a custom (Mobiflight) firmware; in fact this seems to be the only option you practically refer to.

Modifying the firmware does not just require a bit of best practices, it might be also an undesired annoyance because (a) it requires additional work anyway and (b) the custom firmware can't be automatically updated.

The enhancement I suggested would require very minimal changes to current SW/FW; it would also allow any developer to concentrate only with the logic of his/her own board, with no interference whatsoever to the operation of the system and keeping it fully standard.
Admittedly it's not a universal solution, and some details should still be figured out in order to also include inputs (but that's not mandatory); but more advanced use cases would then fall in the scope, and justify the effort, for a custom firmware.

Where you say above "we could even start with option 2 only", therefore, I would rather say it would make more sense to start with option 1; to be more correct, not for the nature of the option itself, but because the proposed solution (which has option 1 as a feature) would be an economical and practical first step while a standard support for custom firmware (corresponding to option 2) is figured out.

[GioCC]

For better clarity, I would add that something close can already be done with the existing system by:

• defining the custom peripheral as an LCD display in the connector;
• connecting the device mandatorily to the I2C bus (no option for SPI/serial connection)
• having the peripheral firmware detect and strip all LCD-specific commands from the data stream transmitted by the connector.