Recent

Author Topic: FPC on Rasp Pi, non Lazarus, use of GPIO.  (Read 17644 times)

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 348
  • My software never cras....
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #75 on: February 22, 2021, 03:14:58 pm »
Quote
There's this sort of thing, which implies that /dev/gpiomem and possibly /dev/mem might be usable.

https://raspberrypi.stackexchange.com/questions/99785/what-is-the-correct-way-to-use-dev-gpiomem-with-mmap-to-get-access-to-raspberry

Nice!  Funny that the question is "what is the correct way" and yet the solution is most likely the least correct way!  (I haven't looked yet...).  That's great for me!

Quote

That is definitely not something I will be playing with, since it is non-portable (i.e. RPi-specific) and only conceals the performance issue rather than providing a robust solution.


If it's robust to my solution, that's all I need.  I'll put it up (if I go that way) with specificity warnings.

Quote
I append a compiles-but-untested implementation of static and dynamic interface units for the gpiod library. Use /either/ gpiod.pas /or/ gpiod_dynamic.pas, the API exposed should be identical and should behave as documented for C etc.

Thanks.  Not sure I can get to it before Friday.  Maybe tomorrow morning.
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #76 on: February 22, 2021, 04:34:22 pm »
Nice!  Funny that the question is "what is the correct way" and yet the solution is most likely the least correct way!  (I haven't looked yet...).  That's great for me!

Well, it can be semantically valid to ask the correct way to operate something even if the result of operating it is abhorrent.

At the risk of being inflammatory, "what is the correct way to operate the napalm dispenser if the enemy fires on the field hospital?". :-/

I anticipate that the gpiod API will operate substantially faster than the /sys/class/gpio one, but relying on "good enough" thoughput is no alternative to a properly designed physical interface.

Here's a minimal gpiod example, it checks the basic calling conventions but doesn't go much further than that:

Code: Pascal  [Select][+][-]
  1. (* A numbered list of ports is prepared at startup, or any time this is called
  2.   and no port is open. The list is returned as a StringList, which should be
  3.   freed by the caller. Entries in the StringList comprise a GpioChip name,
  4.   optionally followed by a space and a device name in parentheses.
  5. *)
  6. FUNCTION ListGpioChardevPorts(currentPort: THandle= InvalidGpioHandle): TStringList;
  7.  
  8. var
  9.   searchRec: TSearchRec;
  10.   gpiochip, gpioname, gpiolabel: string;
  11.   pChip: pgpiod_chip;
  12.  
  13. begin
  14.   if currentPort <> InvalidGpioHandle then
  15.     exit(nil);
  16.   if not DirectoryExists('/dev') then
  17.     exit(nil);
  18.   result := TStringList.Create;
  19.   try
  20.     result.Sorted := true;
  21.     result.Duplicates := dupIgnore;
  22.     IF FindFirst('/dev/gpiochip*', faAnyFile, searchRec) = 0 THEN
  23.       REPEAT
  24.         gpiochip := '/dev/' + searchRec.Name;
  25. //        if not Gpiod.gpiod_is_gpiochip_device(PChar(gpiochip)) then
  26. //          continue;
  27.         pChip := Gpiod.gpiod_chip_open(PChar(gpiochip));
  28.         if pChip = nil then
  29.           continue;
  30.         try
  31.           gpioname := StrPas(Gpiod.gpiod_chip_name(pChip)); (* Same as searchRec.Name? *)
  32.           gpiolabel := StrPas(Gpiod.gpiod_chip_label(pChip));
  33.           gpiochip := searchrec.name;
  34.           if gpioLabel <> '' then
  35.             gpiochip += ' (' { + 'gpiod, ' } + gpioLabel + ')';
  36.           result.Add(gpiochip)
  37.         finally
  38.           Gpiod.gpiod_chip_close(pChip)
  39.         end
  40.       UNTIL FindNext(searchRec) <> 0;
  41.     FindClose(searchRec)
  42.   finally
  43.     if result.Count = 0 then
  44.       FreeAndNil(result)
  45.   end
  46. end { ListGpioChardevPorts } ;
  47.  

That should work identically for either the gpiod or the gpiod_dynamic unit, the "magic" being that the explicit Gpiod. is required.

There looks to be a bit of variability between versions of the library, for example gpiod_is_gpiochip_device() is declared in the header files shipped by the kernel but not in the binary library from Debian (and Raspbian is a Debian derivative). If there's a mismatch of that type the static linkage will fail at build time, while I'd expect the dynamic linkage to throw an exception at runtime.

MarkMLl
« Last Edit: February 22, 2021, 05:24:46 pm by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 348
  • My software never cras....
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #77 on: February 22, 2021, 10:32:36 pm »

At the risk of being inflammatory, "what is the correct way to operate the napalm dispenser ..."


Operating that correctly would indeed be inflammatory... 8)

I'll look into the rest tomorrow or Friday.  Herself believes I have "communal chores" to catch up on... and if she believes it, well...

Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #78 on: February 22, 2021, 11:07:13 pm »
I'll look into the rest tomorrow or Friday.  Herself believes I have "communal chores" to catch up on... and if she believes it, well...

So far I'm happy with the interface units. What I'm not happy about is that there's information in /sys/class/gpio that doesn't have a counterpart in the gpiod API... you'll probably not see it on an RPi but in brief the gpiod API always numbers I/O lines starting at zero while /sys/class/gpio allows you to deduce whether there's inaccessible bits which means that the first accessible bit should have some higher number.

The CH341 board I'm using has two possible drivers: i2c-ch431 (eight GPIO lines) and spi-ch431 (two GPIO lines). If I use the /sys/class/gpio interface I can work out the physical correspondence, if I use gpiod I can't... I might possibly be able to force line names in the module/driver but I'm not at all confident.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 348
  • My software never cras....
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #79 on: February 22, 2021, 11:40:06 pm »
Noted.

And it looks like housework is good for me as my mind wanders...  While I have to confirm the behaviour, I recalled that the gyro/accel module can be configured to output the data at a desired sampling rate.  It has an OCXO, so the sampling should be reasonably accurate.  Can set rates well in excess of 1 Khz.  Each sample 'frame' would be about 20 bytes or so... I assume that Linux will buffer serial data coming in ???  I can hit it pretty often to 'drain' and process...

I have to see how well I can use the GPS to 'frame' the timing of the gyro/accel - but for that I would have liked to use the 1PPS pin - that no longer seems viable.  I was going to set the GPS to 10 Hz frames, but it can be up to 18 (such a messy number hopefully I can set it to 16 Hz).

Edit:
As part of this, I suppose I can use my fav:  "now" to do rough RT dispatching of tasks and "now" and GPS time to discipline some sort of local to the code soft clock and some sort of task to back fill time on recent accel/gyro frames.  The actuator part of this job will be relatively slow at about 40 - 100 Hz.  I think.  TBD.
« Last Edit: February 23, 2021, 01:01:07 am by AlanTheBeast »
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 348
  • My software never cras....
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #80 on: February 23, 2021, 01:13:54 am »
Quote
Don't need no stinkin' OS.
https://ultibo.org/

Just visited that site and it looks very promising.  Thanks!!!!!

Edit: may be a dead group.     :'(

Edit: there is life there.  Registration turned out to be manual and I've received e-mail from them...

I'll look into it more towards the weekend.
« Last Edit: February 23, 2021, 01:14:09 pm by AlanTheBeast »
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #81 on: February 23, 2021, 05:59:08 am »
Not dead I guess.
Last update 20 days ago : https://github.com/ultibohub/Core
Last update 8 days ago : https://github.com/ultibohub/Tools

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #82 on: February 23, 2021, 07:55:54 am »
Noted.

And it looks like housework is good for me as my mind wanders...  While I have to confirm the behaviour, I recalled that the gyro/accel module can be configured to output the data at a desired sampling rate.  It has an OCXO, so the sampling should be reasonably accurate.  Can set rates well in excess of 1 Khz.  Each sample 'frame' would be about 20 bytes or so... I assume that Linux will buffer serial data coming in ???  I can hit it pretty often to 'drain' and process...

Surely you'll be using I2C or similar for that, not GPIO?

Quote
I have to see how well I can use the GPS to 'frame' the timing of the gyro/accel - but for that I would have liked to use the 1PPS pin - that no longer seems viable.  I was going to set the GPS to 10 Hz frames, but it can be up to 18 (such a messy number hopefully I can set it to 16 Hz).

Edit:
As part of this, I suppose I can use my fav:  "now" to do rough RT dispatching of tasks and "now" and GPS time to discipline some sort of local to the code soft clock and some sort of task to back fill time on recent accel/gyro frames.  The actuator part of this job will be relatively slow at about 40 - 100 Hz.  I think.  TBD.

PPS will /definitely/ need to trigger an interrupt, even on something like a Teensy: polling isn't sufficiently accurate.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 348
  • My software never cras....
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #83 on: February 23, 2021, 01:35:32 pm »
@MarkMLI,

Yes, I2C or the UART which are on the GPIO header.  Waiting on hardware from the US.  Seems to be trapped in NJ for some reason - maybe Canadian Customs has to be placated first. TBD.

PPS trailing edge interrupt would be fantastic.  Not sure if I can do this in Linux.  Possibly if I go the Ultibo route that DonAlfredo pointed out.

It's not clear to me yet that I actually need PPS.  But for sure that would be the most accurate time check possible if not for the app then for testing.  I may buy a USB sillyscope to check timing between my code and the GPS PPS signal - if the software can 'manage' time well enough, then the PPS won't be needed.
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #84 on: February 23, 2021, 01:54:21 pm »
PPS trailing edge interrupt would be fantastic.  Not sure if I can do this in Linux.  Possibly if I go the Ultibo route that DonAlfredo pointed out.

I don't think it's safe to assume you can do that without a kernel module, although the gpiod API has a monitor capability... which still might not get you better than 10 mSec resolution.

And in any event- again- LINUX IS NOT AN RTOS so you can never rely on its latency.

Quote
It's not clear to me yet that I actually need PPS.  But for sure that would be the most accurate time check possible if not for the app then for testing.  I may buy a USB sillyscope to check timing between my code and the GPS PPS signal - if the software can 'manage' time well enough, then the PPS won't be needed.

Remember that you'll find it difficult to get a calibration certificate for GPS, so "the most accurate time check possible" has to be treated cautiously. "The most accurate readily available" perhaps.

A Royal Navy ship (possibly a minesweeper) experimentally disconnected its GPS a few years ago, and found that its primary radar stopped working. A certain amount of paranoia is, IMO, justified.

Re. DSO: https://forum.lazarus.freepascal.org/index.php/topic,53058.msg392300.html#msg392300

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 348
  • My software never cras....
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #85 on: February 23, 2021, 06:40:36 pm »
Quote
Quote
PPS trailing edge interrupt would be fantastic.  Not sure if I can do this in Linux.  Possibly if I go the Ultibo route that DonAlfredo pointed out.

I don't think it's safe to assume you can do that without a kernel module, although the gpiod API has a monitor capability... which still might not get you better than 10 mSec resolution.

And in any event- again- LINUX IS NOT AN RTOS so you can never rely on its latency.

No need to repeat ... got it the first time.  I will, post integration, also try DonAlfredo's suggestion...

As to resolution, if as I believe, the gyro/accel module samples as described, then the integration of that data can take place in nearish realtime and can be soft aligned.  If they have a serial number or timestamp, even better (but I don't believe so).  IOW counting those frames will provide me a time reference at 1/frame_rate s.  I don't know offhand if there's a checksum, so reasonableness checking might be needed as well.

Quote
Quote
It's not clear to me yet that I actually need PPS.  But for sure that would be the most accurate time check possible if not for the app then for testing.  I may buy a USB sillyscope to check timing between my code and the GPS PPS signal - if the software can 'manage' time well enough, then the PPS won't be needed.

Remember that you'll find it difficult to get a calibration certificate for GPS, so "the most accurate time check possible" has to be treated cautiously. "The most accurate readily available" perhaps.

The PPS is the calibration.  These things are, even in the cheapest sensors, on the order of 100 ns or better compared to UTC (at the phase centre of the antenna - if you have cable from the antenna to the correlator front end, then account for propagation in the cable at about 2/3 the speed of light).  IAC I don't care about UTC - I do care about the period.  This necessitates an interrupt, obviously.

The first GPS I'm buying states about 40ns (IIRC).    1 usec period accuracy would be much more than accurate enough for my project.

Quote
A Royal Navy ship (possibly a minesweeper) experimentally disconnected its GPS a few years ago, and found that its primary radar stopped working. A certain amount of paranoia is, IMO, justified.

Shipboard systems (of which I have little experience) have been ever more integrated with what I call hodepodge.  (I'm probably being too cynical).  Shipboard radar systems often integrate GPS for a variety of functions from target indicator computations (velocity, course, etc.) but also to aid signal processing (clutter suppression I believe - don't quote me) as well as simple things like actual bearing v. relative bearing indications.

I'm surprised the radar system didn't have a fallback mode however.  Such in aviation is simply unacceptable for many systems (DO-178B/C level B or A [Boeing didn't heed that on the Max]) and even lesser level systems typically have some functionality when aiding data is not provided.

Quote

Re. DSO: https://forum.lazarus.freepascal.org/index.php/topic,53058.msg392300.html#msg392300

Very interesting.   Not sure why you posted that - if I get a silly scope I'll be running it off of a separate computer with the included s/w.
Haven't decided I'll need it yet.  You did remind me of a product I worked on in the late 80s/ early 90's with a TMS320C25 (or C40) however.

In the meantime since I appreciate everything you've written over the last while (very much!), I will reward you with a curse:
https://www.youtube.com/watch?v=d4EgbgTm0Bg (quaternions - which you may be familiar with... I've found some very nicely done C source code on GitHub that I'll translate to Pascal at some point in the not distant future ...).

https://github.com/MartinWeigel/Quaternion/blob/master/Quaternion.c
« Last Edit: February 23, 2021, 07:02:30 pm by AlanTheBeast »
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #86 on: February 23, 2021, 07:21:06 pm »
No need to repeat ... got it the first time.  I will, post integration, also try DonAlfredo's suggestion...

With respect to everybody concerned, I've looked only slightly at Ultibo and so far I don't recall seeing anything about a *guaranteed* interrupt latency.

Quote
As to resolution, if as I believe, the gyro/accel module samples as described, then the integration of that data can take place in nearish realtime and can be soft aligned.  If they have a serial number or timestamp, even better (but I don't believe so).  IOW counting those frames will provide me a time reference at 1/frame_rate s.  I don't know offhand if there's a checksum, so reasonableness checking might be needed as well.

Perhaps I should have put latency rather than resolution there: don't expect much better than 10 mSec from Linux.

Generally speaking most OSes these days are written to set up hardware transfers of a few Kb and to only have to service a single interrupt on completion. As a reminder that Linux is not an RTOS, it took quite a lot of cleaning up in the 2.5 era to get it good enough to drive MIDI.

Quote
The PPS is the calibration.  These things are, even in the cheapest sensors, on the order of 100 ns or better compared to UTC (at the phase centre of the antenna - if you have cable from the antenna to the correlator front end, then account for propagation in the cable at about 2/3 the speed of light).  IAC I don't care about UTC - I do care about the period.  This necessitates an interrupt, obviously.

The first GPS I'm buying states about 40ns (IIRC).    1 usec period accuracy would be much more than accurate enough for my project.

You misunderstand. Correct me it I'm wrong, but I don't believe that the DoD give out calibration certificates or guarantees of service level.

Quote
I'm surprised the radar system didn't have a fallback mode however.  Such in aviation is simply unacceptable for many systems (DO-178B/C level B or A [Boeing didn't heed that on the Max]) and even lesser level systems typically have some functionality when aiding data is not provided.

Fun fact: you might recall that a French plane was lost in the South Atlantic a few years ago, and they recovered the "black box" in the nick of time before its battery ran out. I read the report, and it appeared that the pilots- at least one of whom wasn't exactly the sharpest knife in the rack- had made absolutely no attempt to refer to GPS to deduce their altitude or rate of ascent/descent. And the report- which was of course French- didn't seem to think that was in any way out of the ordinary.

Quote
In the meantime since I appreciate everything you've written over the last while (very much!), I will reward you with a curse:
https://www.youtube.com/watch?v=d4EgbgTm0Bg (quaternions - which you may be familiar with... I've found some very nicely done C source code on GitHub that I'll translate to Pascal at some point in the not distant future ...).

https://github.com/MartinWeigel/Quaternion/blob/master/Quaternion.c

I'm familiar with them from BRL-CAD, where chunks of the UI are pretty much unusable unless you grok them.

Meanwhile, I'm still trying to sort out some aspects of the gpiod stuff, and am rebuilding my WPi to help out with that. It's the usual sort of Linux problem: sometimes you need to map from a named device in /dev to a more detailed description in /sys, and that can be tedious.

But so far the interface units I posted don't look too bad.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 348
  • My software never cras....
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #87 on: February 23, 2021, 10:04:36 pm »
Quote
With respect to everybody concerned, I've looked only slightly at Ultibo and so far I don't recall seeing anything about a *guaranteed* interrupt latency.

If it's as bare as claimed, and
if it allows the programmer to set a timer, and
if that timer can trigger an interrupt,
that the programmer can set the vector to point at his code,

then I would expect sub microsecond latency.  I'd prefer to code this part in assembler but not a killer if it isn't.  (And I'm not familiar with ARM assembly language and don't want to be unless pressed).  Ultibo does support inline assembler. 

Paired with that I'd want to know what other interrupts are being serviced, for what reason and if there is a priority scheme.  Can I get the highest priority interrupt?  I won't be in there that long.  Promise!

IAC it would appear to have far lower latency risk than Linux, which rumour has it is not an RTOS.  Not sure where I heard that.

Quote
You misunderstand. Correct me it I'm wrong, but I don't believe that the DoD give out calibration certificates or guarantees of service level.

You're quite correct.  They don't.  But it's irrelevant.

US DOD provide the clocks in orbit and monitor them on a four hour cycle against a ground based truth (the 4 hour policy may have changed over the years).  They are very accurate.  Beyond the signal leaving the satellite, the DOD's interest in the matter ends (other than for its government clients).  So first off we trust the US DOD on this.  (No point here in discussing 'what if's' on this IMO.)

Receiver manufacturers derive the 1 PPS (I've forgotten the exact method) in hardware, but it is not difficult to do and it is definitely easy to verify against standards at those labs that have them (depending on the accuracy required)).  It is derived from the signal but the s/w in the receiver has to gate it on once the receiver has sufficient signal from space [number of sats needed depends on the application - a ground station that is accurately surveyed could do with a single satellite, I believe; an aircraft would need 4].  The manufacturers declare in their spec how accurate their 1 PPS signal is for the operating conditions of the spec.  So you trust (and perhaps verify) the accuracy of the device as it is marketed.

Just re-reading the spec sheet for the first device coming in:
60 ns, 99% of the time. 
(This is marketed as "Professional grade". Not sure but seems to be everything that isn't consumer or automotive.  Certainly can't include commercial aviation.)

Further, a pin can be programmed to any rate between 10 MHz down to 4 seconds based on that.  With such I could set up an interrupt at whatever rate convenient to the project...

So we trust and perhaps verify.

Quote
I read the report, and it appeared that the pilots- at least one of whom wasn't exactly the sharpest knife in the rack- had made absolutely no attempt to refer to GPS to deduce their altitude or rate of ascent/descent. And the report- which was of course French- didn't seem to think that was in any way out of the ordinary.

GPS is not a source of altitude info, to begin with, in normal flight operations.  That particular A-340 almost certainly did not have a GPS with VNAV capability (it would be passing PVT to the INS of course).  There is no cockpit indication at all of altitude from GPS other than (possibly) diving into the FMS (to the INS).

Finally, IIRC, the crew merely had to cross check left and right sources and that should have been enough to have them at least suspect they were losing altitude quickly .... also IIRC the left side pitot/static system was the culprit (and there was an airworthiness directive open on that model that Air France hadn't gotten around to sorting out yet...)

Link to the report - je lis le français tres bien ....

Quote
Meanwhile, I'm still trying to sort out some aspects of the gpiod stuff, and am rebuilding my WPi to help out with that. It's the usual sort of Linux problem: sometimes you need to map from a named device in /dev to a more detailed description in /sys, and that can be tedious.

But so far the interface units I posted don't look too bad.

I'll wait until the weekend to get to that....
« Last Edit: February 23, 2021, 11:57:45 pm by AlanTheBeast »
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 348
  • My software never cras....
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #88 on: February 24, 2021, 10:47:12 pm »

Very positive reply from the Ultibo team.

It is very clear that it will handle a high rate of interrupts (way beyond my needs) and that it is direct to my code (must play nice - haven't read the 'rules' but I assume one must handle it fast and reliably...)

Also clear that one can set code to run on a particular core and stick there - though I'm not sure that I'll require that or any particular sensitivity to which core is the running core.

So, what I will aim to do is:

- Program the GPS Timepulse pin to 1 KHz or higher (perhaps 4 Khz) to signal(v) processing cycles and be the time keeper.   Generate flags for lower rate processes as well.  This 'rate' will be extremely accurate (based on GPS time incl. 1 PPS - I assume the GPS receiver has an internal counter slaved to the 1PPS and hopefully that it re-calibrates v. 1 PPS over runtime...)  IAC that level of accuracy (sub 100ns) is not needed.  usec level accuracy is good enough... one issue is that this signal is 3V.  May need to step that up to 5V.

- The Ulbito library provides for queued UART i/o at speeds well in excess of my needs.  There may be a way to electrically sync the accels/gyros to the GPS.  TBD.

- I2C from the accel/gyros I bought maxes out at 400 Kb/s.  This should support 1 KHz sampling - depends how many bytes per frame...  The accel/gyro that supports SPI was out of stock.

I'll probably begin by reviewing MarkMLI's code and using it with current setup to see how far I can push it.

Key parts are still in the Fedex universe somewhere... other parts have trickled in at least.
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC on Rasp Pi, non Lazarus, use of GPIO.
« Reply #89 on: February 25, 2021, 11:29:57 am »
Wrapping this up from my POV, after comparing GPIO handling on a PC and a Raspberry Pi, with particular emphasis on the (new) gpiod API.

On an RPi, the on-board GPIO lines are handled by code statically linked into the kernel, so it should be possible to rely on their naming order even in the absence of other "hints". That does not apply to a PC, or to any other target where GPIO support is loaded from a kernel module; in that case the device order will change depending on the order that kernel modules are loaded at boot and/or the order that GPIO devices are plugged in.

I can confirm that on an RPi, Raspbian ("Raspberry Pi OS") associates both on-board and USB-connected GPIO ports with group "gpio", while on a PC (Debian) the user will need root privilege to perform most operations. This might be an oversight or might be intentional, since a significant proportion of Linux PCs are operating as servers and there have already been reports of badly-configured hardware and software allowing access to critical system buses and devices.

Now to discuss the "hints".

The classic GPIO text-based API, which is used by almost all demos so far, puts entries in /sys/class/gpio where the names are related to the bus position. So on an RPi with internal GPIO devices one sees

gpiochip0  gpiochip100  gpiochip504

while on an RPi which also has a USB-connected CH341 board (plus kernel module) one sees

gpiochip0  gpiochip100  gpiochip496  gpiochip504

In this particular case it is the gpiochip496 device which is USB-connected, but assume that number will "wander" depending on the USB topology.

There will also be /dev/gpiochip* devices, but these are numbered sequentially:

gpiochip0  gpiochip1  gpiochip2  gpiochip3

If the gpiod package is installed, the gpiodetect command describes these as


# gpiodetect
gpiochip0 [pinctrl-bcm2835] (54 lines)
gpiochip1 [brcmvirt-gpio] (2 lines)
gpiochip2 [raspberrypi-exp-gpio] (8 lines)
gpiochip3 [i2c-ch341] (8 lines)


and this may be cross-referenced with what's in /sys/class/gpio:


# cat gpiochip0/label
pinctrl-bcm2835
# cat gpiochip100/label
brcmvirt-gpio
# cat gpiochip504/label
raspberrypi-exp-gpio
# cat gpiochip496/label
i2c-ch341


If multiple CH341 (or similar) cards were plugged in, it would be difficult to distinguish them. However for USB devices I think this is relevant:


# ls -ld /sys/class/gpio/gpiochip496/device/gpiochip*
drwxrwx--- 3 root gpio 0 Feb 25 09:41 gpiochip496/device/gpiochip3


Hence assuming that the labels associated with on-board GPIO devices are unique, I think it's possible to get sufficient "hints" to work out the disposition of devices that might "wander".

The reason that this is important is that the "new" gpiod API opens devices by device name (i.e. /dev/gpiochip3 etc.) and can then extract the label and the number of GPIO lines:

Code: Pascal  [Select][+][-]
  1.   chipHandle := Gpiod.gpiod_chip_open(PChar('/dev/gpiochip3');
  2.   if chipHandle = nil then
  3.     exit;
  4.   ngpio := Gpiod.gpiod_chip_num_lines(chipHandle);
  5.   chipLabel := StrPas(Gpiod.gpiod_chip_label(chipHandle));
  6.  

What it can't extract however is the base of the group of GPIO lines physically supported by the chip, and knowing that can be important if the lowest GPIO line on a device can vary. As a concrete example, the CH341 can be handled either as an I2C+GPIO device with 8x GPIO lines, or an SPI+GPIO device with only 2x GPIO lines... the *top* two, but despite the physical difference in both cases the GPIO lines are numbered from zero (0..7 or 0..1 respectively).

I think that covers most details, I suppose I ought to tack it into the wiki at some point.

MarkMLl
« Last Edit: February 25, 2021, 11:40:42 am by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018