Bug or Design? Noticed that unexport() leaves given pin in a floating state? This is typically not a best practice? about onoff HOT 7 CLOSED

Noticed that unexport() leaves given pin in a floating state?

I don't believe this to be the case.

• Please provide a short and complete program which can be used to reproduce this behaviour.
• Please explain how you verified that the given pin is floating.

It is my understanding that the default state for most pins on Pi hardware start up is set for output, no? This avoids pin floating.

This is not my understanding. My understanding is that most pins are configured as input pins by default and have either their internal pullup or pulldown resistor activated. It is also my understanding that calling unexport for a pin will configure the pin as an input without modifying the state of it's pullup or pulldown resistor which implies that it should not be floating.

from onoff.

It is not a matter of providing anything. I am watching the GPIO pins, and the voltage is floating, the default state at power up, most GPIO pins on a Pi device are floating, unless explicitly assigned as in or out mode. My point or question is, should you code not explicitly default to out mode, so the given pins are not floating. If I use you code, I explicitly see the given pins in question return to a floating state, when I call unexported() to release the pins from control. It would be better to not allow the pins return to a floating state, IMHO.

from onoff.

the default state at power up, most GPIO pins on a Pi device are floating, unless explicitly assigned as in or out mode.

This is not the case. As already mentioned above, most pins on a Pi are explicitly configured as in pins on power up.

My point or question is, should you code not explicitly default to out mode, so the given pins are not floating.

No, the code should definitely not explicitly default to out mode. This is highly likely to result in short circuits. For example, assume GPIO17 (or any other GPIO) is connected to a 3V3 power source. If GPIO17 is configured as an output and it's value is set to 0V we have a short circuit.

It is not a matter of providing anything.

I see this a little differently.

If I use you code, I explicitly see the given pins in question return to a floating state, when I call unexported() to release the pins from control.

You need to see this from my perspective. All I know is that you are having an issue with some circuit. Regarding this circuit and the code that is used to control it I am completely in the dark. I have no idea what the concrete problem is. If you explain what the circuit should do and what it does do we may be able to resolve the issue.

from onoff.

I noticed the behavior using your code, and then used volt meter, checking the given GPIO pin, with and without using unexported(). This was where the surprise was, I could see the unstable voltage, i.e. floating. If I left the given GPIO pin set for output, at the end of script execution, I no longer saw the float (of course).

True, the short-circuit issue is significant, my comments are in the context of the topic and testing, I realize I should have qualified that better.

I was trying to drive a MAX7219 based LED strip (8 7-segment LEDs). Using rpi-led-control (on git). It may be the actual GPIO pins I have been watching have non-typical behavior. This all started when I was watching a bit-bang based script using GPIO 8, 10, 11... in other words overriding the SPI0 group of GPIO pins. The original script I updated to work with current versions of required modules. The original version of the project will not compile under npm. Nor execute on current node js with current versions the required modules. For example, it was trying to use a very old version of onoff module.

The long and short, you did qualify my question... onoff is doing what it does... by design.

Given I am using bit-band based module to drive the MAX7219 based device, if unexported() is never called there is little risk of a short circuit per se, pins are not exposed. Moreover, what is odd is the original script... never called unexported. Which struck me as odd, if not a bad practice. The old C programming mantra... if you allocate, you must de-allocate it.

I plan to further update the solution to use true SPI, and avoid the bit-banging, this will avoid the issue as well, in due course.

from onoff.

In this case it's ok to allow the program to terminate without calling unexport. The sysfs files located at /sys/class/gpio that are used to control the pins will remain there after the program has terminated. On program termination, outputs will remain configured as outputs and inputs will remain configured as inputs.

from onoff.

Cool... Somehow it feels wrong... (my old C experience influence)... But makes sense. Thanks for taking the time to answer my question, and moreover, doing active support of the 'onoff' module.

from onoff.

Thanks for taking the time to answer my question, and moreover, doing active support of the 'onoff' module.

You're welcome 😄

from onoff.