Problem running example on Raspberry PI lazarus / 32-Linux ---------------------------------------------------------------------- MartynA · 2017-12-04 19:07 Hi, I've been using Lazarus on Win10 for a while, and yesterday set up Lazarus on a Raspberry PI 3.  Compiling and running simpe apps works fine but I'm having a problem running the example in the section Switching a device via the GPIO port of this article: http://wiki.freepascal.org/Lazarus_on_Raspberry_Pi#PiGpio_Low-level_na tive_pascal_unit_.28GPIO_control_instead_of_wiringPi_c_library.29 The problem I get is that all the fpwrite() calls return -1, and the app fails to toggle an LED I've wired between pin 11 and one of the ground pins via a series resistor.  However, if I run it via sudo in a terminal window, the app works fine and the LED turn on and off as it should. I want to get the app to run without the need to use sudo.  I've seen the note in the article section about the need to execute the app as root OR to "A better option is to add the user to the gpio group, the i2c group and the spi group. ". I tried the adduser calls sudo adduser pi gpio sudo adduser pi i2c sudo adduser pi spi as the article suggests before I began setting up the app, but they all returned a msg like "The user  pi is already a member of the 'gpio' group'" (and the other two groups). So, any suggestions how to get the app to work without running it via sudo in the terminal window? Btw,  this is on a newly installed Raspbian - all I did after its self-set-up was to use apt-get to install fpc, lazarus, sqlite3 and libsqlite3-dev. TIA, Martyn ---------------------------------------------------------------------- mas steindorff · 2017-12-04 19:29 I can not help you on the software side but on the hardware... one should not directly connect a LED to a CPU pin.  you need to have a resistor in the path as well to prevent the CPU from resetting (short story).  just in case you forgot... ---------------------------------------------------------------------- MartynA · 2017-12-04 19:38 Thanks, but I didn't forget - I soldered a 680 ohm resistor in series with the LED's anode.  It's as well to remind readers of the need for one. Cheers, Martyn ---------------------------------------------------------------------- rvk · 2017-12-04 20:25 Check that /dev/gpiomem has the correct permissions with ls -l /dev/gpiomem If it doesn't have group access for read and write for group gpio, fix it. sudo chown root.gpio /dev/gpiomem sudo chmod g+rw /dev/gpiomem ---------------------------------------------------------------------- MartynA · 2017-12-04 20:52 Thanks.  I'm not sure what the correct permissions are supposed to be, but   ls -l /dev/gpiomem returned   crw-rw----l root gpio 244, 0 Dec  4 18:09 /dev/gpiomem I ran the two following commands you listed, rebooted the system, restarted Lazarus,  and ran the app from within the IDE but I'm afraid the app still  behaves as I initially described:  the fpwrites() still return -1 and the LED doesn't toggle. Cheers, Martyn ---------------------------------------------------------------------- rvk · 2017-12-04 21:03 Quote from: MartynA on December 04, 2017, 09:52:47 pm  crw-rw----l root gpio 244, 0 Dec  4 18:09 /dev/gpiomem That should be correct. What does this give you? ls /sys/class/gpio -l ---------------------------------------------------------------------- MartynA · 2017-12-04 21:19 I get this pi@raspberrypi:~ $ ls /sys/class/gpio -l total 0 -rwxrwx--- 1 root gpio 4096 Dec  4 20:47 export lrwxrwxrwx 1 root gpio    0 Dec  4 20:47 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0 lrwxrwxrwx 1 root gpio    0 Dec  4 20:47 gpiochip100 -> ../../devices/gpiochip2/gpio/gpiochip100 lrwxrwxrwx 1 root gpio    0 Dec  4 20:47 gpiochip128 -> ../../devices/gpiochip1/gpio/gpiochip128 -rwxrwx--- 1 root gpio 4096 Dec  4 20:47 unexport Btw, I should probably have mentioned in my q that this is on a newly installed Raspbian - all I did after its self-set-up was to use apt- get to install fpc, lazarus, sqlite3 and libsqlite3-dev. ---------------------------------------------------------------------- rvk · 2017-12-04 21:25 Can you toggle the led manually as user? Like the way on this page http://raspberrypi.tomasgreno.cz/setup-gpio.html But then with GPIO17 (for pin 11): echo 17 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio17/direction echo 1 > /sys/class/gpio/gpio17/value and release the pin echo 17 > /sys/class/gpio/unexport ---------------------------------------------------------------------- MartynA · 2017-12-04 21:38 Yes, those turn the LED on. (and off using 'echo 0 > ...') ---------------------------------------------------------------------- rvk · 2017-12-04 21:47 Quote from: MartynA on December 04, 2017, 10:38:29 pmYes, those turn the LED on. (and off using 'echo 0 > ...') As user pi? Then it's not a permission problem. What does fpgeterrno give you after getting -1 for fpwrite? What example exactly did you use? (the first one?) You could try the shell method. Under "Hardware access via encapsulated shell calls" ---------------------------------------------------------------------- MartynA · 2017-12-05 16:52 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. ---------------------------------------------------------------------- rvk · 2017-12-05 18:47 Quote from: MartynA on December 05, 2017, 05:52:25 pmI 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: When the first call to export fails, you shouldn't execute the others. echo 17 > export creates the gpio17 directory with correct permissions echo 17 > unexport removes it. So if > export fails nothing else matters (and will fail). Not sure what 512 as error is yet. But for the most part the shell commands work for you. The reason it could be unstable is if you open the port and the port stays in use. In that case using the port again might give problems. I can't test right now. I dusted off an old RPI3 and installed Rasbian Stretch but installing trunk gave me trouble. Something in the compile of Lazarus with invalid opcode. Not sure if it's a user-error or trunk error yet. Now checking out 1.6.4 (but haven't much time tonight). Mmm, 1.6.4 doesn't work with new fpc trunk. Checking out 1.8.0 RC5. ---------------------------------------------------------------------- rvk · 2017-12-05 23:01 Quote from: MartynA on December 05, 2017, 05:52:25 pmfpwrite(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 Ok, I did some testing. I had the same result as you. The fpopen on export works correctly and the next fpWrite returns 2. That's also correct because the error is 0 and you have written 2 bytes (characters 1 and 7). fpClose also wasn't a problem. Next you get an error (permission denied) on fpOpen on gpio17/direction. After that you can go on but you'll get Bad file number because fpOpen wasn't successful. I have noticed that the gpio17 directory was created with the correct permissions so I was puzzled why it didn't work. Then I put in some logging and it worked  I traced the problem to accessing the direction file too fast after putting 17 in export. The OS hasn't fully created the gpio17 directory yet when you try to open the direction file inside it !  So, even if you put a Application.ProcessMessages or a Sleep(1000) just before opening the direction-file it should all work correctly. Could you test that in your version? ---------------------------------------------------------------------- MartynA · 2017-12-05 23:24 Thanks,  I really appreciate the effort you've put into this. I confess I'm a bit Application.ProcessMessages-averse but, yes, that avoids the problem and so does Sleep(100) (I didn't need 1000 mS). It's a bit late here (UK), so I'll carry on testing tomorrow, and then go back to the first example and see whether your fix does anything for that, too. Later, Martyn ---------------------------------------------------------------------- rvk · 2017-12-05 23:30 At least we're close to a solution. I wonder why the delay wasn't build in the example. The example could use some extra error logging too. I will change that when we know for sure that's also the problem on your end. It's late here too (NL) so sleep well. ---------------------------------------------------------------------- MartynA · 2017-12-07 17:35 I've been using the "fix" in an app I've been writing for my son for a couple of days, and it seems to work fine. Presumably, rather than use a specific value for the Sleep period, it would be preferable to use a while loop to return a zero status or timeout. Btw, meanwhile I've found a problem in another example in the http://wiki.freepascal.org/Lazarus_on_Raspberry_Pi#PiGpio_Low-level_na tive_pascal_unit_.28GPIO_control_instead_of_wiringPi_c_library.29 page - I'll start a new thread about that. Cheers, Martyn ---------------------------------------------------------------------- rvk · 2017-12-07 18:36 Good to know a small delay works. The delay can probably be even smaller. But checking for the existence of the gpio17 in a loop won't work 100% either. Because the directory is first created with limited permissions. After that the permissions are changed. So actually, the wait should be for the correct permissions on the direction file. Some info: https://github.com/raspberrypi/linux/issues/553