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

[MarkMLl]

Don't assume I'm not reading.

I'll be working on the project tomorrow.

:-)

As to the history of Pascal, I do know that had attention been paid to rapidly adding to the initial Wirth version early and not kept ring fenced it would likely be a major language today.  Indeed, Ada could have been built around it as a core instead of merely inspired by it had such attention been paid earlier...

It's deeper than that: Pascal was the result of ALGOL-68 being sabotaged. 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

One thing I'd throw in about GPIO etc. is that you probably appreciate that in order to get /really/ high-speed access you'd need to get involved with a kernel module: I don't think there's a way to get a GPIO event to interrupt or signal a userspace program directly. And realistically, writing Linux kernel modules needs C. And of course, Linux is not a real-time OS (RTOS) so makes no promises about latency etc.

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/

HTH

MarkMLl

[ojz0r]

First off I'd like to second that Lazarus is really light weight.
However since I'm new to both Pascal and Lazarus I have not got around to do actual coding in Lazarus (its on my todo list).
I've written everything in Nano and compiled with "fpc <program>" directly on the RPi and launching with "./<program>".

Here are the units i have created to make my life easier. (It probably looks like crap to experienced programmers)
You can use it as an example or straight up if you find it sufficient for your needs.

Basically my example contains 3 units:
- GVL.pas: "Global variable list", i use it in the program/sub-units to access the GPIO globaly with "GVL.GPIO[17]" for example.
With this you need to call procedures "GVL.readInputs()" before using the inputs and "GVL.setOutputs()" to set the outputs. When terminating the application you would use the "GVL.unexportGPIO()" to restore the GPIO again.
- iolist.pas: This is the I/O-list i use to map the individual GPIO's as input/output. This is the basis for the last module.
- IO_GPIO.pas: This is the actual "driver" based on the /sys example in the wiki. This one contains procedures used by GVL.pas.

Example how to use:

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

1. program main(input, output);
2. {$mode objfpc}{$H+}
3.  
4. uses
5.         ..., GVL;
6.  
7. begin
8.         repeat                          // Loop
9.         GVL.readInputs();               // Read the inputs defined in iolist.pas
10.  
11.         if GVL.GPIO[17] then            // Use GPIO 17
12.         begin
13.                 GVL.GPIO[18] := true;   // Set GPIO 18
14.         end;
15.  
16.         GVL.setOutputs();               // Set the output state of GPIO's defined in iolist.pas
17.        
18.         until not GVL.GPIO[20]          // Escape loop
19.  
20.         GVL.unexportGPIO();             // Unexport/free the GPIO from /sys upon program termination
21. end.
22.  

Edit: Spelling mistake.
I forgot to mention: my setup is positive voltage to GPIO input = TRUE. Output TRUE = positive voltage on GPIO pin. This can be switched in the IO_GPIO.pas unit.

[MarkMLl]

First off I'd like to second that Lazarus is really light weight.
However since I'm new to both Pascal and Lazarus I have not got around to do actual coding in Lazarus (its on my todo list).
I've written everything in Nano and compiled with "fpc <program>" directly on the RPi and launching with "./<program>".

Here are the units i have created to make my life easier. (It probably looks like crap to experienced programmers)
You can use it as an example or straight up if you find it sufficient for your needs.

Remember: you're writing /in/ Pascal, using the Lazarus IDE as a tool. If you want to use GUI facilities you will end up pulling in stuff from the LCL, otherwise you'll be using the FPC runtime library (RTL) and possibly stuff from the non-GUI FPC Class Library (FCL).

I mention the distinction between RTL and FCL because of the documentation subtrees at https://www.freepascal.org/docs.html which are obviously distinct from https://lazarus-ccr.sourceforge.io/docs/lcl/

One thing I have to ask about your attachment: why are you importing the Crt unit? I'd also query why you've got those GPIO arrays in the interface unit: if you have to have that then put it in the implementation part and access it via a function (to read) or procedure (to write) so that you've got /some/ semblance of control over what can do what.

MarkMLl

[ojz0r]

Well the Crt part is a leftover from previous experimenting, i have yet to completely cleaned up all parts of my code.

I did not attach all my code, maybe the complete project would give a hint at what i was aiming for putting the array in the interface part.
Basically for (again) my use case, i would read the inputs at beginning of a loop and then do logic in between and then set the outputs at the end of the loop, ie i dont use the GPIO inputs in "real time" but an image of the status when entering the loop and writing outputs at the end. So by putting the array in the interface i can use the GPIO[n] freely within the programming without calling a procedure or function to return the instantaneous result.
As i'm writing this i see that it comes of as niché, pascal is a hobby to me and my day job is programming industrial control systems (PLC/DCS) so the concept is to resemble that.

