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 > > > -- > 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/40a7ag9gv2635mshemm4euqic4370aodfr%404ax.com. -- 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/011e01d74c0c%24e13144e0%24a393cea0%24%40autoartisans.com.
