Draft for discussion: Implicit I/O naming

[GioCC]

What is meant by implicit I/O naming

Currently, I/O lines are assigned user-defined names, which are used in some cases to identify and reference those lines for message exchange and processing.
These user-defined names are stored in the configuration (for later retrieval), but also in the Arduino working memory, and must remain available to be used as above.

However, for the purpose of operations, a naming scheme derived exclusively from the line attributes (e.g. assigned pin...) could be defined.

The advantages:

• Automatically generated, nothing to retrieve from storage (thus less working memory used)
• Unambiguous
• Shorter (possibly)
• No change required for new peripherals

Possible drawbacks:

* User-defined names are no longer required, except as labels in the configuration program; therefore, they would no longer be kept in the Arduino configuration copy, which in turn would not be fully comprehensive.

Naming proposal

I/O line names are used when reporting I/O events (whether incoming or outgoing).
They can be uniquely identified by a set of values including:

• Physical connection pin to the Arduino
• Index of the subchannel within the I/O block, if any (e.g. for input shift registers: input # within the block of inputs, 0 to N-1)
• MPX channel

(MPX management is already considered here.)
Ideally, the "MPX Channel" value (which would range from 0 to 15 for MPXs) could also conveniently double as address for I2C peripherals, allowing a seamless addressing of I/O expanders.

It would be also desirable to plan in advance for an input matrix arrangement (shoud it ever be considered interesting); however I haven't figured out a good solution for that yet, because it would probably also depend from its type of connection (using I/O expanders? MPXs? Direct inputs? Any of the above?)

This information can be sent as a set of integer values, or even better as a uniform string collecting all individual codes: for example, something along the lines of

I43.25@02

could mean

digital "I"nput, input block connected to pin #43, 25th input in block, block belonging to MPX channel #2.

This string would take the place of the user-assigned name currently exchanged.

This string (but the actual syntax is just an example) could be used as-is for the exchange in serial messages, or encoded differently; the important part is that all these pieces of information are present in a consistent, easily decodable form.

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

I'm not sure I quite understand this proposal. When you say "I/O lines are assigned user-defined names" do you mean modules rather than lines? At the moment names are given to modules, not the individual pins used by the modules. For example if I define an encoder and call it "COM1" the encoder that's the name for the encoder, not the two pins used to read the encoder.

I find naming modules incredibly helpful as a user as it means when I create the output and input configs I can easily tell in the dropdown which connected device I want to use for that output or input.

The only place where I see names getting exchanged for actual IO lines is in the output shifter implementation, but even there it isn't stored in the configuration, it's only used to identify which line should get turned on/off.

[GioCC]

You're perfectly right, names are actually assigned to the modules - what I had in mind is that, as you point out, these names are still used in "tagging", thus identifying, the individual lines.

I was exactly thinking about the shifter example; it is possible that I'm mistaken about other peripherals, I already had a little mix-up about this matter during an exchange in Discord and I haven't had the time since for a more thorough check.

[MobiFlight-Admin]

@GioCC - thanks for sharing this idea. I explicitly wanted always that a user can give a meaningful name to the devices that one creates. HW-Pins themselves cannot be names, they are derived from the name that the board's data sheet provides for them and what is typically printed on the board.

This yields the best UX because the HW pin names are easy to relate to their physical counterpart and the user can later give meaningful names to the devices.

Configuration is stored completely on the board. This is also required for better sharing of configurations - only if device names and MF app config correspond correctly a config set can shared with others.

For the shifter i am OK with auto-generated pin names, only requirement that is easy for the user to tell to which shift register these pins belong.

[GioCC]

@MobiFlight-Admin,
from your reply, I suspect that I failed to underline one point.

The "auto" names would only be used for data exchange.

User-assigned names:

• would definitely still exist as currently;
• could still be stored - and obviously retrieved - in the configuration data stored on the Arduino; only, they would not be regarded by the firmware for operation. Even if keeping them stored in the Arduino comes as a penalty for space, I understand the value of configuration integrity (and agree with it).

The user would not be aware of any change (nor deprived of any convenience):

• user-defined names would still be assigned and recognized in configurations;
• in logs, when printing message entries, the software (on the PC side) could easily retrieve the user-assigned names.
  There is an additional perk for debugging, because the "auto" name would also report the physical reference for the I/O, which may help recognize some discrepancies.

[elral]

So far what I understood this goes into the direction what Sebastian and I discussed some time ago to reduce the serial traffic.
Instead of sending in case of an event the complete name of the device it would be sufficient to send the corosponding pin number. As the complete config is stored in the eeprom and read out after the connector has connected, the relation between pin number and name is known to the connector. In case of setting up, the user defines still his configuration and it is transfered and stored in the eeprom. The user will not see any difference.

Reading the configuration on the board should be set up in a way that the names are not read into the RAM as they are not needed anymore. This will save memory which could be used for more (input) devices. With the new FW version 1.12.0 the config is transfered directly out of the eeprom, so also no need to have the names in the RAM.

[GioCC]

Thanks @elral,
yes, I would say that this pretty much sums it up!
As far as I could see, in general incoming data (ie outputs) are already based on pin numbers without any reference to the names; in the opposite direction (input events), names are still used (but they could easily be disposed of).
I would just add that the reduction of the serial traffic is not the only goal.
I think it's important to set a convention, not so much for the literal names themselves but for their structure, in order to be sure that I/Os do no longer depend from user-defined names or other non-intrinsic references. And in the process, it would be beneficial if the multiplexer references would also already be included.
I understand from your comment that this has, at least in good part, already been discussed; unfortunately I wasn't aware of that, but fortunately this could mean this topic will be easier to consider.

[GioCC]

I changed the original formulation of the proposal; I got the text from a notice I made some time ago for myself and didn't notice that it was actually misleading (or quite incorrect). I also updated it with a few considerations.