ioctl messages to Beagle SPI port.

GoogleGroups
21

Because this example program uses the high speed gpio the fault happens much sooner on the Pi without the sudo.

pi@raspberrypi:~/projects/lazarus/TC $ ./TC
An unhandled exception occurred at $00084EE4:
                                             ERPiOpenFile: Cannot not open file </dev/mem> for memory mapping.
                                $00084EE4 TFASTSYSTEMCORE__CREATE, line 451 of /home/pi/projects/lazarus/pxl/Source/PXL.Boards.RPi.pas
                                                          $00010410 main, line 95 of TC.lpr

I'll build that project on the Beagle and see what happens.
John

OK. Hadn't noticed until I tried it on the Beagle that it uses PXL.Boards.RPi.pas which has the definitions for the high speed I/O. The Beagle doesn't appear to have that feature as there is no PXL.Boards.BBB.pas file. Looks like Beagle I/O has to go through the file system.

So this particular SPI program is _not_ portable from the Pi to the Beagle and therefore I will stop talking about it on this Beagleboard forum.

John

22

Hi Dennis,
I tried on the groups site to edit this post and change what I wrote.

  While the master copy appears to be a Google Groups entry, it seems to
be propagated outward since gmane is able to copy it and provide NNTP
access (which is how I'm reading -- but about a year ago submitted replies
via gmane were getting rejects from the main group, so I've had to email
replies to Google...).

  NNTP spec does offer a CANCEL command to delete posts... BUT most
servers have disabled that (too easy to spoof a user and delete posts one
objects to, perhaps).

  Since the messages are on distributed servers, they are essentially
"fire and forget" -- there is nothing one can do once they've hit send...

It's a good point you make there. However then the SizeOf function might well return something different in size to make everything fit. I've also heard of systems re-arranging the members of a record to suit. In pascal to make that happen you defined it as packed.

  My concern was that the C code might be packing things differently from
FreePascal, which could mean some of the arguments will not be where the
kernel expects to find them.

  OTOH: I believe ARM Cortex architecture is defined to use byte
alignment (even if word/longword alignment is how the memory bus operates),
so both C and Pascal should be generating packed structures.

Because this example program uses the high speed gpio the fault happens much sooner on the Pi without the sudo.

pi@raspberrypi:~/projects/lazarus/TC $ ./TC
An unhandled exception occurred at $00084EE4:
                                            ERPiOpenFile: Cannot not open file </dev/mem> for memory mapping.
                               $00084EE4 TFASTSYSTEMCORE__CREATE, line 451 of /home/pi/projects/lazarus/pxl/Source/PXL.Boards.RPi.pas
                                                         $00010410 main, line 95 of TC.lpr

  That may be devolving to the similar timing problem as earlier -- if it
is doing memory mapping to get to GPIO rather than using the sysfs access,
it may take time to get memory privileges set up.

https://man7.org/linux/man-pages/man4/mem.4.html

Hmmm, it appears that /dev/mem is a udev victim. Freshly booted a BBB gave

crw-r----- 1 root root 1, 1 Dec 31 1999 mem

but repeating the command a few seconds later shows

crw-r----- 1 root kmem 1, 1 May 25 23:45 /dev/mem

(note that the first is using the system default date, while the second is
after the system synched clocks).

  Making the R-Pi user a member of group kmem might improve things; the
Beagle already has kmem for user

debian@beaglebone:~$ groups debian
debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users
systemd-journal input bluetooth netdev i2c gpio admin spi iio docker tisdk
weston-launch xenomai cloud9ide pwm eqep remoteproc
debian@beaglebone:~$

23

OK. Hadn't noticed until I tried it on the Beagle that it uses PXL.Boards.RPi.pas which has the definitions for the high speed I/O. The Beagle doesn't appear to have that feature as there is no PXL.Boards.BBB.pas file. Looks like Beagle I/O has to go through the file system.

  Well -- it might be possible to clone the R-Pi version and redefine all
the memory and bitmap addresses to match the BBB <G>, and then modify
whatever code detects the platform...

So this particular SPI program is _not_ portable from the Pi to the Beagle and therefore I will stop talking about it on this Beagleboard forum.

  Technically, I think the "program" source is portable, but not binaries
