Using GPIOs without Using sudo

GoogleGroups
21

A bit of a mystery in how it works other than it creates an OS fault to signal issues. My new function is more complicated:
{
   The ExportPin procedure has been expanded to test to see if it is already
   exported. If it was already there then a new bit flag is set so that when
   the application calls to unexport pins, the ones that were there are left alone.
}
procedure TSysfsGPIO.ExportPin(const Pin: TPinIdentifier);
var val : StdChar;
begin
// First check to see if we already exported this pin inside this application.
if (not IsPinBitSet(Pin, ExportedBitmask)) then begin

  Suggest

  if (not (IsPinBitSet(Pin, ExportedBitmask)
      or IsPinBitSet(Pin, ExportDefinedBitmask)) then begin

That way you don't waste time with the TryReadCharFromFile() if you already
know it was externally exported.

So where does the delay suggestion you made come in? When we try and set the direction of the pin! Which is done in the user application.
// Switch LED pin for output.
GPIO.PinMode[PinLED] := TPinMode.Output;

  I'd put the delay immediately after

      // Wasn't exported when program started so now let's export it.
      if TryWriteTextToFile(FExportFileName, IntToStr(Pin)) then
  begin
         SetPinBit(Pin, ExportedBitmask);
    *** put delay statement here ***;
  end;

The only issue I've run into is the repeat until loop. Seems like the file is readable in about 100mS but fails with the write unless the delay is 500mS.

  Which "file" (there are so many created under each exported pin) <G>

  It may be that the OS default for those files permits reading -- but
the group hasn't been changed yet so only root can write. Sometime after
the creation, the logic that sets up special groups runs and changes the
file to a group that allows you to write.

22

Hi Dennis,

  Suggest

  if (not (IsPinBitSet(Pin, ExportedBitmask)
      or IsPinBitSet(Pin, ExportDefinedBitmask)) then begin

That way you don't waste time with the TryReadCharFromFile() if you already
know it was externally exported.

The ExportDefinedBitmask I created is the only extra bit available in that array of bytes indexed by pin number. But like the ExportedBitmask it's unknown until the system tries to read from it at which point it's defined. I added it because I didn't think any application has the right to unexport a pin that was already exported on start up.

Even with just the 1/2 second delay, you can see the difference in speed of the test application when the pin is already exported compared to when it's not.

>
>
  I'd put the delay immediately after

      // Wasn't exported when program started so now let's export it.
      if TryWriteTextToFile(FExportFileName, IntToStr(Pin)) then
  begin
         SetPinBit(Pin, ExportedBitmask);
    *** put delay statement here ***;
  end;

Yes. Could be put there too. I'll take a closer look to see if that introduces a side effect. I had a reason for not doing it in the export procedure. Just don't remember why...

>
>
>The only issue I've run into is the repeat until loop. Seems like the file is readable in about 100mS but fails with the write unless the
delay is 500mS.
>

  Which "file" (there are so many created under each exported pin) <G>

The initial usage of the pin must be to set the direction which then does the export so that's the file I try and read from. Trying to get pin value before setting direction results in a fault.

  It may be that the OS default for those files permits reading -- but
the group hasn't been changed yet so only root can write. Sometime after
the creation, the logic that sets up special groups runs and changes the
file to a group that allows you to write.

Hmm. Maybe it's better to try and get the file attributes and then it would execute the loop decrement section instead. At the moment it never executes that part of the code.

In either case I just need to test that code on the Pi3 and Pi4 to make sure Blinky blinks. On the Beagle the code now makes it through the Reset and DIR select for the SPI bus test code but dies on the IOCTL call.

The simple C code in the \\BEAGLEBONE\debian\exploringBB\chp08\spi\spidev_test does work so the question is what's broken in the pxl library?

And now that I have the Mikroe Click board rewired I have two beagles with CAN bus drivers in the kennel.

I have a Click board with a SPI based RAM chip which will be the easiest to interface with rather than a breadboard with an SPI 320x240 LCD SPI controlled display.

Baby steps eh?
John

23

BTW, caught this posting
https://forum.beagleboard.org/t/gpio-export-problem/29737

Apparently exporting twice to the same pin will cause it to go away. If I understand the issue correctly. All the more reason to test to see if it's already there and then not export if so.

John