I agree, the C code uses the equivalent of the WITH statement in Pascal to
assign parameters during structure declaration. Once you 'get' how it works
it's fairly readable.
My understanding is both systems place the variables on the heap. Only the
small micro-controllers with limited stack space (recall some of the PIC16
series had a 2 word call stack). Other systems in the micro-controller area
might limit the stack to 256 bytes due to paging schema.
The record (struct) is essentially the same in C or Pascal.
spi_ioc_transfer = record
tx_buf: UInt64;
rx_buf: UInt64;
len: LongWord;
speed_hz: LongWord;
delay_usecs: Word;
bits_per_word: Byte;
cs_change: Byte;
pad: LongWord;
end;
The C one with some extra information about the requirements of the structure
is here:
https://github.com/spotify/linux/blob/master/include/linux/spi/spidev.h
In both cases the requirement is that they are 32 bytes in length hence the pad
at the end.
Filling it with zero's first implies that the transition of the address of a
BYTE buffer to unsigned 64 bit is probably being corrupted in some unexpected
way. With Pascal, generally, globals are initialized to 0's as are C
variables unless you add the flag to not initialize in the C startup code.
Locals on the stack are not for both languages.
The pxl library was last updated in 2017 and there are photos and fritzing
diagrams on how to connect hardware so that the image on the displays is
created by the example programs (both Pi and BBB). That it worked in 2017 and
now doesn't means something in either the OS and the ioctl() interface has
changed or the FreePascal compiler is doing something different.
And that other link that I now can't find anymore shows that even for the Pi3 a
C program without the fill structure with 0's will fail in exactly the same
way. Don't remember the date. May well have been roughly the same revision OS
which means the issue might well have been in the ioctl() at the OS level for
SPI bus.
As the attached screen shot shows, SPI packets are now longer than 1 or 2 bytes
on a Beaglebone with code written in Pascal. It's finally behaving.
For now I'm going to consider this 'fixed' and I will pass on the information
to the pxl library source.
BTW. For the Pi to make this work I have to either run it with sudo from the
command line or run Lazarus with sudo. The help everyone provided on the
Beagle to make my user part of the gpio group means the code can run and be
debugged from within the IDE.
Thanks
John
> -----Original Message-----
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On
> Behalf Of Dennis Lee Bieber
> Sent: May-25-21 10:39 AM
> To: Beagleboard
> Subject: [beagleboard] Re: ioctl messages to Beagle SPI port.
>
> On Tue, 25 May 2021 09:45:39 -0700, in gmane.comp.hardware.beagleboard.user
> "John Dammeyer" < <mailto:johnd-5o6ditlojsohvde0pjs...@public.gmane.org>
> johnd-5o6ditlojsohvde0pjs...@public.gmane.org> wrote:
>
>
> >
> >Here's the BBB version from and you can see the code is identical for both
> >the Pi and the Beagle.
> > <https://github.com/derekmolloy/exploringBB/blob/version2/chp08/spi/spidev_test/spidev_test.c>
> >
> > https://github.com/derekmolloy/exploringBB/blob/version2/chp08/spi/spidev_test/spidev_test.c
> >==============================================================================================
> >uint8_t rx[ARRAY_SIZE(tx)] = {0, };
> > struct spi_ioc_transfer tr = {
> > .tx_buf = (unsigned long)tx,
> > .rx_buf = (unsigned long)rx,
>
> Somewhat confusing code -- one has to track upwards in the
> code... C
> arrays are a synonym for pointers, so he's using unsigned long to store a
> pointer to the array.
>
> I'm not downloading the source again to see how the buffers are
> defined...
> >
> > Data.tx_buf := PtrUInt(WriteBuffer);
> > Data.rx_buf := PtrUInt(ReadBuffer);
>
> ... just notice this explicitly asks for a pointer (given my stale C
> history, I'd tend to read that as a pointer to an unsigned integer of some
> size... But the C version has the buffers defined as uint8_t (new in
> C99/C++11) with is an 8-bit unsigned (equivalent to old unsigned char).
>
> Does FreePascal have size differentiation?
>
>
>
> >It's likely the C compiler clears this structure when it's declared or
> >extends 0's out on an assignment that isn't done by the FreePascal
> compiler. And that it was required in that Pi forum posting for C code
> suggests it's perhaps even somewhat random. Compiler flags
> maybe?
>
> """
> -fno-zero-initialized-in-bss
>
> If the target supports a BSS section, GCC by default puts variables
> that are initialized to zero into BSS. This can save space in the resulting
> code.
> """
>
> is the closest GCC option I saw. The OS may do zeroing when it allocates a
> block of memory to the application, but that wouldn't affect stack usage --
> and the C code is allocating the structure on the stack. I presume Pascal
> is doing the same (since it allows recursion). Not seeing the declaration
> of "Data" means I can't be certain -- FreePascal may have keywords to force
> allocation on heap..
>
>
>
> --
> Dennis L Bieber
>
> --
> For more options, visit <http://beagleboard.org/discuss>
> 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 <mailto:beagleboard+unsubscr...@googlegroups.com>
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> <https://groups.google.com/d/msgid/beagleboard/r4cqagp6uljj4n53p65c3j4tl6ds3078uj%404ax.com>
>
> https://groups.google.com/d/msgid/beagleboard/r4cqagp6uljj4n53p65c3j4tl6ds3078uj%404ax.com.
--
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/022a01d7519f%24ed925880%24c8b70980%24%40autoartisans.com.
