On Thu, 13 May 2021 10:05:24 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" <johnd-5o6ditlojsohvde0pjs...@public.gmane.org> wrote:
>I've been playing with that yesterday.
>I think the library needs to be changed in a couple of places. As you pointed
>out, it doesn't really know if the GPIO pin was already exported until it
>tries to do it and then flags that it's exported in the flags variable.
>
On further scanning of the source -- it will all come down to the
library. I think the Export method is declared as private, so your
application couldn't call it directly without modifying the library spec.
And if one is modifying the library, might as well fix it all within the
library instead of still requiring applications to change also.
>The problem is if the export fails it then not only checks an invalid flag
>setting and does the unexport but that ends up removing an exported pin that
>was already there when the program stops. I don't like that behaviour. I
>thought I saw that it only changes it to input from output but yet it's gone
>when the program finishes so that will take some more investigation.
>
The change from in to out might be linked to the re-export if the
kernel tears down the pin configuration and rebuilds it (or -- it might
have been built into some overhead library operation, forgive me for not
doing a scan of the sources again).
>What I found yesterday is by adding the delay you suggested down in the
>library after the TryWriteTextToFile() that I now get run from command line
>performance. Most of yesterday was a bit of a write-off dealing with a
>missing SIM card for my wife's new iPhone 12 and some running around to get
>other problems solved.
>
>From puTTY I reliably get this now.
>debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$
>./Blinky
>Blinking LED, press any key to exit...
>debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$
>
Progress... <G>
>Today I want to change that low level code to:
>1. Not set the exported flag if the pin is already there so it won't be
>unexported at the end but only set to what it was before the program ran.
>This means we also won't try to export it at the start.
That might add a bit more overhead than you want -- if you are talking
about adding a test to see if the .../gpioXX directory (or a file within
the directory) exists and is accessible. After all, it appears that every
access of a pin includes the test for is-pin-exported. You might want to
add a parallel bitmap similar to the one currently used in which you record
pins that were found to be externally exported.
That would make the is-pin-exported something like
<current pin bitmap test> OR <new bitmap test>
That way you only invoke the export function if the pin is in neither
bitmap. Export function could then be something like
if <.../gpioXX directory exists> then
update new bitmap
else
write the export command
sleep
update old bitmap
--
Dennis L Bieber
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/f8sq9g1722mq93tv2vcdfe0lq9c9683hbv%404ax.com.
