Read GPIO problem
#1
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 Wink
  Reply
#2
Hi m8,

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

Grts

...tech
please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697
  Reply
#3
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.
  Reply
#4
... will work on this later today.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#5
Same bug happens on A64-DB-2G Rev B running Armbian Desktop 3.10.105-pine64
  Reply
#6
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.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#7
(08-05-2017, 10:24 PM)MarkHaysHarris777 Wrote: 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 Wink
  Reply
#8
(08-06-2017, 01:33 AM)pfeerick Wrote:
(08-05-2017, 10:24 PM)MarkHaysHarris777 Wrote: 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 Wink


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.


Blush
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#9
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! Dodgy
  Reply
#10
(08-07-2017, 12:11 AM)pfeerick Wrote: 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.

Tongue




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.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  How to use dts or other setup to declare gpio pin Interrupt (e.g. a button)? dkebler 1 43 06-12-2019, 10:37 AM
Last Post: dkebler
Lightbulb Sample GPIO codes highlighting RPi.GPIO-PineA64 and the PI bus MarkHaysHarris777 6 1,511 06-07-2019, 12:37 AM
Last Post: tllim
Star GPIO, SPI and I2C C++ Lib databit 7 2,193 02-04-2019, 05:45 AM
Last Post: Jeff R
Information Howto: Controlling Pine64 GPIO via the filesystem (sysfs) on linux pfeerick 4 3,503 01-24-2019, 03:36 AM
Last Post: Fifth
  RPi.GPIO python module for Pine A64/A64+ aquilegia 93 19,824 01-23-2019, 06:46 AM
Last Post: cathenna10
  GPIO and SPI SamR1 20 5,069 03-15-2018, 10:32 AM
Last Post: jomoengineer
Question GPIO shockr 7 3,737 03-11-2018, 01:52 AM
Last Post: jomoengineer
  fm transmitter with gpio weasel18 1 664 06-20-2017, 06:35 AM
Last Post: louwie17
  GPIO fiq capability joseph 3 752 11-10-2016, 06:07 PM
Last Post: joseph
  RPI2-GPIO mus1c 6 1,275 09-22-2016, 05:28 AM
Last Post: mus1c

Forum Jump:


Users browsing this thread: 1 Guest(s)