gpioserver, output possible for input pins

[heppg]

scratch version 2016-05-02 configured a gpio as input (config23inputpullup) then issued gpio23off, gpio23on and gpio port toggled an attached LED. the gpio23 sensor value toggled also.

Expected result: when port is not configured or configured as input, then output command should have no effect.

[timrowledge]

This is a side-effect of making use of pigpio - when you write to a pin it happily sets the mode to 'output' if it wan't already that way. Oddly, it doesn't set any mode if you read a pin, nor does it fail if the pin is set to output. If you write pwm to a pin it also changes the mode for you.

I'm not at all sure what the proper way to handle this is; it wouldn't be terribly hard to keep a list of how we've configured pins and prevent writing to pins we think are inputs but we're not the only user for pins. Should we read the configuration of the pins when starting up the gpioserver and restore them when it stops? Maybe read them and merge the configuration into our internal status tracking? These are all the sorts of questions I asked about when initially working out the gpioserver and got no responses on, which is why it was left as open as possible in the hope it would make some sort of sense.

The bigger problem is that the pins are an unmanaged shared resource that can be 'damaged' by any code behind the back of any other user.

[heppg]

no simple answer, I agree. I came around this test when preparing a workshop for 'pi and more', comparing gpioserver and scratchClient. The setup uses some led and a button, so I checked what happens if someone writes a '1' to the button input, the button gets pressed and the pi blows up. I would prefer an environment where scratch with its hardware-helpers takes full control. This is typical for school environments. It could be documented that 'scratch takes control of the GPIO pins used in the program and leaves them (undefined|input) state when scratch ends'. And although the initialization is not bullet proof, I prefer an environment where inputs stay inputs and outputs stay outputs. With a preceding config command, this you could change it on the fly. This results in a pattern: restart scratch, and then the code you see is the behavior you get.

On 30.05.2016 19:07, tim Rowledge wrote:

This is a side-effect of making use of pigpio - when you write to a pin it happily sets the mode to 'output' if it wan't already that way. Oddly, it doesn't set any mode if you /read/ a pin, nor does it fail if the pin is set to output. If you write pwm to a pin it also changes the mode for you.

I'm not at all sure what the proper way to handle this is; it wouldn't be terribly hard to keep a list of how we've configured pins and prevent writing to pins we think are inputs /but/ we're not the only user for pins. Should we read the configuration of the pins when starting up the gpioserver and restore them when it stops? Maybe read them and merge the configuration into our internal status tracking? These are all the sorts of questions I asked about when initially working out the gpioserver and got no responses on, which is why it was left as open as possible in the hope it would make some sort of sense.

The bigger problem is that the pins are an unmanaged shared resource that can be 'damaged' by any code behind the back of any other user.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/scratch/issues/197#issuecomment-222529040, or mute the thread https://github.com/notifications/unsubscribe/AE_2C7HvHFK7qn3hJqSv8J4XTQt8aHOsks5qGxlogaJpZM4IpVIm.