Add core support for FLEXGPIO i2c Expander and Motor Alarm Expander Inputs

[engigeer]

• Add init for flexgpio plugin to support use of i2c based RP2040 io expander from Expatria
• Add core support to facilitate defining and claiming per-axis motor fault pins by expander plugins
• Fix typo in aux input mask

[terjeio]

I have added an alternative solution that, IMO, is cleaner and easier to implement across drivers. I hope it is ok I did this without involving you...

Handling of the is still done in board specific code, main change driver side is that the pins to use is set via a call from the driver and that both expander and local pins can be used, even in a mix if required.
The driver specific code for the Sienci SLB Ext has been updated, this was the only board making use of separate inputs for each driver, making the decision to change the interface easier.

I have not added all your proposed changes, e.g. expanding the number of digital ports. The main reason for not doing this earlier is that adding port definitions eats into flash - and some drivers are a bit short on that.

Have you tested expander probe inputs? No latency issues?

[engigeer]

I have added an alternative solution that, IMO, is cleaner and easier to implement across drivers. I hope it is ok I did this without involving you...

Sounds great. I will test with my board and confirm all is working as expected.

I have not added all your proposed changes, e.g. expanding the number of digital ports. The main reason for not doing this earlier is that adding port definitions eats into flash - and some drivers are a bit short on that.

This makes sense, although maybe there could also be a way to expand the IO capability on boards/drivers that support it? I have not yet pinpointed the exact source of the issue I was fixing with this change, but I think it is related to having more pins than AUX_MAX, even though some of these pins are not AUX (e.g., limits). I’m wondering if maybe it is the loop in map_reverse?

[engigeer]

Have you tested expander probe inputs? No latency issues?

Testing of this is still ongoing but I think there are some options if it proves to be too much. The expander was designed with a second irq pin connected to the primary mcu, which could be dedicated to probes. It seems like it should be possible to hook into the probe-select logic and then “hand-off” this signal between the various configured probes, depending on which is active.

[terjeio]

Is this to allow increasing the number of ports?

[engigeer]

Not exactly. But increasing the value of MAX_PORTS seems necessary for correct assignment of aux pin functions for my new 2350 board map.

Without increasing this value from the default (i.e., 24), I am seeing that even if there are <24 Aux Input Ports (I have for example only 12 on my map + 8 expander ports) the pin assignment will be incorrect if I try to assign these inputs to explicit functions like Cycle Start, etc.

I am still trying to wrap my head around how the pin assignments are stored in the map, but it almost seems like when the aux ports are assigned to an explicit function they take up an additional entry in the map. So if I have 20 ports, and more than 4 are assigned to explicit functions, the map overflows and weird behaviour occurs. Does this make sense?

[terjeio]

Try with these changes, at the top of crossbar.h there are new #defines that can be overridden (in blocks of 8, max 32 (31?) for digital, max 16 for analog).

auxports.zip