Draft for discussion: Aggregation of driver lines for I/O peripherals

[GioCC]

What does it mean

Currently, the driver lines for an I/O block in Mobiflight can be assigned freely to (almost) any yet unused Arduino pins.
This has several drawbacks:

• Pins having similar functions (e.g. clock) are needlessly repeated for every block
• Software drivers must be used, rather than exploiting Arduino hardware peripherals where possible

How this can be changed

Several types of serial peripherals (Shift registers, LED drivers, Display drivers...) use the very same set of signals (basically three: Data, Clock, Latch/Select)*.
Only one of these three signals needs to be different and specific for each component; the remaining two can be handled in common, without interference.

Using common lines in MobiFlight is a point worth seriously considering; the firmware is already I would say almost 95% compatible, the only relevant change would be to modify the configurator in order to enforce correct pin assignment in a user friendly fashion.

* Their working logic is not necessarily identical between components, but it is for all most common components, and all currently used ones.

Choice of common lines / individual line

Normally, the Latch/Select signal is the one that is singled out; however, if compatibility with the SimVim/RealSimControl system is desired (which uses exactly this type of common line handling), the peripheral-specific signal would necessarily have to be the CLK line.

Also note that compatibility with SV/RSC would also require all display drivers and output shifters to share common Data and Latch lines (input shifters are not supported there because MPXs with direct inputs are deemed sufficient in their place).

Choice of the assignment of common pins

The pin assignment for the two common lines could either be chosen by the user or fixed.
The first option doesn't really make much sense, and besides, the chosen pins should be marked as "shared" and treated in a somehow different manner with no real benefit.

If these lines were assigned to pre-determined, fixed pins, however, they could be assigned to the pins corresponding to the hardware interfaces of the Arduino; this would open the possibility of using said hardware interfaces (or still software drivers, or even both) whenever possible.
This would bring a gain in speed and possibly in ease of handling.

For further optimization, pins used for a certain category of peripherals (e.g. SPI, MPXs) could be released if no peripheral of that category is used.

[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]

Interesting idea! Enabling sharing of these lines seems like a straightforward way to free up more pins for use by other devices.

Could the solution be as simple as just allowing users to select already-used pins in the dropdowns in the desktop app? I think some slight firmware changes would be required too, but not much. It would also resolve this user experience issue: #573

The downside to a simple solution like this is potential new user error, accidentally using the same pin for more than one LED for example (which is why I assume the current experience exists, to guard against that).

[neilenns]

I looked in the firmware and it turns out that some devices check for prior pin usage but others don't. Buttons do, which is fine since it doesn't make sense to have multiple buttons use the same pin. But output shift registers, interestingly, don't have this test.

It seems like a targeted change to enable this would be to modify BindMobiFlightFreePins() to take an extra "showUsedPins" parameter that specific module types could enable. So output shifters, input shifters, and multiplexers (which are advanced devices anyway) could show existing used pins, but other simpler devices like LEDs and buttons could hide them.

Or just always show all pins on the desktop (with the associated potential for user error), and modify the firmware to stop tracking used pins entirely (which would have the added bonus of freeing up some more space in the firmware).

[GioCC]

I am not quite sure this "double standard" would be necessary.

If driver lines are aggregated, every peripheral - be it a single I/O, a shift register, a display driver, etc - would have its own, one assigned pin, and that pin would be marked as occupied just like now.

That would be good, since I think having to leave the possibility of "illegal" choices to the users would raise quite a lot of issues.

There would be a difference though if MPXs are used:
for instance, if pin X is assigned to an input for MPX channel n, it should no longer be shown when trying to assign another I/O for channel n, but it should be shown for channel m.

BTW, as far as I can recall, most of the checks on pin assignment consistency are made in the configurator (correctly, since it is easier and allows to unburden the firmware).

[GioCC]

