FPC on Rasp Pi, non Lazarus, use of GPIO.

[AlanTheBeast]

First Success.  Using ojz0r (just realized that was a 0) 's code, managed to read an input and turn on a LED when the button was pushed.
(Not using Laz, using Geany.  Less fuss).

Code: Pascal  [Select][+][-]

1. program testGVL(input, output);
2. (* {mode objfpc}{$H+} *)
3.  
4. uses
5.         GVL, IO_GPIO, sysutils;
6.        
7. const
8.         SecPerDay = 86400;
9.        
10. var
11.         i:longword=0;
12.         make:boolean=false;
13.         breaker: boolean = false;
14.         time : TDateTime;
15.         statechange: boolean;
16.        
17.  
18. begin
19.         time := now;
20.         repeat                          // Loop
21.         GVL.readInput();               // Read the inputs defined in iolist.pas
22.         StateChange := false;
23.  
24.         if (not make) and (GVL.GPIO[17]) then            // Use GPIO 17
25.         begin
26.                 GVL.GPIO[22] := false;   // Set GPIO 18
27.                 writeln ('up');
28.                 make := true;
29.                 breaker := false;
30.                 statechange := true;
31.         end;
32.         if (not breaker) and (not GVL.GPIO[17]) then
33.         begin
34.                 writeln ('down');
35.                 GVL.GPIO[22] :=true;
36.                 breaker := true;
37.                 make := false;
38.                 statechange := true;
39.                        
40.         end;
41.  
42.         if statechange then
43.                 begin
44.                         GVL.setOutput();               // Set the output state of GPIO's defined in iolist.pas
45.                         inc(i);
46.                 end;
47.         sleep(50);
48.  
49.         until ((now - time) * SecPerDay) > 10;    // Escape loop
50.  
51.         IO_GPIO.unexportGPIO();             // Unexport/free the GPIO from /sys upon program termination
52.         writeln(i);
53. end.
54.  

[ojz0r]

Well the SPI part is also based on the wiki example, allthough i could not get it to work at first so i had to do alot of work arounds.
The IO_MCPxxxx units are not so generic since i have hard coded the SPI request for each types control registers.
Note that (atleast) the RPi Zero only have two chip select pins, be careful not to get that confused or weird stuff can happen. They are defined in the constants part.
The chips are MCP3208 (8x 12-bit ADC) and MCP4922 (2x 12-bit DAC).

I use the SPI I/O the same way as the GPIO: Read at beginning of cycle and write at the end.

Code: Pascal  [Select][+][-]

1. GVL.readInputs();
2.  
3. GVL.aoCH[0] := GVL.aiCH[0];
4.  
5. GVL.setOutputs();
6.  

One weird thing i had when terminating the program was that the analog output would assume a seemingly random value.
To remedy that i added a "GVL.aoCH[n] := 0;" (followed by setOutputs procedure) right before the "end." outside the main loop.

Again i suspect that the code continues the same newbie mistakes as the last attachment.

I notice 7 others have downloaded the .zip file you posted ... I guess laziness is fun for everyone!

Thats probably curiosity.

[AlanTheBeast]

Thanks ojz0r!

[MarkMLl]

Over the last few months I've been playing with a CH341 board as discussed at https://hackaday.com/2018/02/21/linux-adds-ch341-gpio/ I found that I had to tweak the module/driver slightly in order to get predictable kernel-generated names, but after that it behaved very much as would be expected on an RPi. I was using GPIO access via /sys, which is the "old" kernel standard, there's also a "new" kernel standard interface via /dev/gpiochip* which I've not yet played with, and the RPi-specific one via /dev/mem which I've /definitely/ not played with https://embeddedbits.org/new-linux-kernel-gpio-user-space-interface/

The "new-style" (kernel 4.8 and newer) API appears to work- at least with a CH341 attached to a PC- without changes to the module/driver. The /dev/gpiochipX device is still root:root, I don't know whether there's a way to hotplug it into e.g. a gpio group to which users could be added.

I've not investigated the API yet, but looking at the source of gpiomon suggests that it polls the device rather than using something like FAM to request that it be advised promptly by the kernel when something changes. Frankly I feel it's a bit /meh/...

Somewhat later: there's a Java bug from 2015 which relates to the fact that creation of directories in /sys/class/gpiochip* isn't handled reliably by FAM, but that doesn't say anything about whether gpio*/value updates are detected... I suspect not but I might be tempted to investigate further.

MarkMLl