I merely attached the units to give the OP some example based on the wiki /sys example without the form part.
I'm not trying to step on anybodys toes, i know im fresh and not a software engineer, i just want to help.

[MarkMLl]

Even if the GPIO array is only temporary, accepted practice would be to have it in one place with published/exported routines for getting and setting pins. You could also have a unit-level property to make it look like you were accessing a variable.

That would have the undeniable advantage that you could put a breakpoint on the setter and see exactly what was happening, and any overhead that the compiler didn't optimise out would be miniscule compared with what the kernel was having to do to process your 0/1 character through the standard API, and then put it through a module/driver to access the physical bit.

/However/, speaking as somebody else who is industrially-oriented and departing from accepted doctrine, I would not argue that it improved system robustness. Neither FPC nor the underlying OS, and for that matter not the hardware either, implements the sort of segmented architecture which would allow you to say "this physical access routine can only be called by this other part of the code". It is, at a pinch, possible to contrive schemes with access tokens etc. but without physical protection they can always be spoofed.

Linux (in fact POSIX) does have a capabilities mechanism which means that control of the GPIO bits can be enabled or disabled on a per-process/program basis, but it doesn't provide any finer (e.g. per-thread) protection than that and once a handle has been granted I don't think it can be revoked.

MarkMLl

[AlanTheBeast]

@Mark: re: Ada, I read part of the linked article.  One doesn't typically "do Ada" because "want to try using it".  One does Ada because they get hired by an aerospace or defence co. and the Booch is thrown on their desk, "to get familiar" before having some code thrown at them to change.   And here's the company style guide. And here's the flowed down B----g contract paragraph that says: "No recursion and no task rendez-vous".  Here's how you check out code.  Report before you leave for the day.

(I actually had the benefit of an in-house class ... [funny moment: as I was coding an exercise the instructor commented: wouldn't it be nice if indenting was all you needed for a code block.  I chuckled.  Did he know about Python?])

re: real time:  I do hope to be able to set up a timer interrupt at 1 KHz, possibly 2 KHz.  That will be essential to sampling my sensors as well as running a Kalman-ish filter at 10 Hz.  Otherwise I'll have to turn the Pi into an embedded system w/o OS.  (I'd prefer that in some ways...)

@ojzOr: thanks for the code - that's more my cuppa!

EDIT: Forgot to mention, last night installed Laz on the Pi, and made the project from the Wiki, got it to build and run.  All I get is a blank form.  Not sure if I need to set up the hardware to 'drive' that, but should get to it sometime today.
Laz is pretty clunky on the Pi (Pi 4 B (4 cores/1.5GHz) with 8 GB of ram).

[MarkMLl]

@Mark: re: Ada, I read part of the linked article.  One doesn't typically "do Ada" because "want to try using it".  One does Ada because they get hired by an aerospace or defence co. and the Booch is thrown on their desk, "to get familiar" before having some code thrown at them to change.   And here's the company style guide. And here's the flowed down B----g contract paragraph that says: "No recursion and no task rendez-vous".  Here's how you check out code.  Report before you leave for the day.

You obviously aren't familiar with the author. He's ex-BigCorporate, designs and builds high-throughput Internet devices, and runs an ISP. The sort of ISP where one doesn't need any magic words to get through to somebody who knows what he's doing.

https://xkcd.com/806/
https://hackaday.com/2017/12/14/adsl-robustness-verified-by-running-over-wet-string/

Not sure where you're going to be with a high-speed timer interrupt though. That's a very "non-unix" thing to ask... you might be able to do something with a looping thread and either fpSelect() or fpNanoSleep(), but by and large things that require that degree of aggression have specific kernel support.

MarkMLl

[ojz0r]

Even if the GPIO array is only temporary, accepted practice would be to have it in one place with published/exported routines for getting and setting pins. You could also have a unit-level property to make it look like you were accessing a variable.

That would have the undeniable advantage that you could put a breakpoint on the setter and see exactly what was happening, and any overhead that the compiler didn't optimise out would be miniscule compared with what the kernel was having to do to process your 0/1 character through the standard API, and then put it through a module/driver to access the physical bit.

Sadly I don't have the experience/deep enough knowlage to relate to what you mean. I have an easier time learning by studying examples and trying it out.
Do you have some kind of example of this method? Or a wiki page/tutorial link explaining?

[AlanTheBeast]

Not impugning the guy, it's just that Ada is not something one does for fun.  It is the anti-C.  It's hard work (to do right) and usually because it is a requirement, not a desire.  That said, he can indeed do it for himself or co. if he seriously wants to build stronger, more reliable code.  But there is a cost to it in time.  I haven't touched it in decades (literally) and the only time my code was in production it was in 8086 assembler in a system that was otherwise almost 100% Ada (early 90's).

