Read GPIO problem

[MarkHaysHarris777]

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!! 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.