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.
> 
> 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).
> 
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

--
> Dennis L Bieber
> 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/02bd01d751e5%2469cef350%243d6cd9f0%24%40autoartisans.com.

Reply via email to