MobiFlight Community Support

Hi,
I noticed that, in the configuration panels, each display driver or shift register is required to have its own different driver lines assigned; i.e. it's not possible to share lines between drivers (for instance, CLK and DTA lines shared between several shift registers, with individual LAT lines).
I haven't had time to check the latest code yet, but chances are that this might just be a limitation in the user interface that could be implemented with (almost) no trouble in the board code and maybe even no overhead or other drawbacks.
Has this ever been discussed, and wouldn't it be worth considering?

What should be the benefit ??

May i not understand you.
Please give ma a practicable example of a Situation....

How it is currently..... What you expect to change.... And whats the new (benefit) result ?

The main benefits would be avoiding longer chains of drivers, with possible noise and sync problems, without unnecessarily wasting pins.
For instance, to drive 8 MAX displays individually, I would currently need 8x3 = 24 lines, while it could be made with 8+2 = 10 lines.

Also, it might be important in order to improve compatibility with existing hardware connected in this way (which often is, for efficiency).

It's surely not a vital requirement, but don't underestimate that the cost and drawbacks of the change should be almost zero (not checked yet, but I intend to do that briefly).

Ok, I just checked... on the firmware side, as I expected, it seems that it would be quite possible to share the pins.
Libraries for involved peripherals (basically displays and shift registers) have software drivers where driver lines are not bound to particular HW pins.

The only issue may arise in preventing accidental pin overlays where a same pin is assigned both as input and output, but this would be easy to implement with a similar check as is currently done for already "registered" pins. (BTW, this last condition is enforced for display drivers, but is missing for shift registers).

If there is potential interest for such a feature (i.e. it is not dismissed a priori), I would be happy to try and submit a modified version of the Arduino firmware on GH.

Here i´m the fully wrong guy to talk with !

May you know my other postings here and on Discord..... I´m not a fan of "save pin philospohy" . I not use Shift Registers.... If i need 200 LED then i would use 5 Megas, 40 LED each via 40 Pins each.
My basic statement.... Number of Megas is not limmited so its no mater if i need 10, 20 or 100 Megas for a Cockpit.

Where i agree.... I also not use Chains to avoid noise or long Data sets..... But again.... I not care about if my 8 Displays need 24 Pins and 2 Megas or 8+2 Pins on one Mega. Thats no factor for me.

*****

I recommend.... Talk to Sebastian (DocMoeibius) BEst way on Github directly or via Discord (Voice Chat).
In the past he also think like me and "save Pins" was not a target for him..... But in the last Year he change opinion and allow Shift Registers. So "maybe" he agree with your idea and like to implement it.

Thanks, you're right, better bring the matter up on more technical channels.
I just wanted to check beforehand if the matter had already been discussed here in some thread and pick up some opinions.

Regarding the "just add one more Mega" philosophy, please allow me to voice my opinion too.
Although in general I have little to object to it (it's actually quick, cheap etc.), and in some - many - applications it's really a no-brainer, in some others I find it incredibly limiting, bordering to unacceptable (meaning: makes you opt for a different system altogether).

In my experience, I have met many setups (particularly devices) where there was no space at all to add one more Mega board; sometimes even just one was too large to fit, so equivalents like the MegaPro Embed have been used.
Besides, additional boards/cables/hubs can be very inconvenient when you're short of just maybe 10, 5, or even 2 pins.

I think that, for a system that aims to be generic, modular, flexible and reasonably "universal", it is kind of a contradiction to make such strict assumptions about what can or can't be done in the final application, at least when allowing broader possibilities is not really a burden; maybe Sebastian has veered towards the same opinion.
That's why I'm very glad of the late support for shift-register based peripheral blocks (important example: common constant current LED drivers) - though I must admit that I am yet not sure how far currently both inputs and outputs are supported.

On the topic, I am also puzzled by comments by Sebastian like this one: https://github.com/MobiFlight/MobiFlight-Connector/issues/449#issuecomment-908956199 where he says he "would really like" to support multiplexers (74hc4067), also for possible compatibility with SimVim (now realSimControl), something that I can recall had been firmly dismissed in past discussions!
It is also possible, as transpired from the same post, that he has little experience with the actual electronic components, and this might play a part on his judgment. But this is a matter I think it had better be discussed with him directly.

I would also be in favour of having common driver lines for shift registers, it would help to save Mega pin resources. I share same opinion as giocc, sometimes it's kind of inconvenient to add one extra Mega for only a few pins. The Atmega 2560 is such a powerful microcontroller that actually a complex cockpit could be built with only 1 mega. I made a PCB with SMD serial shift registers and it's able to manage 64outputs and 64inputs using only 4 Mega pins. Also 128PCBs can be connected to the same 4pins, so this system can actually control 8192 inputs and outputs, which should be enough for a B737 cockpit, I hope . Now, I'm trying to get it interfaced with Mobiflight, so common drive lines for shift registers would be very beneficial.

Hi amcosco,

welcome to MobiFlight!

what a logic: 1 MEGA board but 128 PCBs with components for switches and LEDs plus at least one additional power supply ...
Search on YouTube for "HeliMech". He built a complete B737 Cockpit with 34 Megas.

Apart from that: since version MF 9.0 shift registers are possible. More on this on Discord and/or Github.

PS: By the way, most pins can be saved by not building anything at all ;-)