[AlanTheBeast]

@Mark,

I'll be looking at the /dev/gpio_____ methods tomorrow.  Glad for now that I have ojz0r's code compiled and running.

Not much for me to do now ... I'm waiting for the GPS and Accel/Gyro to show up.

[MarkMLl]

I'll be looking at the /dev/gpio_____ methods tomorrow.  Glad for now that I have ojz0r's code compiled and running.

That might need a Pascal binding to libgpiod and I'm not sure such a thing exists yet. I might have a chance to take a look over the weekend, I've had it pencilled in for a while.

The API does have a "wait for change with timeout" function and I'd expect that to be far more responsive than going through /sys/class/gpio. Assuming that your RPi has kernel >= 4.8, what is the user:group ownership of your /dev/gpiochip* ?

MarkMLl

[AlanTheBeast]

Assuming that your RPi has kernel >= 4.8, what is the user:group ownership of your /dev/gpiochip* ?

Code: Text  [Select][+][-]

1. pi@raspberrypi:/dev $ uname -r
2. 5.10.11-v7l+
3. pi@raspberrypi:/dev $ ls -al | grep gpio
4. crw-rw----   1 root gpio    254,   0 Feb 17 20:46 gpiochip0
5. crw-rw----   1 root gpio    254,   1 Feb 17 20:46 gpiochip1
6. crw-rw----   1 root gpio    246,   0 Feb 17 20:46 gpiomem

[MarkMLl]

Assuming that your RPi has kernel >= 4.8, what is the user:group ownership of your /dev/gpiochip* ?

Code: Text  [Select][+][-]

1. pi@raspberrypi:/dev $ uname -r
2. 5.10.11-v7l+
3. pi@raspberrypi:/dev $ ls -al | grep gpio
4. crw-rw----   1 root gpio    254,   0 Feb 17 20:46 gpiochip0
5. crw-rw----   1 root gpio    254,   1 Feb 17 20:46 gpiochip1
6. crw-rw----   1 root gpio    246,   0 Feb 17 20:46 gpiomem

Thanks for that, I suspected that the RPi people would have taken the trouble to make that (relatively) accessible. Don't try using it yet though, I don't think there's a Pascal binding to libgpiod or a unit for direct access to the kernel: stick to /sys/class/gpio for the moment.

My development RPi uses the classic hack of an RPi kernel with standard Debian on top, but over the last few months the WiFi has stopped working for reasons that nobody seems to understand. Time for a "Delete all and insert", but I'll probably stick to Raspbian (or whatever it's called these days) since I don't have a user insisting on having three as desktop systems.

MarkMLl

[AlanTheBeast]

I'll probably stick to Raspbian (or whatever it's called these days)

They call it "Raspberry Pi OS".

https://www.raspberrypi.org/software/

[AlanTheBeast]

And my major use for Ada is using it to point out that when the DoD was looking for a language base they didn't seriously consider Lisp, although I've seen other people revisiting it comparatively recently and being impressed https://www.revk.uk/2017/11/ada.html

I just installed Ada on the Pi and tested it out.

DL, install, write a program (HellWorld), make ... a few minutes.

It used to take our 80186 cross compiler on the VAX 24 hours to compile and link about 5000 lines of code...

... astounding ...

[MarkMLl]

It used to take our 80186 cross compiler on the VAX 24 hours to compile and link about 5000 lines of code...

On the one hand, it's reasonable to assume that an RPi is more powerful- at least for single-user stuff- than a VAX.

On the other hand, it's reasonable to assume that some of the paranoid checks that were in late-80s/early-90s Ada might have been omitted. There's certainly a lot of the workbench stuff that has been.

The gripping hand is that there's probably also been a lot of changes in compiler technology, so even if the platform and facilities were identical speed might still be substantially improved. But we don't know for certain.

MarkMLl

[AlanTheBeast]

Two labs began Ada at about the same time.  Each chose a different compiler vendor.

Our lab had to meet US military s/w standards for avionics, they had to meet commercial.  (The US military generally uses commercial standards for s/w these days).  We were at similar criticality (about DO-160B level C).

Both had to meet divisional standards for s/w (which was a melding of both to a large degree).

Yes, the compiler was full compliance and that was a big part of the slowness.  Obviously we would avoid full builds as much as possible.

it's reasonable to assume that an RPi is more powerful- at least for single-user stuff- than a VAX.

But yes, a 4 core Pi at 1.5GHz could host many virtual VAX-785's (16 MHz IIRC) and 16 MB of RAM...

