Sorry for the delay replying ...
>What does fpgeterrno give you after getting -1 for fpwrite?
The results I get from all the calls are s follows:
fpwrite(fileDesc, PIN_17[0], 2) returned 2 fpgeterrno:0
fpclose(fileDesc) returned 0 fpgeterrno:0
fpwrite(fileDesc,OUT_DIRECTION[0], 3) returned o -1 fpgeterrno:9
fpclose(fileDesc) returned -1 fpgeterrno:9
>What example exactly did you use? (the first one?)
Yes, the first one.
>You could try the shell method.
>Under "Hardware access via encapsulated shell calls"
I tried that, hoping my success with the Terminal example you pointed me at would repeat itself. Unfortunately the app under "Hardware access via encapsulated shell calls" behaves erratically. One time out of about 10, the first call, i.e to "export", returns 0 and the the rest of the app behaves as expected. The other ~9 times, the first call returns 512 and the subsequent calls to set the direction and set port 17 to on, return 256, and the LED stays off. There are two odd things about this:
- The misbehaviour persists across cold-starting the Pi (i.e. disconnecting the power during a shutdown/reboot cycle). Do the GPIO settings persist across a cold-restart?
- Sometimes executing the commands from the terminal article clear the problem, but other times not.
Update: As with the first app I tried, the EncapsulatedShell one works fine if run from a terminal window using sudo. I know virtually nothing about Linux but if it's not a permissions issue, maybe it's to do with the app seeing a different execution environment when run in the Terminal as compared with the desktop or Lazarus?
Does any of that give you any clues? It seems to me as if some other process is interfering with the port settings, but I only have Lazarus and the app under test running, in the gui at any rate.