Provide generic output device for custom hardware integration

[MobiFlight-Admin]

A user can define a custom device and send data via the serial connection to the MobiFlight firmware. It doesn´t matter to mobiflight what happens with the data but allows for more flexibility for custom hardware.

Confirmations:

• A user can extend the mobiflight firmware with the custom device implementation through a standard process
• Multiple custom devices can be added in the firmware, types don't have to be the same
• Custom devices cannot be added through the UI
• Custom devices appear in the UI like any other device
• MobiFlight Firmware with one or more custom devices will not be automatically updated by MobiFlight
• Custom devices show in the Output Dropdown and provide generic fields:
  • Payload - a string that holds all the data - the field supports placeholder replacement

Optional:

• A custom device has a "Name" which can be updated?

[elral]

A fixed number of pins, or better variable number of pins, should be possible to define. If e.g. a Display is connected which requires pins these must be marked as used to avoid double using.
The string to be transferred could be similiar to the existing one of the LCD displays, delimiters are possible with that to transfer multiple informations. The length of the string is limited to the command messenger buffer of 96 Byte including overhead! If pins for this custom device are defined the max. length of the string is reduced compared to the LCD. Once defined if a fixed number of pins will be used or a variable number the max. length of the string can be defined. Escape characters have also to be considered.
It has to be defined how to handle the max. number of custom devices. The maximum is now part of the .json file. As the custom firmware will be setup by the user, he should also setup a custom .json file where the max. numbers are defined.

[elral]

Beside the pins which could be defined it would also be helpfull to define a string within the configuration dialog which could be used for intialisation parameters of the decice.
A custom device could be used more than once on the board but might require another initialisation. Or this custom device is shared with another user and this new user needs some other initialisation of the custom device.

[elral]

One more idea while looking in my motorized axis code. The custom device might also require existing devices. So within the custom device another existing device should be added. The required pin(s) could be defined via the pin defintion, the name and other init parameters via a string.
But when doing so, the custom device has to know which x.te device is registered, to be able to access exactly this device.

As an example on a board 3 steppers are connected. The 1st and 3rd stepper is defined as always and the position is set b the connector. The 2nd stepper is initialized through the custom device. When setting a new value to the custom device, the custom device has to know that the 2nd has to get a new setpoint.
The same for Analog Input. 2 Analog Inputs are connected as always. A 3rd Analog Input is also required for the custom device. So the custom device has to know if this Anlog Input is the 1st/2nd or 3rd one (beside that there is for now no function for reading an analog value, but could be easily added).
To get this work, each function for adding a device has to report back it's number when it gets registered. Eg. void Stepper::Add(int pin1, int pin2, int pin3, int pin4, int btnPin1) is not a void function but returns steppersRegistered. The custom device can now set s position via steppers[x.teDevice]->moveTo(newPos); (x.teDevice is the return parameter from the Stepper::Add() function.

/edit: This would mean that avery (most?) Add() function in the firmware must be changed from void to uint8_t

[elral]

An update() function should also been foreseen and called from the main loop (like steppers or AnalogIn).

[DocMoebiuz]

that would be required for inputs typically, but do we need that for displays? yeah maybe.

[elral]

I am not only thinking about displays as custom devices, there could be also other devices which might require also an input.

[elral]

I wrote above:

The length of the string is limited to the command messenger buffer of 96 Byte including overhead! If pins for this custom device are defined the max. length of the string is reduced compared to the LCD.

It is correct that the command messenger buffer must not be exceeded. But defined pins are part of the initialisation and must not be considered in the payload. So it could keep the same as for the LCD.

[elral]

@MobiFlight-Admin @neilenns @GioCC and all.
I have setup a proposal for the custom device considering the above mentioned topics.
There will be 2 draft pull requests for this in the firmware repo. One pull request shows the minimum required changes to introduce a custom device. The second pull request contains additional changes which could help to setup custom devices in a more flexible way / advanced functionalities.
Further explanations are within the pull requests.
An example for this could be found under MotorizedAxis where the Custom Device works together with other devices.

[GioCC]

One more idea while looking in my motorized axis code. The custom device might also require existing devices. So within the custom device another existing device should be added. The required pin(s) could be defined via the pin defintion, the name and other init parameters via a string. But when doing so, the custom device has to know which x.te device is registered, to be able to access exactly this device.

To get this work, each function for adding a device has to report back it's number when it gets registered.

Please tell me if I got it right: the other device referenced by the custom device should be specified by the user via the parameters entered in the connector. But how does the user know (or how can he quickly read) what is the index of the required device?
Every device could report its index, but how is this information used? Should it be shown in the connector for the user to read?
If that is the case, wouldn't this all be made much simpler (and redundant) by using the ("main") pin number, rather than the index, as suggested in #207?