Stephan,
every time a discussion on this theme surfaces, it seems to bring out a good deal of unfriendly feelings.
Of course amcosco's example, "one mega to rule them all", is an extreme (which I tend not to subscribe to, BTW), but you seem to reply with a similarly untenable argument - "add megas by the pound just because" - just for the sake of dismissing a different opinion.

(For the record, a similar, albeit reverted, attitude is regularly encountered in other well known systems - which I won't mention - that postulate that using more than a single mega is a deadly sin.)

I am confident that I made my reasons clear in my previous post (and amcosco just wanted to support them), so there's no use in repeating myself; let me just observe that, just because someone has deemed fit to use 34 megas for HIS specific kind and execution of build, with HIS specific requirements and preferences (and regardless of the fact that he's a really capable guy, cheers to him!), is no case at all to prove that as the absolutely best way for each and every possible application.

Sometimes I feel genuinely puzzled by the fact that architectural guidelines are upheld as dogmas beyond any real technical reasons, standing in the way of bringing potentially substantial improvements to a very good and established system; for some reason, hardly anyone seems interested in this. Moreover, it almost seems as if having different possibilities would go at the expense of those who have a different view.

But I didn't mean for this thread to become a clash of philosophical nature, I just started with the hope to investigate an interesting improvement; I hope this is still possible and maybe even fruitful.

But I didn't mean for this thread to become a clash of philosophical nature, I just started with the hope to investigate an interesting improvement; I hope this is still possible and maybe even fruitful.

Thats the point..... All the feature requests ( like Shift Register, Multiplexer, Matrix Inputs, Different Boards like UNO Micro , additional 7Seg and Stepper Drivers) ..... All are just philosophical !!!!

For sure it´s true..... If a User invest time and create code for those things,..... And all is working fine. This is a benefit if MF e.g. can increase Pin/Device Number by those new features.
Its also a benefit if MF e.g. can handle a new Controller like the Micro..... So a User who only need 10 Pins not need to use a "little mor expensive" Mega !

BUT!!!!

The mostly forgot element is TIME !
Currently some users on Discord spent 100-200 Hours of lifetime (together) to rework our firmware..... to make it compatible also for Micro/Uno.
On this point i think about other Elements..... Eg.g. we talk since 5 Years about a posibility to let a LED Blink ( Need by nearly every cockpitbuilder)
OR.... We think since years about support for 14/16 Seg Displays to show Characters like NESW in a B737 IRS Display. or the "+" in a A320/B737 VS Display.

