gridrun
Posts: 46
Joined: Mon Feb 18, 2013 12:26 pm
Contact: Website

Re: SPI driver latency and a possible solution

Mon Feb 25, 2013 7:17 pm

Thank you msperl, for this ingenious contribution of yours!
Keep up the good work! 8-)
Find more info on Raspberry Pi, Virtualization and all things cloudy on my blog: http://niston.wordpress.com

msperl
Posts: 325
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Feb 25, 2013 8:12 pm

Thanks - it still has not made it into the default raspien tree...

Anyway: my intention is to improve the patch much further, so that we can DMA right into userspace without having to spend CPU cycles...

Of most interest for for ADC converters at high bandwidth...

Martin

Marinov
Posts: 5
Joined: Tue Dec 04, 2012 7:56 am

Re: SPI driver latency and a possible solution

Thu Apr 11, 2013 7:43 am

Hello,

I want to ask for help. I am using 100k sample ADC, connected via SPI, but I am experiencing same SPI latency problems. I did try almost every posted patch, but I get errors during patching. I guess that something changed since February in 3.6 kernel source. I don’t have experience and I am not able to find the problem. Can someone upload updated patch or even upload compiled kernel? Thank you in advance.

msperl
Posts: 325
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Thu Apr 18, 2013 3:00 pm

