Read GPIO problem
#11
(08-07-2017, 07:21 AM)MarkHaysHarris777 Wrote: 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.

Um, don't you mean you understand what export DOES on the board that people are most familiar with this funtionality? Because on the raspberry pi, there is no need to set the direction, because the initial sysfs values are correct!! Tongue When you export a pin, and then do a 'cat /sys/kernel/debug/gpio' on the rPi, the values you see are actually representational of the pin state, not false (i.e. gpio-4 sysfs in lo).

However, when you move to other boards, such as the Orange Pi Zero, you are out of luck... they are left floating just like with the pine64. Yes, it is nice to have it working, but exceptionalism is not good either... because this means this is yet another thing that makes the RPi-2 bus not RPi-2 compatible. So at the end of the day, I would like to either make it do what everyone expects it to do, or if that is not possible, document it as a known issue, because it is not rPi behaviour. Anything else is just looking at it with rose-tinted glasses, and making excuses.
  Reply
#12
(08-07-2017, 07:21 PM)pfeerick Wrote:
(08-07-2017, 07:21 AM)MarkHaysHarris777 Wrote: 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.

Um, don't you mean you understand what export DOES on the board that people are most familiar with this funtionality? Because on the raspberry pi, there is no need to set the direction, because the initial sysfs values are correct!! Tongue When you export a pin, and then do a 'cat /sys/kernel/debug/gpio' on the rPi, the values you see are actually representational of the pin state, not false (i.e. gpio-4 sysfs in lo).

However, when you move to other boards, such as the Orange Pi Zero, you are out of luck... they are left floating just like with the pine64. Yes, it is nice to have it working, but exceptionalism is not good either... because this means this is yet another thing that makes the RPi-2 bus not RPi-2 compatible. So at the end of the day, I would like to either make it do what everyone expects it to do, or if that is not possible, document it as a known issue, because it is not rPi behaviour. Anything else is just looking at it with rose-tinted glasses, and making excuses.


Yes, of course,  which is what I stated in post #8. 

...  the Raspberry PI people do go to great lengths to make sure that the board can be relied upon to match the /sys/class/gpio/  filesystem, as well to make sure that the default pin states can be relied upon too ( stipulated ).

I suppose I agree with this part of your argument in as far as the PI2 bus is trying to be compatible (sort-of) with the Raspberry PI ( it is actually incompatible in several points, but leaving that aside for the moment ).

It could be argued both ways IMHO.  On the one hand, in an automated sense, if export would leave the pins in an expected default state for some people this would be desirable from the standpoint that it would be less work and more consistent.  On the other hand, I question whether it is not better when dealing with hardware to make sure that the state of the pads is explicitly stated in the user space initialization routines ?  This is an honest question. I mean its only a couple of lines of code to make sure that the state of the pin is set explicitly.

Thinking about this some more this evening I´m thinking that if it were possible, there ought to be a PI2 compatibility mode;  particularly in the sysfs method and in the RPi.GPIO-PineA64 routines. In any case I´m supposing that not only the dts would need tweaking, but the sysfs kernel module component as well. 

I´m going to check tomorrow to see whether the Rock64 has a similar issue.

Wink
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
#13
My point the whole time as been simply that... if you export the pin, and it says that it's state is currently x, then it should damn well be x. not y, or z... x. The Raspberry Pi folks know that is what should be the case, so they made sure it was. Otherwise, the pin should have have a 'indeterminate' state, so that you know it hasn't been set yet. Wink

A separate 'compatibility' mode isn't needed, especially when we are talking about the RPi bus. It either isn't or is. We already know that it isn't, so the focus should then be making it as compatible as possible, and documenting well the areas which it isn't. As far as the default state, it should be an input as the sysfs expects, and should be that as soon as possible. Not getting into a discussion over how soon it should do it, or what happens before then... this is a SBC, not a micro-controller... it's going to be sloppy. I do think for simplicity sake it should be done at boot - so probably in uboot. And I still wonder if the DTS is the root of the problem there... if you read some of the gpio-controller info, it appears that the default states *may* be defined there...

https://www.kernel.org/doc/Documentation...o/gpio.txt
  Reply
#14
(08-08-2017, 06:20 PM)pfeerick Wrote: My point the whole time as been simply that... if you export the pin, and it says that it's state is currently x, then it should damn well be x. not y, or z... x. The Raspberry Pi folks know that is what should be the case, so they made sure it was. Otherwise, the pin should have have a 'indeterminate' state, so that you know it hasn't been set yet. Wink 


My 4K R64 board came in yesterday ; so I played with it most of the night,  found that it does NOT have this issue.   If the pin is exported its direction is set IN, the active_low is set 0 and its value is set "1".  If the pin is grounded than the value changes to "0".  

So we need to get to the bottom of it;  is it a dts|dtb issue, a hardware issue with the PineA64+,  or a build issue ( something inconsistent with export somehow ).
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
#15
Personally, I think it is more "by hardware design" where Rockchip and AllWinner engineers views diverge in the way GPIOs are implemented.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  RPi.GPIO python module for Pine A64/A64+ aquilegia 98 129,294 12-15-2022, 08:40 PM
Last Post: Fadazo
  fm transmitter with gpio weasel18 2 4,730 09-10-2019, 04:28 AM
Last Post: desai_amogh
  How to use dts or other setup to declare gpio pin Interrupt (e.g. a button)? dkebler 1 3,531 06-12-2019, 10:37 AM
Last Post: dkebler
Lightbulb Sample GPIO codes highlighting RPi.GPIO-PineA64 and the PI bus MarkHaysHarris777 6 10,918 06-07-2019, 12:37 AM
Last Post: tllim
Star GPIO, SPI and I2C C++ Lib databit 7 11,012 02-04-2019, 05:45 AM
Last Post: Jeff R
Information Howto: Controlling Pine64 GPIO via the filesystem (sysfs) on linux pfeerick 4 11,733 01-24-2019, 03:36 AM
Last Post: Fifth
  GPIO and SPI SamR1 20 31,078 03-15-2018, 10:32 AM
Last Post: jomoengineer
Question GPIO shockr 7 14,522 03-11-2018, 01:52 AM
Last Post: jomoengineer
  GPIO fiq capability joseph 3 5,988 11-10-2016, 06:07 PM
Last Post: joseph
  RPI2-GPIO mus1c 6 8,935 09-22-2016, 05:28 AM
Last Post: mus1c

Forum Jump:


Users browsing this thread: 1 Guest(s)