https://www.linkedin.com/pulse/vaxcluster-raspberry-pi-wilm-boerhout

The other lab's compiler seemed much faster though...

another:
https://www.askwoody.com/2020/ibm-system-370-on-a-raspberry-pi/

[MarkMLl]

Two labs began Ada at about the same time.  Each chose a different compiler vendor.

Our lab had to meet US military s/w standards for avionics, they had to meet commercial.  (The US military generally uses commercial standards for s/w these days).  We were at similar criticality (about DO-160B level C).

Both had to meet divisional standards for s/w (which was a melding of both to a large degree).

Yes, the compiler was full compliance and that was a big part of the slowness.  Obviously we would avoid full builds as much as possible.

I could tell you were an ex-Ada man. You're one of the minority who knows how to spell it...

I seem to remember discussing it with a few people during my GM days in Devon, but I can't remember how many of those converted into sales (most customers went direct to Alsys). I do however recall that we sold a copy of Logitech Modula-2 on a QIC cartridge for a VAX... it's an extreme minority who remembers Logitech as a compiler supplier.

it's reasonable to assume that an RPi is more powerful- at least for single-user stuff- than a VAX.

But yes, a 4 core Pi at 1.5GHz could host many virtual VAX-785's (16 MHz IIRC) and 16 MB of RAM...

https://www.linkedin.com/pulse/vaxcluster-raspberry-pi-wilm-boerhout

The other lab's compiler seemed much faster though...

another:
https://www.askwoody.com/2020/ibm-system-370-on-a-raspberry-pi/

Yes. There's stuff in the FPC-distributed variant of Lnet specifically to support the x2741 terminal emulator that I use to talk to a VM/CMS guest system, although that terminal emulator's strength is actually APL.

MarkMLl

[AlanTheBeast]

Revisiting the empty Tform ..... (see attached screen grab).

Main:

Code: Pascal  [Select][+][-]

1.                                                                                                                          program io_test;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   {$IFDEF UNIX}{$IFDEF UseCThreads}
7.   cthreads,
8.   {$ENDIF}{$ENDIF}
9.   Interfaces, // this includes the LCL widgetset
10.   Forms, Unit1
11.   { you can add units after this };
12.  
13. {$R *.res}
14.  
15. begin
16.   Application.Initialize;
17.   Application.CreateForm(TForm1, Form1);
18.   Application.Run;
19. end.