So NOW I ask myself a easy question...... Whats the REAL Benefit of this user`s work ????
All features we talk above could be already done with current software..... Simply by " Add a new Mega" ......
But many other things, that need real new Code and improvemnet work are not be done---- Badly nobody work on that! The people just work on features to save 3$ ?????

So my question is simple..... Why you guys waste time to work ( or think about) elements that are still possible with additional Controllers...... If we have on other side a long list of requested features, that are currently not possible, but would be be needed SAME TIME for lots of other users?

To bring this to a end.....
Lets say nobody think about all stuff to save Pins or to increase effictivity......
1000+ Hours of Programmign and Brainstorming time together would be "free" and can be invest to other things ......
May we would still have a direct XPlane Interface (Same way like WASM for FS2020) to controll Datareffs. ( So SimVim would be unless for all of the world)
May we would have Blinking LED´s, 16 Seg Support, Automatic writes through MF without Key Press, a better UIand many more things !

In easy words.... For myself every minute of time that is invest for a thing that is still possible is waste..... Aslong there is a minimum of one really new feature left in the list !
And YES..... This is not a pure logical argument... this is a philosophy !

"Thats the point..... All the feature requests (like Shift Register, Multiplexer, Matrix Inputs, Different Boards like UNO Micro , additional 7Seg and Stepper Drivers) ..... All are just philosophical !!!!"

No they're not. All of them are motivated by very practical reasons. The main difference, of course, should be in the amount of people interested in them, though here it seems to lie more in the attitude: It's not interesting to me, therefore "you guys waste time to work (or think about) elements".

Why are e.g. blinking LEDs more important? Or 16-segment support (which have very specific and limited application)? Because "Need by nearly every cockpitbuilder": this may well be, but how would you know this in the first place, if you had dismissed every suggestion or request because it didn't match your likings?

The people just work on features to save 3$

: this clearly shows you completely missed the point. It's not a matter of cost at all. It's a matter of building panels that can get twice as complicated as needed (if at all possible to build it as intended). I would show you practical examples, but I doubt you'd be interested given your reply.

Of course there are lots of possible improvements, very different in effort, extent, and importance; for one, I would definitely vote myself for a native interface to XPlane (or many other features), over the possibility of shared driver lines. Priorities exist, and for good reasons; that, I think, is abundantly clear to everyone, but it's not endangered by just talking about smaller features.
Still, I think it's interesting to discuss ideas; and maybe, before introducing a grand feature with months of work (and years of timeline), maybe a smaller one with just a few hours, or maybe even days, of work could make its way to the application. After all, shift registers have been implemented by someone (thanks!) ahead of larger features, without diverting years of work from the entire body of developers.

With my original question, I wanted to check the pulse to possibly offer my contribution (maybe someone was already working on it? Maybe someone had suggestions?); given the reaction, I think I would be better off by forking the code and keep my "waste of time" to myself. I will probably still take a chance and see on the discord channel if anyone is interested in supplying some useful feedback, otherwise I won't bother to convince anybody to accept undesired opinions or contributions.

Thanks for your time and insight anyway.

I must say again..... All my last postings are MY personal thoughts. Not a official Mobiflight Statement.
I love to discuss about those things.... You got good ideas and thougths..... But you finally not argument to my main announcement !

Why are e.g. blinking LEDs more important? Or 16-segment support (which have very specific and limited application)? Because "Need by nearly every cockpitbuilder": this may well be, but how would you know this in the first place, if you had dismissed every suggestion or request because it didn't match your likings?

The main statement of my last posting is different!! Its not the question what users "like" or what i prefer. ..... Its question what they are "NOT be able to do at the moment"

Blinking LED and 16Seg got for me a Priority, cause as i said..... It is not possible to Build this with current Mobiflight Version.
On other side you hopefully agree..... All the listed Things ( you vote for) like Shift register, Chared CLK Lines, (and so on) pretty sure also give a benefit ( and may also a lot of people want this) BUT..... They not open a new usecase! All these things can be done ( may a little uncomfortable) still Today !

With Your CLK Line Idea or with the Shift registers we could make things more easy and more cheaper/effective. But finallly whatever if you use 5 or 300 Max Chips .... or you use 20 or 5000 LED´s. Both is STILL possible without any new feature just by using more and more Megas.
On other Side.... Without a New Feature a LED will not Blink. Its no mater if only 10% of Users need this and if same time 90% of users ask for shift Registers.
My argument is simple..... The 90% in that case can still build there cockpit (whatever with too much megas) but the 10% are blocked!

**************

: this clearly shows you completely missed the point. It's not a matter of cost at all. It's a matter of building panels that can get twice as complicated as needed (if at all possible to build it as intended). I would show you practical examples, but I doubt you'd be interested given your reply.

Yes . Please tell it to me ( Best way via Discord Voice with a beer and a nice brainstorming ).
Thats exactly what i looking for !
Lots of people tell me e.g. a Shift register is a Benefit..... But after discussing 2 Hours always there only final argument is "cheaper like a Mega" .
Really nobody could show me ( until now) a benefit why e.g. a shift register make things less difficult ! Instead. I think it increase difficult a lot !

Give me a example where e.g. Time to Build is reduced through your ideas....
Give me a example where system to setup ( e.g. MF Configs) get more easy.....

Argument please if your feature is a benefit for a new user.....
For example a Shift register ( in my eyes) is a new element a new user must understand and learn to work with it ( The mega he still knows). So why it is for a new user more easy to connect a Led to a additional IC and why it is more easy to understand to select a Shift Register Adress in MF Settings instead of a unique Pin Nr.

I´m not against all thing basically..... If you give me good arguments and show me a benefit ( additional to "save 3$" or to "have more free Pins" ) then pretty sure i will agree and change the sides !
Please Contact me on Discord if you got some time. I looking forward to meet you !

Thanks for your eloquent reply, we might still not completely agree on some points but I also think there's indeed space for an interesting exchange!
I'd be very glad to meet you on Discord, although unfortunately each of us will have to bring his own beer
I'm usually free on weekends only, though I'm fairly flexible about the time (BTW we're on the same timezone, I'm from Italy). I will message you there, please let me know when it's more convenient for you.
Looking forward to talk to you soon!