-- the device access is different between the two, but the end result
should be the same.

  See my previous response regarding the R-Pi kmem group membership.

24

And yet more progress using the pxl library and Lazarus with the rewritten code from the pxl Blinky.pas example and adafruit_max31855.py. SPI bus operation. Source code attached.

debian@ebb:~/lazarus/TC$ ./TC
Reading temperature, press any key to exit...
Temperature: 21.25C 70.25F
Temperature: 21.25C 70.25F
Temperature: 21.25C 70.25F
Temperature: 21.5C 70.7F
Temperature: 21.25C 70.25F

John

TC.lpr (3.96 KB)

25

Hi Dennis,
I will investigate that further. Wanted to get the SPI bus Type K Thermocouple module working first. Baby steps.
The code is slightly different from the Pi but not radically so. I used '/dev/spi/0.0' since there is no '/dev/spidev0.0' on my Beagle.

  My concern was that the C code might be packing things differently from
FreePascal, which could mean some of the arguments will not be where the
kernel expects to find them.

  OTOH: I believe ARM Cortex architecture is defined to use byte
alignment (even if word/longword alignment is how the memory bus operates),
so both C and Pascal should be generating packed structures.

>Because this example program uses the high speed gpio the fault happens much sooner on the Pi without the sudo.
>
>pi@raspberrypi:~/projects/lazarus/TC $ ./TC
>An unhandled exception occurred at $00084EE4:
> ERPiOpenFile: Cannot not open file </dev/mem> for memory mapping.
> $00084EE4 TFASTSYSTEMCORE__CREATE, line 451 of /home/pi/projects/lazarus/pxl/Source/PXL.Boards.RPi.pas
> $00010410 main, line 95 of TC.lpr
>

  That may be devolving to the similar timing problem as earlier -- if it
is doing memory mapping to get to GPIO rather than using the sysfs access,
it may take time to get memory privileges set up.

mem(4) - Linux manual page

Hmmm, it appears that /dev/mem is a udev victim. Freshly booted a BBB gave

crw-r----- 1 root root 1, 1 Dec 31 1999 mem

but repeating the command a few seconds later shows

crw-r----- 1 root kmem 1, 1 May 25 23:45 /dev/mem

(note that the first is using the system default date, while the second is
after the system synched clocks).

I get the same /dev/mem value. I thought about adding time delays in there but that would just be me hacking away at trying things without knowing why. Normally for me a waste of time.

  Making the R-Pi user a member of group kmem might improve things; the
Beagle already has kmem for user

The Code works on the Pi but not on the Beagle using the PXL.DevicePi or whatever it was named. There may be other processor specific items in that unit that just won't work with direct memory access. When I have some time I'll take a closer look at how hardware is access directly on the Pi compared to the BBB. It would be useful to have a DeviceBBB. However even with belonging to the kmem group it's really not happy with /dev/mem so something else is up there.

I did notice that the delay periods were rock solid.

John

26

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Dennis Lee Bieber

>
>OK. Hadn't noticed until I tried it on the Beagle that it uses PXL.Boards.RPi.pas which has the definitions for the high speed I/O. The
Beagle doesn't appear to have that feature as there is no PXL.Boards.BBB.pas file. Looks like Beagle I/O has to go through the file
system.

  Well -- it might be possible to clone the R-Pi version and redefine all
the memory and bitmap addresses to match the BBB <G>, and then modify
whatever code detects the platform...

That would have to be done.

>
>So this particular SPI program is _not_ portable from the Pi to the Beagle and therefore I will stop talking about it on this
Beagleboard forum.

  Technically, I think the "program" source is portable, but not binaries
-- the device access is different between the two, but the end result
should be the same.

Well almost. In the uses section PXL.Devices.RPi or PCL.Devices.BBB would be one area set up with an
{$IFDEF}

Same with the path to the SPI.

And the code was designed to run more than 1 SPI device which is why they were inclining to perhaps two or three SEL lines and a decoder to deal with more than one. The comment in the code as I recall was to leave the actual physical SPI0 CS disconnect since it can't be disabled and used as gpio with the SPI active. Although it did seem like it with the config-pins function. At least on the Beagle.

Tomorrow I'll take a closer look at the structures and write a dump utility to compare the two. That should give a clue as to where the system ioctl is hiccupping.
John