search

MobiFlight / MobiFlight-Connector

MobiFlight is an open source project that allows you to create your own home cockpit for your favorite flight simulator in a flexible, affordable and extremely user-friendly way.
https://mobiflight.com
MIT License
244 stars 106 forks source link

Support MCP23017 Port Expander #192

Open MobiFlight-Admin opened 3 years ago

MobiFlight-Admin commented 3 years ago

Support the Cheap MCP23017 I2C Port Expander.

http://www.nikolaus-lueneburg.de/2015/11/mcp23017-i2c-io-port-expander/

[Issue created by Bastischen: 2017-08-15] [Last updated on bitbucket: 2019-09-09]

GioCC commented 2 years ago

I'm thinking about starting to integrate this; I've been holding it off until now because there was already a lot on the plate, but now might be a good time for me. Is anybody already working on it or can I proceed? (@elral , @neilenns)

DocMoebiuz commented 2 years ago

Sounds good. Ralf had some concerns in terms of memory usage. I would expect that a MCP23017 will also either allow to be configured in output or input mode and behave exactly the same in the UI as the output / input shift register.

This is a very old story on the backlog to add this IC. There is an i2c and SPI version of it. Do we have a notion of how much of a footprint we are looking at?

I would actually like to think of how to provide the feature as a community feature and not necessarily putting it into the official MF core. I already mentioned this a couple of weeks ago to some of you: i am trying to come up with a way that people can contribute support for more ICs without always adding everything to the official MF core firmware - it will allow for more innovation speed and less responsibility on the MF side and if a community device turns out to have a high adoption by the community we can still decide to integrate it into the core.

The concept would require to integrate such support only on the FW side and reusing MF UI capabilities. In the case of the MCP23017 this could actually be possible because we have the output and input shift registers as a template.

elral commented 2 years ago

I have done a "quick and dirty" implementation some month ago. All pins show up as output or input via the existing UI as changing the connector is out of my knowledge. So I had to define a number area for the MCP's, maybe not really the best solution, but no changes on the UI side are required. However, support of more devices will not fit any more into the ProMicro/Uno (flash, not RAM), so other devices would have to be disabled.

I haven't come up with an own opinion if the MCP support is still required as we have now the input / output shifters (beside I really like them)

GioCC commented 2 years ago

Sounds good. Ralf had some concerns in terms of memory usage.

I expect the memory footprint to be just slightly higher than a shift register.

I would expect that a MCP23017 will also either allow to be configured in output or input mode and behave exactly the same in the UI as the output / input shift register.

Exactly; more precisely, I'm aiming for a mixed configuration (like: all inputs by default, which is the most common case, but "pins #i,#j and #k are outputs"). The device would then be seen as an overlay of ins and outs (ie: events would just be triggered by pins configured as inputs; only pins configured as outputs can be addressed).

This is a very old story on the backlog to add this IC. There is an i2c and SPI version of it. Do we have a notion of how much of a footprint we are looking at?

I'm considering just the I2C version for now. The SPI version is much less popular and widespread, generally more expensive, and has no real advantage (from our point of view) against a shift register.

I would actually like to think of how to provide the feature as a community feature and not necessarily putting it into the official MF core. I already mentioned this a couple of weeks ago to some of you: i am trying to come up with a way that people can contribute support for more ICs without always adding everything to the official MF core firmware - it will allow for more innovation speed and less responsibility on the MF side and if a community device turns out to have a high adoption by the community we can still decide to integrate it into the core.

This is a good idea that I would tend to support, but I think it still needs to be defined more precisely. Anyway, it requires more thought and planning in advance, and it would involve all (or at least several other) devices; in this specific case, I believe the support for MCP23s should (and can, without too much trouble) be introduced in the meantime, while the broader solution is elaborated - also because the MCP23s are fairly popular and used.

The concept would require to integrate such support only on the FW side and reusing MF UI capabilities. In the case of the MCP23017 this could actually be possible because we have the output and input shift registers as a template.

As I mentioned, I'm basically in favor of this, but I still have some doubts:

GioCC commented 2 years ago

I have done a "quick and dirty" implementation some month ago. All pins show up as output or input via the existing UI as changing the connector is out of my knowledge. So I had to define a number area for the MCP's, maybe not really the best solution, but no changes on the UI side are required.

That's a very good idea for development (and I very much appreciate that MF allows such practical shortcuts!), but I think we agree that, as a permanent solution, the user will have to be able to configure his system from the UI; also, the closer the UI references the actual connections (without "concealed" references), the easier it is for him. If you have a link to your version that you're willing to share, I can see if it might spare me some effort.

However, support of more devices will not fit any more into the ProMicro/Uno (flash, not RAM), so other devices would have to be disabled.

True, but possible (even though not radical) workarounds can be considered.

I haven't come up with an own opinion if the MCP support is still required as we have now the input / output shifters (beside I really like them)

I believe this is a fairly used component. In the end, even shifters were shunned initially, but I think the user response has already beginning to prove otherwise - sometime, if a device type is unsupported, people interested in using it may just not consider the system altogether.

elral commented 2 years ago

If you have a link to your version that you're willing to share, I can see if it might spare me some effort.

https://github.com/elral/MobiFlight-Firmware/tree/MCP23017_new

This is from my first steps of transferring the firmware to paltformIO, so it is NOT a fork of the actual repo. And I haven't transferred it to my actual fork using a new branch. Please be also aware that the button routine is another one (I used before severell times), but the principal should be clear. I "just" check if the pin number exceeds the native pins, and if so I read the input from the MCP (same for the outputs). My idea was to configure one (or more) from the UI side (I2C adress), and once it is configured to "release" the accordingly pin numbers.

GioCC commented 2 years ago

Thanks @elral, I'll have a look at it!

I somehow like the idea of the "virtual" pin numbers assigned to these devices, unfortunately I don't see an easy way to manage them when there are several devices involved (the idea could/should be applied to MCPs, shift regs, multiplexers...). A fixed allocation in a "pin address space" could work, but it would again cap the number/type of devices; besides, many pin references are byte-size, limiting the total nr to 255, and that could raise problems somewhere.

I'm still inclined to consider a pin naming like e.g. "14.06" -> device connected to Arduino pin n.14, peripheral line n.06. This would also conserve the reference to the physical structure, helping the user to locate and understand better which actual HW line is involved.