Added support for TM1637

[GioCC]

Requires firmware including modified display library "LedControl_Dual" (branch: MOD_TM1637_DualLib).
Solves [closed] issue #514 (changed to discussion #604.

[github-actions]

Build for this pull request:
MobiFlightConnector.zip

[GioCC]

Note:
in ComboBoxHelper.cs, the first argument of reassignPin(...) has been changed in order to better handle the peculiar cases of the modified display panel; now it directly takes the pin number (as a string) rather than the ComboBox it belongs to (which was involved for the sole purpose of getting that string).
The function purpose is also definitely cleaner this way.
This however required the invocation in all other involved panels to be modified, resulting in an increase in the number of changed files although the change there is minimal.

[github-actions]

Build for this pull request:
MobiFlightConnector.zip

[github-actions]

Build for this pull request:
MobiFlightConnector.zip

[GioCC]

An important point posted in the Discord channel:
I expect the max number of configurable displays to be a somehow controversial point.
RAM is not actually a constraint in this case; the number could be easily extended to 6 or more.
The real conundrum is that MAXes are chainable, so having 4 "devices" (Mega and Pico; 1 for other boards) really means having 4 chains of 4 physical modules each, which is plenty. Even for other boards, where the limit is 1, 4 physical modules are usually enough.
The problem in extending this number for MAXes is that the data transfer time becomes very long; for every single digit to be changed, a very long sequence must be transmitted, so IMHO even a 4-device chain should be preferably avoided, let alone having many of them.
On the other hand, TMs can't be chained (so they don't have the above issue), therefore a higher maximum number of devices - I'd say 8 or more - is practically compulsory; but it's apparent that allowing such a high number of displays whatever the type could cause unpleasant problems to the unaware user.
I haven't found an answer to this problem as of yet, so I would gladly accept any idea or suggestion.

[elral]

An important point posted in the Discord channel: I expect the max number of configurable displays to be a somehow controversial point. RAM is not actually a constraint in this case; the number could be easily extended to 6 or more. The real conundrum is that MAXes are chainable, so having 4 "devices" (Mega and Pico; 1 for other boards) really means having 4 chains of 4 physical modules each, which is plenty. Even for other boards, where the limit is 1, 4 physical modules are usually enough. The problem in extending this number for MAXes is that the data transfer time becomes very long; for every single digit to be changed, a very long sequence must be transmitted, so IMHO even a 4-device chain should be preferably avoided, let alone having many of them. On the other hand, TMs can't be chained (so they don't have the above issue), therefore a higher maximum number of devices - I'd say 8 or more - is practically compulsory; but it's apparent that allowing such a high number of displays whatever the type could cause unpleasant problems to the unaware user. I haven't found an answer to this problem as of yet, so I would gladly accept any idea or suggestion.

I would increase the max number of displays to 6 (or 8?) so that more than 4 TM1637 displays can be connected. For the MAX displays I would give a clear statement in the wiki, that the max numbers of devices should be limited. For now we can connect up to 4 x 4(daisy chained) = 16 displays. This would mean that the limitation should be still 16 displays (what I think it could be still too much), that could be 8 devices each daisy chained with 2 displays, or 6 devices with 4 devices and 3 daisy chained plus 2 devices with 2 daisy chained. According the formula devices multiplied with daisy chained displays must not exceed 16.
At least for the MAX displays we are backwards compatible.

I still do not now how many displays would be sensefull on 1 board. I see it in the way that 1 board should be used for one instrument (COM, NAV, ...). So even 16 would be much to high, but haven't figured out what the max numbers would be by using this logic

[github-actions]

Build for this pull request:
MobiFlightConnector.zip

[github-actions]

Build for this pull request:
MobiFlightConnector.zip

[DocMoebiuz]

This PR was superseded by #1325

Thank You @GioCC