Unit

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. {Demo application for GPIO on Raspberry Pi}
4. {Inspired by the Python input/output demo application by Gareth Halfacree}
5. {written for the Raspberry Pi User Guide, ISBN 978-1-118-46446-5}
6.  
7. {This application reads the status of a push-button}
8.  
9. {$mode objfpc}{$H+}
10.  
11. interface
12.  
13. uses
14.   Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls,
15.   ButtonPanel, Unix, BaseUnix;
16.  
17. type
18.  
19.   { TForm1 }
20.  
21.   TForm1 = class(TForm)
22.     ApplicationProperties1: TApplicationProperties;
23.     GPIO18CheckBox: TCheckBox;
24.     LogMemo: TMemo;
25.     procedure ApplicationProperties1Idle(Sender: TObject; var Done: Boolean);
26.     procedure FormActivate(Sender: TObject);
27.     procedure FormClose(Sender: TObject; var CloseAction: TCloseAction);
28.   private
29.     { private declarations }
30.   public
31.     { public declarations }
32.   end;
33.  
34. const
35.   PIN_18: PChar = '18';
36.   IN_DIRECTION: PChar = 'in';
37.  
38. var
39.   Form1: TForm1;
40.   gReturnCode: longint; {stores the result of the IO operation}
41.  
42. implementation
43.  
44. {$R *.lfm}
45.  
46. { TForm1 }
47.  
48. procedure TForm1.FormActivate(Sender: TObject);
49. var
50.   fileDesc: integer;
51. begin
52.   { Prepare SoC pin 18 (pin 12 on GPIO port) for access: }
53.   try
54.     fileDesc := fpopen('/sys/class/gpio/export', O_WrOnly);
55.     gReturnCode := fpwrite(fileDesc, PIN_18[0], 2);
56.     LogMemo.Lines.Add(IntToStr(gReturnCode));
57.   finally
58.     gReturnCode := fpclose(fileDesc);
59.     LogMemo.Lines.Add(IntToStr(gReturnCode));
60.   end;
61.   { Set SoC pin 18 as input: }
62.   try
63.     fileDesc := fpopen('/sys/class/gpio/gpio18/direction', O_WrOnly);
64.     gReturnCode := fpwrite(fileDesc, IN_DIRECTION[0], 2);
65.     LogMemo.Lines.Add(IntToStr(gReturnCode));
66.   finally
67.     gReturnCode := fpclose(fileDesc);
68.     LogMemo.Lines.Add(IntToStr(gReturnCode));
69.   end;
70. end;
71.  
72. procedure TForm1.ApplicationProperties1Idle(Sender: TObject; var Done: Boolean);
73. var
74.   fileDesc: integer;
75.   buttonStatus: string[1] = '1';
76. begin
77.   try
78.     { Open SoC pin 18 (pin 12 on GPIO port) in read-only mode: }
79.     fileDesc := fpopen('/sys/class/gpio/gpio18/value', O_RdOnly);
80.     if fileDesc > 0 then
81.     begin
82.       { Read status of this pin (0: button pressed, 1: button released): }
83.       gReturnCode := fpread(fileDesc, buttonStatus[1], 1);
84.       LogMemo.Lines.Add(IntToStr(gReturnCode) + ': ' + buttonStatus);
85.       LogMemo.SelStart := Length(LogMemo.Lines.Text) - 1;
86.       if buttonStatus = '0' then
87.         GPIO18CheckBox.Checked := true
88.       else
89.         GPIO18CheckBox.Checked := false;
90.     end;
91.   finally
92.     { Close SoC pin 18 (pin 12 on GPIO port) }
93.     gReturnCode := fpclose(fileDesc);
94.     LogMemo.Lines.Add(IntToStr(gReturnCode));
95.     LogMemo.SelStart := Length(LogMemo.Lines.Text) - 1;
96.   end;
97. end;
98.  
99. procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
100. var
101.   fileDesc: integer;
102. begin
103.   { Free SoC pin 18: }
104.   try
105.     fileDesc := fpopen('/sys/class/gpio/unexport', O_WrOnly);
106.     gReturnCode := fpwrite(fileDesc, PIN_18[0], 2);
107.     LogMemo.Lines.Add(IntToStr(gReturnCode));
108.   finally
109.     gReturnCode := fpclose(fileDesc);
110.     LogMemo.Lines.Add(IntToStr(gReturnCode));
111.   end;
112. end;
113.  
114. end.

[AlanTheBeast]

I could tell you were an ex-Ada man. You're one of the minority who knows how to spell it...

Well, I took a class at work (about 4 days, the instructor brought along a UNIX system with about 10 terminals - UNIX was not known to us much.  We were all assembler / FORTRAN / Pascal types (and most not even Pascal)).  2 people per terminal (teams).  I was paired with a Belgian engineer who though HOL's were an abomination to mankind.

But I never wrote a line of production code in Ada - as I mentioned earlier - my contribution was a section in assembler to the system that was 98% in Ada 83.  I had moved to marketing by then and didn't want to waste time learning how to make it work in Ada and I wasn't confident in the timing issues (I was allocated 2ms per 40ms on a machine that had IIRC an 8 MHz clock).  So took the shortcut and banged it out in assembler and shaved weeks off the schedule... 

I remember a very experienced and highly respected engineer say "Wow.  This record construct could be really useful!"
( I don't recall her ever doing anything other than assembler before that - HP-2100 ...)

A few years ago, I requested here, that FPC be modified to allow undeclared counter/index vars in procedures and functions as in Ada.  People beat the crap out of me - you may have been one of them!  Still seems like a good idea to me!

I do however recall that we sold a copy of Logitech Modula-2 on a QIC cartridge for a VAX... it's an extreme minority who remembers Logitech as a compiler supplier.

You're right.  Never thought of them at all like that.

I did write some Modula-2 (Borland) back OUAT ... I seem to recall it was a university class for an easy A.  (I never went to class so I think I hit a B- on that...).  In those (DOS) days it was pretty tedious IIRC as one had to edit the unit interface file separately from the implementation.  So main, units (interface), units (implementation).  That was a loooong time ago though.  I might have preferred it over Pascal if editing wasn't so tedious.  Then TP 4 came out with Units and - wow! What an improvement.

I believe, had Wirth simply extended Pascal with concepts from Modula-2, that Ada could have begun there...

I do seem to recall buying stuff from Logitech and getting 'bonus packs' of s/w of all sorts...