(Regarding issue #573, I left a comment there)

[MobiFlight-Admin]

Hello guys - i don't understand the benefit of re-using one CLK line over having the total freedom of assigning pins to their respective IC/Driver.

In my opinion this sounds like restricting the user convenience with an optimization that is not really needed so much.

Convince me of the benefits, i am open to listen carefully to your reasoning.

[GioCC]

Hi Sebastian, thanks so much for chiming in.

One thing to point out before replying: it's not just a single line that is reused, there is a single "owned" line for the peripheral (for the lack of a better term, please help me out if you have a suggestion), of course freely assigned, and all other lines are common (two for SPI-like peripherals, but e.g. four for multiplexers).

As for the benefits:
I would have little to add to what already written: mainly, several additional free pins (eg with two displays and two shifters = 8 additional pins).
And, if compatibility with SimVim - even if only to a certain degree - is a topic that shoule eventually be addressed (or is it?):

Also note that compatibility with SV/RSC would also require all display drivers and output shifters to share common Data and Latch lines

Admittedly this change is not really needed, but so are all changes that "only" bring any less than substantial improvement.

As for the drawbacks:
how far user convenience is restricted is IMHO debatable.
Why would a user really want to connect a driver line to pin n rather than to an assigned pin m?
Why would a user really not want to connect a driver line together with other lines with the same function?
The only reason I can think of is because he wants to use an already existing, hard-wired PCB board. But what is the practical incidence of that use case?
What advantage would the "total freedom" actually bring?

For completeness, I could say that beside the mentioned options (common driver pins with fixed assignment; common driver pins with free user-defined assignment) the current option could also be maintained as an alternative; but then the software would have to introduce not-so-trivial consistency checks for pin sharing in order to allow the proposed case of grouping (and the advantage of possibly using HW interfaces would probably be lost). I did not mention this case because it seemed overcomplicated and hardly worth the effort.

[GioCC]

After some time has passed - and many improvements have been added to the system - I think this discussion is still current and should be revived.
Regarding the advantages (and the lack of drawbacks), I think my last reply above to @MobiFlight-Admin 's comments is still valid.

The solution I have in mind would be very easy to implement, below is a quick summary.

(Edit) IMPORTANT: this solution refers to the options with control lines freely chosen by the user; the above "fixed pins / hardware peripherals" option would not be exploited (although still open for a later change if required).

• as currently, any suitable pins could still be chosen for control lines, and there could still be different sets of control lines (exactly like it is now)
• the solution would only involve the connector (and exclusively the GUI part at that), the firmware would be completely untouched
• there would be NO change at all in current mode of operation
• the only difference would be a larger set of pins that can be chosen in the drop-down menu for control lines of LED drivers/shift registers etc
• there would be no additional complication for the user whatsoever (any pin choice presented to him would be safe to use with no further caveats)
• this improvement would pave the way for the subsequent easy implementation of the connection of devices "behind" a multiplexer; that is a required and substantial step towards SimVim (RealSimControl) compatibility (with better capabilities, e.g. not just for displays but also in/out shift regs)

The only real non-trivial aspect in this solution (actually, all there is to it) is the correct identification of what pins can be defined as sharable and presented to the user in the GUI, but after some thought this would be all it takes.

I would appreciate your comments; I'd be glad to go further with the implementation provided that I have confirm that the proposal is favorably considered.

[simontrhodes]

What about an SPI controller device, where the user defines the clock and data lines?
When adding another device, the user could choose which SPI controller and the select pin to use.

[GioCC]

What about an SPI controller device, where the user defines the clock and data lines? When adding another device, the user could choose which SPI controller and the select pin to use.

Unless I misunderstand what you mean - I can tell you from experience that @MobiFlight-Admin does not like the introduction of "virtual" service devices only for the purpose of driving other physical devices.

We had this discussion before the implementation of multiplexer support, when I proposed a similar "controller" for the Mux selector (address generator); in the end, this has been implicitly embedded in the devices, which all have in their definition panel the reference to a same set of selector pins (that were originally supposed to be defined only once in such a "virtual" controller device).

The rationale was that this kind of devices would be confusing, or difficult to grasp, for novice users, who are supposedly more comfortable to think in terms of physical components only.

(Of course I will gladly stand corrected if @MobiFlight-Admin thinks I reported it wrong).

[simontrhodes]

It's a constant battle between novice users and power users.

I designed my PWM driver in a similar way to the multiplexors.
In the config, you have to select the chip and then the pin.

There does seem to be a standard for SPI pins:

Uno and Nano
MOSI pin 11
MISO pin 12
SCK pin 13

Mega
MISO pin 50
MOSI pin 51
SCK pin 52

Adding a new SPI device could be similar to adding an I2C device.
When adding the device, the Arduino pins are checked to make sure they aren't in use by any other device first, such as an LED or switch.

[GioCC]

I agree, this is what I mentioned as an option in the original post (the "privileged" option back then):

If these lines were assigned to pre-determined, fixed pins, however, they could be assigned to the pins corresponding to the hardware interfaces of the Arduino [...]

But admittedly, beside this being a small complication, this would also require modifying the firmware to account for the different interface used (HW or SW); dropping the Sw interface on different pins would be out of the question because of retro-compatibility.
I would personally be inclined to implement a similar solution, but I must also say I fully understand Sebastian's point of view.

[DocMoebiuz]

yes, that's correct - i was immediately reminded of the discussion i had with @GioCC - i still believe that the majority of the users doesn't think in SPI Controller and attaching different devices to it. My assumption: I want to add a device, and it will show as one device.

I think I/O expansion probably is a topic for intermediate users. So maybe we can make other assumptions about their level of understanding. However, I still prefer a flat list of devices at the moment instead of starting to nest nodes, which should be then probably the proper way of visualizing the "sharing" of the same lines.

Another reason for not doing it prominently in the UI also was that we wanted to keep the API simple for adding a device. I didn't want to make Mobiflight Connector aware of the fact that the firmware internally created a MultiplexerBus(? might be a different name) and the Multiplexer. I wanted to hide this detail inside the firmware. Therefore for every multiplexer Connector sends the same message including the repeated pin settings. Very simpel.

What we definitely could do is, similar to the approach we have now for the multiplexer (where we show the reused settings from the first multiplexer), to offer the user the option to reuse the pins from another SPI device or define new pins.

[GioCC]

starting to nest nodes, which should be then probably the proper way of visualizing the "sharing" of the same lines.

This caught my attention, because it might be need a clarification:
sharing lines in itself (i.e. basically the whole core of this proposal) would not imply nesting.
Think of current Multiplexers, which are made exactly the same way: they share the selector pins, yet the device hierarchy is flat.

[DocMoebiuz]

for some reason the comment i wrote yesterday is not visible here in the conversation:

@GioCC i think we are still checking whether a pin is already in use before attaching a new device - only the displays don't do that iirc.

[GioCC]

Yes, that's correct. The criterium should just be modified in order to include "sharable" pins with their proper roles. (BTW that's the only modification required at all).

[DocMoebiuz]

it was simply a detail i had in mind when i read the point "it requires no change to the current mode of operation"

[DocMoebiuz]

what is the benefit of using the specific pins
MOSI pin 11
MISO pin 12
SCK pin 13

over using arbitrary pins? does it require less computational resources?

[GioCC]

what is the benefit of using the specific pins MOSI pin 11 MISO pin 12 SCK pin 13

over using arbitrary pins? does it require less computational resources?

Those are the pins attached to the hardware periphral.

[DocMoebiuz]

that's clear, but i am not sure about the benefits for the software side - is it less memory consumption?

[simontrhodes]

Those 3 pins are physically connected to the on-chip SPI controller.
The only pin you can choose is SS which selects the slave device and can be any of the normal IO pins.
The SS needs to be unique for each device attached.

[DocMoebiuz]

we have three different SPI devices (7-segment, shift registers) they all work with arbitrary pins too.

My question is: what's the benefit of using the built in pins?

[GioCC]

that's clear, but i am not sure about the benefits for the software side - is it less memory consumption?

That too, also less processing overhead and possibly higher speed. However, in our case this is mostly lost because we should retain the software drivers for compatibility (unless it should be decided to use HW peripherals exclusively, which I see as unlikely).