Take the version from the git-repository (https://github.com/msperl/linux)
Just download the spi-bcm2708.c file and put it in your downloaded kernel.
Alternatively clone the repository itself and build the kernel from that...

See here for the patch to the kernel version 3.6 from the repository that works for me:
https://github.com/msperl/linux/commit/ ... 081178d268

Martin

Marinov
Posts: 5
Joined: Tue Dec 04, 2012 7:56 am

Re: SPI driver latency and a possible solution

Thu Apr 25, 2013 7:20 am

Thank you Martin,

I have downloaded spi-bcm2708.c from your git-repository and placed over the existing one. The kernel compiled successfully, but I still have delays. From CS falling edge to first clock I have around 10us, from the last clock to the rising edge of CS I have 10-50us. I also observe second false CS signal after the correct one. Any idea why I still have delays or false CS signal? I am using python. My plan is to collect 10k (or 100k) samples and then process the data. Precise timing between the samples is critical. What is the best way to achieve this? Thank you in advance.

Tsvetan Marinov

Petr
Posts: 9
Joined: Sun Oct 09, 2011 8:51 am

Re: SPI driver latency and a possible solution

Thu Apr 25, 2013 9:48 pm

Hi Martin,
I am not experienced enough so I do not know if my question is OK.
Anyway: can you, please, put your SPI patched kernel on-line?
This can help beginners a lot (compilation is not necessary)?

Regards

Petr

notro
Posts: 682
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: SPI driver latency and a possible solution

Fri Apr 26, 2013 3:48 pm

Petr wrote: Anyway: can you, please, put your SPI patched kernel on-line?
This can help beginners a lot (compilation is not necessary)?
I have made a binary version of the driver that should work with this image: 2013-02-09-wheezy-raspbian
It's only tested with the loopback test. I don't have anything to test it with, because I only have SPI displays which need a custom kernel.
Please report success or failure.

Code: Select all

uname -a
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux

wget -O spi-bcm2708.zip http://tronnes.org/download.php?file=spi-bcm2708.zip
unzip spi-bcm2708.zip
cp -v spi-bcm2708.ko /lib/modules/3.6.11+/kernel/drivers/spi/spi-bcm2708.ko

pasifus
Posts: 17
Joined: Sat Jan 19, 2013 9:35 am

Re: SPI driver latency and a possible solution

Sat Apr 27, 2013 7:07 am

notro wrote:
Petr wrote: Anyway: can you, please, put your SPI patched kernel on-line?
This can help beginners a lot (compilation is not necessary)?
I have made a binary version of the driver that should work with this image: 2013-02-09-wheezy-raspbian
It's only tested with the loopback test. I don't have anything to test it with, because I only have SPI displays which need a custom kernel.
Please report success or failure.

Code: Select all

uname -a
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux

wget -O spi-bcm2708.zip http://tronnes.org/download.php?file=spi-bcm2708.zip
unzip spi-bcm2708.zip
cp -v spi-bcm2708.ko /lib/modules/3.6.11+/kernel/drivers/spi/spi-bcm2708.ko
i tested you driver and it still have delay

Code: Select all

pi@raspberrypi /media/msp/raspberry/rapi-linux $ uname -a
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux
Image

Image

Petr
Posts: 9
Joined: Sun Oct 09, 2011 8:51 am

Re: SPI driver latency and a possible solution

Sat Apr 27, 2013 7:29 am

@pasifus
@msperl
Just wonder what kind/brand of analyzer are you using?
Pictures are looking great.

pasifus
Posts: 17
Joined: Sat Jan 19, 2013 9:35 am

Re: SPI driver latency and a possible solution

Sat Apr 27, 2013 10:55 am

logic
www.saleae.com
Petr wrote:@pasifus
@msperl
Just wonder what kind/brand of analyzer are you using?
Pictures are looking great.

notro
Posts: 682
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: SPI driver latency and a possible solution

Sun Apr 28, 2013 2:25 pm

pasifus wrote: i tested you driver and it still have delay
It's really not "my " driver, I just compiled msperl's driver so it loads on the stock raspian image.

This is how I did it:

Starting with a fresh image: 2013-02-09-wheezy-raspbian

Code: Select all

sudo raspi-config
  expand_rootfs
# reboot when asked

Code: Select all

apt-get update
apt-get install -y git-core
Get kernel headers

Code: Select all

cd /usr/src
git clone --depth 1 git://github.com/raspberrypi/linux.git
ln -s /usr/src/linux /lib/modules/3.6.11+/build
cd linux
Prepare headers

Code: Select all

zcat /proc/config.gz > .config
make oldconfig
make prepare
make modules_prepare
Get Module.symvers and System.map that match the running kernel
Find the firmware commit that is used for this image

Code: Select all

zcat /usr/share/doc/raspberrypi-bootloader/changelog.Debian.gz | head
raspberrypi-firmware (1.20130207-1) unstable; urgency=low

  * firmware as of 5dd9b4962e

 --  <asb@asbradbury.org>  Sat, 09 Feb 2013 00:20:15 +0000

raspberrypi-firmware (1.20130203-1) unstable; urgency=low

   *firmware as of efc9c98fa
Find commit (5dd9b4962e) and get the file versions we need: https://github.com/raspberrypi/firmware ... 5dd9b4962e

Code: Select all

pwd
/usr/src/linux

wget -O Module.symvers https://raw.github.com/raspberrypi/firmware/5dd9b4962eb5ae9b9cd9f4a1cbfada360521fee4/extra/Module.symvers

# Not sure if this is really needed
wget -O System.map https://github.com/raspberrypi/firmware/blob/5dd9b4962eb5ae9b9cd9f4a1cbfada360521fee4/extra/System.map?ra
Compile SPI Controller driver

Code: Select all

cd
mkdir -p src/latency
cd src/latency

wget https://raw.github.com/msperl/linux/rpi-3.6.y/drivers/spi/spi-bcm2708.c
nano Makefile

Code: Select all

obj-m += spi-bcm2708.o

all:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
Since we are not rebuilding the kernel we have to patch the driver with some info that should be in bcm2708.c:
diff spi-bcm2708.c

Code: Select all

@bcm2708_spi_probe
	struct bcm2708_spi *bs;
	const char* mode;
	
+	#define DMA_MASK_BITS_COMMON 32
+	pdev->dev.coherent_dma_mask = DMA_BIT_MASK(DMA_MASK_BITS_COMMON);
+
 	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);

Code: Select all

make

insmod spi-bcm2708.ko
dmesg
bcm2708_spi bcm2708_spi.0: DMA channel 0 at address 0xf2007000 with irq 16
bcm2708_spi bcm2708_spi.0: DMA channel 4 at address 0xf2007400 with irq 20
spi_master spi0: will run message pump with realtime priority
bcm2708_spi bcm2708_spi.0: SPI Controller at 0x20204000 (irq 80)
bcm2708_spi bcm2708_spi.0: SPI Controller running in interrupt-driven mode
This would all have been so simple if someone provided a kernel headers package: apt-get install linux-headers-$(uname -r)
Sadly I have never taken the time to learn how to make an APT package :|

