Read GPIO problem

[shworker]

I use Pine64 A64-DB-Rev B board and Debian Jessie.

I need read some GPIO pins (69 and 233 on RPI connector) using sysfs. I use pullup resistors (10k) to 3.3v. Measure voltage on these pins. I get 3 v.
Set direction to 'in'.
But, reading /sys/class/gpio/gpioXX/value i always got 0 !

If switch direction to out, then back to in, reading get 1 ! 

Simple script to test:

Code:

#!/bin/sh

SYSFSDIR=/sys/class/gpio
DOOR_PIN=69
UPLVLPIN=233

setup(){
   if [ ! -d $SYSFSDIR/gpio$1 ] ; then
       echo $1 > $SYSFSDIR/export
   fi
   # If comment out these 2 lines - always read 0 !
   echo 'out' > $SYSFSDIR/gpio$1/direction
   echo 'in' > $SYSFSDIR/gpio$1/direction
}

gpio_read(){
   cat $SYSFSDIR/gpio$1/value
}

setup $DOOR_PIN
setup $UPLVLPIN

case "$1" in
   door)
       gpio_read $DOOR_PIN
       ;;
   uplevel)
       gpio_read $UPLVLPIN
       ;;
   *)
       usage
       ;;
esac

PS: Sorry for my bad english, my native language is Russian

[Techsensei]

Hi m8,

Am i right you're wondering why you're getting different read-outs???

Grts

...tech

[shworker]

Yes.
When pin configured for input (default) is always read 0 regardless of the voltage level at the pin.
But if you switch pin direction to 'out', then again to 'in' all you read correctly.
If in the script that I put comment out the line:
"echo 'out' > $SYSFSDIR/gpio$1/direction"
is always read 0.

[MarkHaysHarris777]

... will work on this later today.

[aromring]

Same bug happens on A64-DB-2G Rev B running Armbian Desktop 3.10.105-pine64

[MarkHaysHarris777]

This is not a bug.

... you have to set the direction to  "IN"  and then set the ACTIVE_LOW or the input pin will not work the way you expect, even though theoretically the default state of the pins is input !

After setting the direction to IN of course the pin functions normally as an input pin.

[pfeerick]

This is not a bug.

... you have to set the direction to  "IN"  and then set the ACTIVE_LOW or the input pin will not work the way you expect, even though theoretically the default state of the pins is input !

After setting the direction to IN of course the pin functions normally as an input pin.

Actually, that is a bug... if you export say gpio 69 (pin 33 on the rPi bus), and then try to read the value, it will report 0 regardless of it the pin is being held high or low. If you check the direction, it says it is "in". But if you simply set the direction as 'in' (no toggling out/in, just setting as in) it will read 1/0 correctly if you take it high/low. So the initial state of the sysfs direction is probably not correct... I think the question then is that a DTS error, some other initialisation error, or simply the sysfs not being in with the actual pin state when the GPIO is exported. No need to alter active_low, and nor did changing only it alter the results. Only 're'-setting the direction was needed. 

My money is on the DTS... as I think it can also set the inital state of the pins, but I really haven't played in that space, so I'll defer to the DTS experts on that one

[MarkHaysHarris777]

This is not a bug.

... you have to set the direction to  "IN"  and then set the ACTIVE_LOW or the input pin will not work the way you expect, even though theoretically the default state of the pins is input !

After setting the direction to IN of course the pin functions normally as an input pin.

Actually, that is a bug... 

My money is on the DTS... as I think it can also set the inital state of the pins, but I really haven't played in that space, so I'll defer to the DTS experts on that one

No, actually, it is NOT a bug.

... that is one of the problems with the PineA64 board;  it does not guarantee the state of an uninitialized pin !  Unlike the Raspberry PI which DOES guarantee the state(s) of uninitialized pins.  The /sys/class/gpio/ system is not "in sync" with the hardware until explicit initialization.  The reason ACTIVE_LOW needs to be set is that the internal pullups can also be pulldowns !  If you don't set ACTIVE_LOW the function of the input pin (whether pullup or pulldown) is not known either, and may or may not function as expected.  The bottom line (aside from argumentative semantics) is that explicit initialization of gpio pads on the PineA64 board is required !

Having said all of that, I agree that we may be able to correct this situation (bug or semantics) with dts and|or init code which makes sure default states of all pins really are input;  but then,  do we assume pullups ?  Or is it really better that the gpio(s) are a resource left up to the user in user space/  again explicit initialization seems to be the best situation all around.

[pfeerick]

If you don't think it is a bug, then that's fine. If I export a pin, and then read the direction parameter, and see that it is "in", and it doesn't work, then I call that a bug, because it is not doing what it says it should be doing. Simple as that. Having to set it as an input when it says it is already is an input is not what I should have to do. It isn't reporting that the pin is 'uninitialised' or some other state.. it says it is currently 'in'. There was no need to change active_low in the tests I did, so I do not believe that is a factor, unless it truly is random. I believe that it is an incorrect DTS setting, and that the sysfs is incorrectly stating the current state of the pin, and the DTS is setting it to something else. But as I said, I haven't played with that stuff, so I will defer to the experts that do know how that stuff actually works.

As far as the default state, it should be whatever sysfs says it is when you export the gpio! :-P Something which is not what it says it is isn't semantics, it's a bug! 

[MarkHaysHarris777]

If I export a pin, and then read the direction parameter, and see that it is "in", and it doesn't work, then I call that a bug, because it is not doing what it says it should be doing. Simple as that. 

Except that it IS NOT as simple as that.

... Exporting a pin doesn't set anything.  The export only makes the pad available in user space; that's all, exporting alone is not a complete operation, and as incomplete it alone does not guarantee anything about the state of the pin nor the direction, nor the pullup|pulldown. You must also set the direction and if input set the pull, and if output set the value;  with the /sys/class/gpio/  method it really is as complicated as that on the PineA64. 

Now then, if you don't want to do the complete operation, well that's fine;  except that it won't work -- simple as that.

---

---

Note:  I do understand 'what' everyone believes export "should" accomplish, and I certainly also believe that it should be possible to guarantee the default operation of an exported pad;  however, my personal 'reality' is that it is more important to help users understand the complete operation rather than arguing over what 'should' be happening.  At the end of the day, do you want the pad to work or not ??  That's the simple question you need to answer for yourself.