4 Replies Latest reply on Nov 5, 2014 8:55 AM by KurtE

    Spi transfer buffer possible bug.


      When using the spi.transferBuffer I find that the CS line is not de asserted/asserted after each frame or 8bits of data, so the spi slave only sees 8bits of data instead of all the buffer.


      If I use a for loop and spi.transfer only then it works, however using this method is very slow as there is a sizable delay between each transfer, making it in effect a 19khz cycle of data instead on 2mhz that the spi clk is set too.


      If I want to fix this, where should I look? I had a look at spidev.c in the linux firmware (intending to build my own custom yocto image) but this is just the module.



        • 1. Re: Spi transfer buffer possible bug.

          I do not think this is a bug.

          There are many spi devices that need frames that are longer then 8bit.

          • 2. Re: Spi transfer buffer possible bug.

            I understand that, and that would be the frame size setting that can be set, where mine is set to default or 8bit, but looking at various specs that I googled, each frame seem to need the cs asserted to give a frame boundary.


            If this is not the case, then fine, I would like to modify the Kernel to achieve this result without having the large cs gaps, but haven't yet found the relevent kernel code to achieve this.

            • 3. Re: Spi transfer buffer possible bug.

              I think the file you are looking for is : /drivers/spi/intel_mid_ssp_spi.c (available in yocto as a patch to kernel 3.10). But without chip documentation (at least to know if hardware support the behaviour you want) it will be difficult to modify it.


              But as said Erik_van_der_Zalm it's not a bug. It's how SPI driver is operating. The large cs gap you see is result of context switch between calls, in order to reduce this gap you need to write a SPI driver for your device and not use spidev as i'm not sure it uses DMA. But with a 8bits register on your slave device you do not have any choice but use 8 bits transfers, if you use 32bits transfer it's normal for the CS line to stay low.

              • 4. Re: Spi transfer buffer possible bug.

                I am not sure how much it will help, but I am also trying to understand what the SPI driver is doing.   I have been browsing through the code and talking a little about it in the thread: Sources for /dev/spidev5.1 and what it calls