Draft for discussion: how to manage multiplexers (MPXs) in MobiFlight

[GioCC]

Why MPXs should be used:

First of all, all points below have the potential to add a great deal of flexibility, without upsetting the existing architecture so much.
However, the most relevant reason would probably be the fact that MPXs are extensively used by RealSimControl AKA SimVim (more details in another discussion), but also in existing cockpit installations or devices.

How MPXs can be used:

There are different ways with growing flexibility (not necessarily also growing complication).

1. The simplest way would be to use MPXs as input multipliers, similarly to shift registers.
   They cannot be used as output multipliers, since their outputs are not latched and therefore not permanent.
   Note that MPXs are also suitable for analog inputs.

2. MPXs could be used to route driver lines for input/output shift registers, thus multiplying inputs (and outputs!) even further;

3. they could be used to route driver lines for other I/O peripherals, most notably MAX7219 (or other) display adapters.

4. they could also possibly be used for peripherals like servos and steppers, but I haven't investigated these enough as of yet.

Theoretically, all peripherals* which have their own Arduino I/O pin assigned could be routed through MPXs (single digital inputs, single analog inputs, shift register I/Os, display drivers..., but not e.g. I2C peripherals); however, actual support may be limited to just some of the use cases above, for convenience reasons, or implemented gradually.
* even an individual input is here considered a "peripheral".

How MPXs can be driven:

• A group of 4 pins is designated in the configuration as common selector for all connected MPXs*;
  the root terminal of each MPX (which can be inbound or outbound) is assigned to a dedicated pin.
  * options for selector pins: fixed allocation vs user-defined; adjacent vs free; 4 vs (possibly) less than 4.

  In this way, every peripheral attachment point (i.e. pin) could be "multiplied" up to 16 connected peripherals, each corresponding to a different channel.

• For SPI-type peripherals driven through a set of Data / Clk / Latch signals, (e.g. MAX display drivers, input or output shifters, LED drivers etc), only one of the three signals is routed through the MPX; the other signals have to be in common with all peripherals (see other discussion).

How MPXs could be configured:

• In the configurator program, every supported peripheral could have a checkbox that indicates if it's attached to a MPX; if it is checked, a set of 16 radiobuttons* is enabled that specifies to which channel of its MPX that peripheral is connected.
  If it's not checked, it means that the peripheral is connected directly to an Arduino pin and it's handled exactly as currently done.

  MPX support could also be globally disabled: in this case, nothing would need to be changed, except that MPX channel #0 can be implicitly assigned wherever it is referenced.

* or less, depending on the number of selector lines

[GioCC]

This discussion might be more relevant to the Mobiflight-FirmwareSorce repository; I posted it here to avoid scattering, please advise if it should be moved.

[neilenns]

What kind of multiplexers are you thinking about with this proposal? There are several options and I believe they all have slightly different capabilities. For example I'm playing with MCP23017s right now and they definitely could be used for output as their output value stays constant once you set it.

I think the biggest decision that has to be made regarding multiplexers is what their purpose is. Are they intended to:

1. Support more LEDs and buttons?
2. Support "virtual" pins that could be used as pins for any device supported by MF (e.g. servos, encoders, I2C displays, etc.)

#1 would be relatively straightforward and mimic the existing output and (hopefully soon) input shifter behaviour. #2 is an idea floated by @DocMoebiuz but would likely require deep changes across the desktop and firmware source to pull off.

[neilenns]

How would an encoder know to use pins on the multiplexer instead of pins on the Arduino?

[GioCC]

Very relevant observation. However I'd like to reply by dodging the question 😄: I would be inclined to limit encoder connections to direct pins, since otherwise keeping timings under control would become a problem.

[GioCC]

This is also matter for another topic. In the past I suggested a common "flag repository" that could collect the status of all inputs, wherever they would come from; this would have made answering to your question easier.
However, I grew convinced that now this is no longer convenient (if at all applicable), and every I/O block should manage its own status data. Maybe this can be discussed separately in detail, though I'm afraid it has mostly become academic.

[neilenns]

Replace encoder with SPI-type peripheral it is the same question 😁 How would those devices know to use pins on the multiplexer instead of pins on the Arduino? Even if you go with the proposal of two shared pins across all SPI devices and change the firmware code to always use those, there's still the third pin that's specific to each peripheral. How would it know that third pin is routed via the multiplexer instead of physical Arduino pins?

[GioCC]

It wouldn't [need to] know. 😁
In the configuration, devices are assigned to an MPX channel (stored as one of their parameters); this means that, when their polling function is called (with the currently selected channel as argument), it only does its job - transparently - if the current channel matches their own, otherwise it returns with no effect.

I probably forgot to mention that the MPX channels should be scanned sequentially, selecting a new channel every iteration of the main loop; every pass would poll all peripherals, but only those associated with the current channel would "respond".

As a border case, peripherals not attached to an MPX (or direct pin I/Os, for that matter) could have a "wildcard" value assigned, which means that they can/should be scanned at every iteration. (Or, they could also have a "valid" channel number even without being attached to an MPX, in order for them to be polled with the same frequency as MPX'd devices)