Also, see my revised comment above ("EDIT").

As to real time, I do need a pretty crisp sampling rate and period.  I assumed that Linux' nous as an embedded system core would support that... ah well, if it comes to it I can go OS-less on the sensor end.  Heck, write in Ada.  (kidding).

[MarkMLl]

re: real time:  I do hope to be able to set up a timer interrupt at 1 KHz, possibly 2 KHz.  That will be essential to sampling my sensors as well as running a Kalman-ish filter at 10 Hz.  Otherwise I'll have to turn the Pi into an embedded system w/o OS.  (I'd prefer that in some ways...)

Linux isn't an embedded OS. People try to use it as an embedded OS, just as they try to use Android as an embedded OS (e.g. in 4G USB sticks), but it's not an RTOS and generally speaking (I've not checked the specific GPIO case) it's not easy to hook an interrupt or bitbang.

EDIT: Forgot to mention, last night installed Laz on the Pi, and made the project from the Wiki, got it to build and run.  All I get is a blank form.  Not sure if I need to set up the hardware to 'drive' that, but should get to it sometime today.

In that case post your code so that we can take a look at it (having to be careful here since I don't currently have an RPi set up).

ALWAYS be ready to post your code when complaining about a non-obvious problem.

Laz is pretty clunky on the Pi (Pi 4 B (4 cores/1.5GHz) with 8 GB of ram).

Shouldn't be. Are you using a direct keyboard/video connection or are you doing something like tunneling X11 over SSH?

MarkMLl

[AlanTheBeast]

I'll complete the h/w setup before coming back - and I'll open a new thread if it comes to it.

I do notice, that although the code runs, during compilation there are crtbegin.o and crtend.o not found errors.  Surprised that it linked... FPC install error?



Clunkiness is just v. my Mac (i7 4 HT cores, 3.4 GHz).  And yes I have a mouse/KB on the Pi (the Rasp foundation KB is pretty bad in itself, the mouse is good).

And the general clunky feeling of Linux desktops generally.

Further, I made the error of buying a 1080 p monitor for the project to save money.  Should have gone 4K.

(I'm also VNCing in from the Mac and that is borderline unworkable for scrolling around code...)

[MarkMLl]

Ignore the crtbegin/crtend error, it's one of a couple of benign linker errors.

Normally VNC performs a bit better than X11-over-SSH, because of the implicit buffering/caching... I've seen a couple of apps behaving /very/ badly with remote X11 due AIUI to input device polling issues.

However, that might depend on whether VNC is looking at the system's root window, or is set up to have a dedicated session. In the former case it effectively has to scrape the X11 buffer of the root (GUI console) session, while in the latter case it implements an X11 server for client apps (i.e. Lazarus, the desktop environment etc.) which it then sends over the LAN using its own protocol.

MarkMLl

[AlanTheBeast]

@ojzOr well your code compiles ...

But there was an error in there - a comma instead of a semicolon in GVL.pas in the code you sent w/o further units below.

Testing me, eh?

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

1. implementation
2. uses
3.         IO_GPIO,
4.  

edit:
Then tried your test code (main) which was full of errors, but managed to fix those.

Runs (and quits immediately) - I guess because I haven't wired it up yet... not sure why you're testing on GPIO 20, oh, well, I should be able to sort it out from here....

[ojz0r]

@ojzOr well your code compiles ...

But there was an error in there - a comma instead of a semicolon in GVL.pas in the code you sent w/o further units below.

Testing me, eh?

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

1. implementation
2. uses
3.         IO_GPIO,
4.  

edit:
Then tried your test code (main) which was full of errors, but managed to fix those.

Runs (and quits immediately) - I guess because I haven't wired it up yet... not sure why you're testing on GPIO 20, oh, well, I should be able to sort it out from here....

Oh yeah the units. I had to delete some other IO_ units, i had SPI "drivers" for some mcp's (adc & dac) also declared in the GVL unit.

The code embedded was just a generic example how i use it. You have to declare the pins in the iolist. The pin 20 was just a random number i picked when writing the post.

[AlanTheBeast]

Oh yeah the units. I had to delete some other IO_ units, i had SPI "drivers" for some mcp's (adc & dac) also declared in the GVL unit.

The code embedded was just a generic example how i use it. You have to declare the pins in the iolist. The pin 20 was just a random number i picked when writing the post.

Ok!  If you have SPI code, please don't be shy.  My laziness is boundless!

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