jwasch
Posts: 12
Joined: Wed May 01, 2013 3:10 pm

Re: SPI driver latency and a possible solution

Wed May 01, 2013 3:30 pm

Impressive effort going after latency. Can anyone please answer a few basic questions since I would like also to modify the kernel driver to allow 32-bit wide transfers. So far, I find this causes an error in the ioctl() call to initiate the transfer, though I can see on my oscilloscope that 8-bit transfers are working just fine. I could send-down multiple transfers and manage CS to make one long transaction period like I want, but I think that may waste FIFO space and produce more interrupts. I apologize for the basic-level of these questions:

1. The RPI uses BCM2835. The closest file in the drivers directory is spi-bcm2708.c (which you mention), but the register map of #define's doesn't appear anything like the BCM2835 "Universal SPI Master" peripheral in the broadcom documentation. Is this the kernel driver source code file I should be starting with? If so, can you briefly explain the discrepancy. If not, can you suggest which source code file is applicable?

2. Does the form of the driver that you modified for interrupt-driven transfers with DMA allow 32-bit wide transfers (set 6 least-significant bits in the "AUXSPI0/1_CNTL0 Register - 0x7E21 5080,0x7E21 50C0" to 32?

Thank you.

jwasch
Posts: 12
Joined: Wed May 01, 2013 3:10 pm

Re: SPI driver latency and a possible solution

Wed May 01, 2013 4:16 pm

Followup - I see now that there are two SPI blocks inside the SOC, and that the bcm2708 driver corresponds to the second (NOT the one called "Universal SPI Master (2x)." And I see that bcm2708 is the family code for bcm2835 is the specific SOC code. So I think I have my answers for now. Thanks, and sorry for the fire-drill.

borg42
Posts: 1
Joined: Thu May 02, 2013 12:54 pm

Re: SPI driver latency and a possible solution

Thu May 02, 2013 1:14 pm

Hi,

I have a similar problem with SPI delays.

Image

The protocol i have to speak is as follows:

1. Send 0xFF until slave responds with 0xFF
2. Transceive length (if slave has nothing we get 0, if master has nothing to send it sends 0).
3. Transceive payload (length: MAX(slave_length, master_length))
4. Transceive CRC
5. Transceive ACK/NACK (ACK if crc was correct, NACK otherwise. If we have to send or receive a NACK, the whole process is repeated).

The problem here is, that we have 5 steps and for each step we have to wait for the data from the step before. In the screenshot you can see 3x 0xFF, then 1x length, then the payload, then the CRC and then the ACK.

You can see that transmitting the data (quite a few bytes) only takes ~60us, while the whole process takes over 600us because of the delays between each of the steps. The whole communication between a microcontroller and the same slave takes about ~65us.

The delay until the slave select deasserts and the delay between the transfers is really killing us here. Is the delay because of the user space implementation? Whould we get less delay if we implemented the protocol as a kernel module?

I already started the application as root with nice -n -20.

Really frustrating that it works in principle but is not usable since it is too slow :(.

jwasch
Posts: 12
Joined: Wed May 01, 2013 3:10 pm

Re: SPI driver latency and a possible solution

Thu May 02, 2013 3:03 pm

Using the 3.2.27 kernel driver, I'm unable to set bits_per_word to be anything other than 8 during the SPI_IOC_MESSAGE ioctl call. Test program says invalid argument, but not sure this is a reliable message. Am able to set the SPI_IOC_WR_BITS_PER_WORD, and is read-back reliably, but doesn't seem to do anything with this value. I'm trying to use 32 bit transfers. By setting len=word*4 and using bits_per_word=8, oscilloscope output shows multiple 32-bit transfers gathered-together under one chip-select transaction, like I want, but it has gaps between individual bytes. I suspect this comes from processing FIFO to initiate next byte of transfer, and I suspect since FIFO contained all data (only sent 8 bytes), that the gaps are short and predictable. If larger blocks are sent, I suspect software latencies involved in filling the FIFO will cause bigger gaps at unpredictable times. Some of this is okay, but I'd like to minimize. - - - Does anyone know if I can operate this SPI in a 32-bit word mode, This should reduce software latencies by at least 4-times.

notro
Posts: 682
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: SPI driver latency and a possible solution

Thu May 02, 2013 3:40 pm

jwasch wrote: Using the 3.2.27 kernel driver, I'm unable to set bits_per_word to be anything other than 8 during the SPI_IOC_MESSAGE ioctl call. Test program says invalid argument, but not sure this is a reliable message.
The SPI Controller hardware exposed on the header only supports 8 and 9 bit words.

notro
Posts: 682
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: SPI driver latency and a possible solution

Tue May 07, 2013 7:46 pm

Marinov wrote: From CS falling edge to first clock I have around 10us, from the last clock to the rising edge of CS I have 10-50us.
The datasheet states this in 10.6.4 Notes

Code: Select all

Setup and Hold times related to the automatic assertion and de-assertion of the CS lines 
when operating in DMA mode (DMAEN and ADCS set) are as follows: 
The CS line will be asserted at least 3 core clock cycles before the msb of the first byte of the 
transfer. 
The CS line will be de-asserted no earlier than 1 core clock cycle after the trailing edge of the 
final clock pulse. 
With a core clock running at 250 MHz this translates to:
CS active to clock >12 ns
clock to CS inactive >4 ns

But I assume your python module don't do dma from userspace, so the driver will default to interrupt mode.
From bcm2708_transfer_one_message()

Code: Select all

		/* check if elegable for DMA */
		if ((xfer->tx_buf)&&(!xfer->tx_dma)) { can_dma=0; }
		if ((xfer->rx_buf)&&(!xfer->rx_dma)) { can_dma=0; }
When in interrupt mode this is what happens (bcm2708_transfer_one_message_irqdriven):
Interrupts is disabled.
Transfer is started by setting TA bit in CS register. According to 10.6.2 Interrupt in the datasheet, this immediately triggers a first interrupt.
FIFO is filled.
Interrupts is enabled.
The interrupt routine is called: RX FIFO is emptied, if no more to send clear TA

In theory this should not generate the latency you experience.

Maybe the controller doesn't start transferring before it has triggered the interrupt.
See this about interrupt latency: http://jjackowski.wordpress.com/2013/03 ... 10%CE%BCs/


Driver source code: https://github.com/msperl/linux/blob/rp ... -bcm2708.c


Edit:
The datasheet doesn't say how large the FIFO is, only that 16 bytes should be written in interrupt mode.
When writing many bytes, are there recurring "interrupt latency" gaps in the transfer?

Sidenote: The vanilla driver doesn't prefill the FIFO and thus uses the first interrupt to fill it.
Source: https://github.com/raspberrypi/linux/bl ... -bcm2708.c

jwasch
Posts: 12
Joined: Wed May 01, 2013 3:10 pm

Re: SPI driver latency and a possible solution

Wed May 08, 2013 6:34 pm

Got 3.6.11+ from github and compiled kernel plus modules. Replaced my kernel.img and modules and firmware files, and copied hard floating point gpu libraries. Using fedora distribution. All worked fine and reboot was successful. An error message came up when trying to run "/opt/vc/bin/vcgencmd" saying couldn't find "/lib/ld-linux-armhf.so.3" but not too concerned about GPU for now (but if anybody knows about this, please, I would appreciate any guidance). Biggest negative is my test_spi program no longer works. Don't get any error messages, but don't see any activity on any of the IO pins. This all worked perfectly on 3.2.27, even after I rebuilt kernel and modules from tarball source and installed it.

1. I compiled with the default configuration file, and pressed return to accept defaults for all new configuraiton items. Maybe I should have selected something special for DMA or for SPI?

2. I'm opening "/dev/spidev0.0" and I recall I hand-modified this from the original source code for the SPI test program I found on the internet. The file system only shows /dev/spidev0.0 and /dev/spidev0.1, but maybe I need to set-up links to different names since I am on a fedora distribution??

Any clues would be greatly appreciated. Thank you.

jwasch
Posts: 12
Joined: Wed May 01, 2013 3:10 pm

Re: SPI driver latency and a possible solution

Fri May 10, 2013 3:13 am

I got it working on 3.6.11+. For anybody who might have similar problems, I was cross-compiling on a Fedora distribution running on a PC, and when I did "make oldconfig" it somehow used the configuration of the build machine for certain default settings. Not entirely certain. But I cancelled the "make oldconfig" and copied a new .config from arch/configs folder, and then did a build, it worked. I noticed right away that the default processor selection was 54.raspberry pi, instead of some generic arm that had been shown before. New compile results transferred onto the SD CARD booted successfully and ran my SPI test successfully. Next step is to integrate this new SPI driver that has DMA and is interrupt-driven for lower-latency. I think that can be patched into this 3.6.y branch from the 3.8.y branch.

jwasch
Posts: 12
Joined: Wed May 01, 2013 3:10 pm

Re: SPI driver latency and a possible solution

Fri May 10, 2013 5:08 pm

Yahoo. Edited arch/arm/mach-bcm2708.c to add .dev clause, and replaced drivers/spi/spi-bcm2708.c, recompiled and reloaded kernel and modules, and it worked!! Next I'll test different processing modes for throughput. Goal is to program FPGA with single huge SPI transfer, so may need to look into 4096 byte single page buffer limit.

jwasch
Posts: 12
Joined: Wed May 01, 2013 3:10 pm

Re: SPI driver latency and a possible solution

Sat May 11, 2013 3:22 pm

Does anybody have an example of how to use "struct spi_ioc_transfer" to initiate SPI transfer with DMA processing mode enabled? From user-space, before the ioctl(), I presume I set-up rx_dma and tx_dma with some buffer addresses. Do I therefore NOT send down buffer addresses in rx_buf and tx_buf? Do I need to lock these buffers down or memory-map them in some way or does the driver do this so they're not swapped during background processing? Is the new "processing mode" inferred from the contents of these new fields or does it have to be set somewhere else beforehand? Does the driver need to be compiled with processing=2 (DMA) or is the compile-time setting a default and runtime conditions will indicate which mode will be used for any particular transfer?

pasifus
Posts: 17
Joined: Sat Jan 19, 2013 9:35 am

Re: SPI driver latency and a possible solution

Wed May 15, 2013 10:13 am

after module build and run:

pi@raspberrypi ~/src/latency $ sudo insmod spi-bcm2708.ko
Error: could not insert module spi-bcm2708.ko: Invalid module format
pi@raspberrypi ~/src/latency $ tail /var/log/kern.log
May 15 10:12:23 raspberrypi kernel: [ 3218.043562] spi_bcm2708: no symbol version for module_layout


notro wrote:
pasifus wrote: i tested you driver and it still have delay
It's really not "my " driver, I just compiled msperl's driver so it loads on the stock raspian image.

This is how I did it:

Starting with a fresh image: 2013-02-09-wheezy-raspbian

Code: Select all

sudo raspi-config
  expand_rootfs
# reboot when asked

Code: Select all

apt-get update
apt-get install -y git-core
Get kernel headers

Code: Select all

cd /usr/src
git clone --depth 1 git://github.com/raspberrypi/linux.git
ln -s /usr/src/linux /lib/modules/3.6.11+/build
cd linux
Prepare headers

Code: Select all

zcat /proc/config.gz > .config
make oldconfig
make prepare
make modules_prepare
Get Module.symvers and System.map that match the running kernel
Find the firmware commit that is used for this image

Code: Select all

zcat /usr/share/doc/raspberrypi-bootloader/changelog.Debian.gz | head
raspberrypi-firmware (1.20130207-1) unstable; urgency=low

  * firmware as of 5dd9b4962e

 --  <asb@asbradbury.org>  Sat, 09 Feb 2013 00:20:15 +0000

raspberrypi-firmware (1.20130203-1) unstable; urgency=low

   *firmware as of efc9c98fa
Find commit (5dd9b4962e) and get the file versions we need: https://github.com/raspberrypi/firmware ... 5dd9b4962e

Code: Select all

pwd
/usr/src/linux

wget -O Module.symvers https://raw.github.com/raspberrypi/firmware/5dd9b4962eb5ae9b9cd9f4a1cbfada360521fee4/extra/Module.symvers

# Not sure if this is really needed
wget -O System.map https://github.com/raspberrypi/firmware/blob/5dd9b4962eb5ae9b9cd9f4a1cbfada360521fee4/extra/System.map?ra
Compile SPI Controller driver

Code: Select all

cd
mkdir -p src/latency
cd src/latency

wget https://raw.github.com/msperl/linux/rpi-3.6.y/drivers/spi/spi-bcm2708.c
nano Makefile

Code: Select all

obj-m += spi-bcm2708.o

all:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
Since we are not rebuilding the kernel we have to patch the driver with some info that should be in bcm2708.c:
diff spi-bcm2708.c

Code: Select all

@bcm2708_spi_probe
	struct bcm2708_spi *bs;
	const char* mode;
	
+	#define DMA_MASK_BITS_COMMON 32
+	pdev->dev.coherent_dma_mask = DMA_BIT_MASK(DMA_MASK_BITS_COMMON);
+
 	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);

Code: Select all

make

insmod spi-bcm2708.ko
dmesg
bcm2708_spi bcm2708_spi.0: DMA channel 0 at address 0xf2007000 with irq 16
bcm2708_spi bcm2708_spi.0: DMA channel 4 at address 0xf2007400 with irq 20
spi_master spi0: will run message pump with realtime priority
bcm2708_spi bcm2708_spi.0: SPI Controller at 0x20204000 (irq 80)
bcm2708_spi bcm2708_spi.0: SPI Controller running in interrupt-driven mode
This would all have been so simple if someone provided a kernel headers package: apt-get install linux-headers-$(uname -r)
Sadly I have never taken the time to learn how to make an APT package :|

notro
Posts: 682
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: SPI driver latency and a possible solution

Wed May 15, 2013 1:32 pm

pasifus wrote:after module build and run:

pi@raspberrypi ~/src/latency $ sudo insmod spi-bcm2708.ko
Error: could not insert module spi-bcm2708.ko: Invalid module format
pi@raspberrypi ~/src/latency $ tail /var/log/kern.log
May 15 10:12:23 raspberrypi kernel: [ 3218.043562] spi_bcm2708: no symbol version for module_layout
I'm no expert on kernel building, but I guess this means that Module.symvers or possibly .config doesn't match the running kernel.

If you did this with the 2013-02-09-wheezy-raspbian image, with the default kernel and followed the steps in order, I don't know why it fails. One thing I have experienced: Module.symvers has to be copied after make modules_prepare.

jwasch
Posts: 12
Joined: Wed May 01, 2013 3:10 pm

Re: SPI driver latency and a possible solution

Thu May 16, 2013 3:46 pm

Tried sending a single ioctl() with multiple spi_ioc_transfer structs in array. Each attempts to transfer multiple bytes. Initial ones have change_cs=0, and last one has change_cs=1. Works as expected except that I expected to be able to have each item have a byte length of up to 4096 bytes, and instead, fails when SUM of individual transfers exceeds 4096. spii_test.c message is "can't send spi message: Message too long". Anybody find a way around this? Goal is to transfer as much as possible in single ioctl() call. Thanks.

User avatar
gordon@drogon.net
Posts: 1961
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: SPI driver latency and a possible solution

Thu May 16, 2013 3:51 pm

jwasch wrote:Tried sending a single ioctl() with multiple spi_ioc_transfer structs in array. Each attempts to transfer multiple bytes. Initial ones have change_cs=0, and last one has change_cs=1. Works as expected except that I expected to be able to have each item have a byte length of up to 4096 bytes, and instead, fails when SUM of individual transfers exceeds 4096. spii_test.c message is "can't send spi message: Message too long". Anybody find a way around this? Goal is to transfer as much as possible in single ioctl() call. Thanks.
unload the kernel module, and reload with a buffer buffer size.

If you have wiringPi installed, then

sudo rmmod ... (er, can't remember the names off-hand, but remove both for good measure)

gpio load spi 64

will load it with a 64KB buffer.

-Gordon
--
Gordons projects: https://projects.drogon.net/

Return to “Interfacing (DSI, CSI, I2C, etc.)”

Who is online

Users browsing this forum: No registered users and 7 guests