GreenGiant bug workaround

[WillMunns]

Some missing break statements in the green giant code mean that configuring GPIO will also configure higher numbered GPIO.

The obvious FAQ workaround is to ask users to put inputs on the low numbered GPIO and outputs on the higher ones, then simply configure the GPIO in order.

In robot we could configure all GPIO in order whenever there is a configuration change to any GPIO. Its a little ugly but we can't patch GreenGiants that are in the wild

[WillMunns]

I'm not certain how to do this cleanly. You know the GPIO number because its the address -1, but I'm not sure that the GPIO object can access its parent to use that information?

You can't use this info to query the Greengiant because the Greengiant doesn't let you know this from the I2C.

Hacky as hell you could have a static array and update from this?

[shardros]

I don't understand the problem enough to suggest a fix. Could you comment a passing/failing example?

Yes you can access the parent class in python using super.

[WillMunns]

``` R.gpio[1].mode = OUTPUT R.gpio[2].mode = OUTPUT R.gpio[3].mode = OUTPUT R.gpio[4].mode = OUTPUT ``` Sets all pins to OUTPUT But if later you do: ``` R.gpio[2].mode = INPUT ``` Then the brain considers just gpio2 to be in input state, but the green giant configures GPIO2, 3 and 4 as inputs. (Which you can observe by connecting LEDs to the GPIO)

On 07/11/2021 at 10:39, Edwin Shepherd wrote:

From: "Edwin Shepherd" ***@***.***>Date: 7 November 2021To: "systemetric/robot" ***@***.***>Cc: "Will" ***@***.***>,"Author" ***@***.***>Subject: Re: [systemetric/robot] GreenGiant bug workaround (Issue #29) I don't understand the problem enough to suggest a fix. Could you comment a passing/failing example? Yes you can access the parent class in python using super.

[shardros]

I have created a PR with one possible solution. Less hacking than globals, I still feel like there is a more pythonic way out there but idk what it is.