SSP Bitstream

19 Oct 2010

Hi,

I'm trying to generate a very high speed constant bitstream on a MOSI pin of one of the SSP interfaces and I noticed that after each byte (or word) there is a small delay of about one SCLK tick. Is this normal or am I doing something wrong? This even happens when I use GPDMA to move the data to the peripheral.

Thanks,

--Ivo

19 Oct 2010

Hi Ivo,

I have a module that reads a flash device at high speed via SSP using DMA bulk transfers. Works for me. But when checking it with a logic analysiser I did also see the one clock "wait" between bytes. But didn't affect the actual transfer as I expected. I think it's a function of the SSP/SPI that there's always going to be a delay of some sort between frames. I've done a lot of work with SPI on many devices and it always seems the same.

regards,

--Andy

20 Oct 2010

Hi Andy,

 

Thanks for your reply! I have looked at the SPI/SSP documentation again and I think the extra time taken is for the SSEL line to go high and low again. It's a pity I can't get a continuous bitstream at 25MHz, but I'll look into other methods. Maybe a GPIO pin with DMA, though I seem to remember reading somewhere that was limitted to 16Mbit/s.

 

--Ivo

20 Oct 2010

Take a look at http://mbed.org/forum/mbed/post/5547/ which shows a simple sample of "banging a port bit" using DMA. This maybe where you read about "16MHz". That may have been 20MHz however, I'm at the limits of my LA.

21 Oct 2010 . Edited: 21 Oct 2010

Hi Ivo, All,

I'd also take a look at the I2S peripheral on the LPC1768 (not I2C), which is designed for connecting to high quality DACs. Fundamentally, it is a high bandwidth bitstream with no framing, and the hardware has a big send FIFO, so IMO it could be a bit-bangers peripheral of choice!

As an example of something someone has done on one of our early mbed prototypes using I2S (another simon), have a look at this :)

We don't have a published driver for it, but if you are willing to decipher the datasheet and code it yourself I think you could get great results out of the I2S peripheral for your application.

Simon

22 Oct 2010 . Edited: 22 Oct 2010

Thanks for pointing out the I2S peripheral. Looks like that  is exactly what I am looking for. Seems like I am reinventing the wheel, sort of. Currently I have 512x480 pixels running with DMA to the SSP interface, which is 64 characters wide, with annoying vertical lines between each column.

25 Jan 2011

This reply is a little late, but you can get a continuous bit stream by using TI mode on the SSP controller. The simplest way on mbed is to declare it and set it up as if it were SPI, but jam it into TI mode before you transmit.

SPI         device     (p11, p12, p13);
  .
  .
  .

    // Configure TX data port
    device.format(8, 0);            // SPI 8 bit mode 0
    device.frequency(2000000);      // SPI bit rate
    LPC_SSP0->CR0 |= 0x0010;        // Switch to TI mode
  .
  .
  .
        while (i < len) {
            while ((LPC_SSP0->SR & 0x0002) == 0x0002) {
                LPC_SSP0->DR = xmt_msg[i];
                i++;
            }
        }
        while ((LPC_SSP0->SR & 0x0001) == 0x0000);
        for (i=0; i<20; i++);       // Allow extra time to clock out the last few bits

Regards,

- Gary

15 Mar 2012

Hi Gary, 

Thanks for your work, which unveils some clues in my application.

In my application, raw data acquiring from DAQ system (24 bits * 64 channels (at least) each block with 2k sample rate) is going to transmit into mbed through SPI interface and pass through USB interface to an Android-powered device through Android Accessory Protocol. 

Since the data is not in a SD card but from a FPGA, SSP interface (SPI in TI mode) seems to have higher performance for continuous bits stream. My question is that: 1. How much data rate in your test? And what is the peripheral of mbed in your test. 2. Do you use GPDMA in your test in order to get a high speed? (In LPC1768, there are eight GPDMA channels, and it's possible to configure one channel worked in peripheral to memory mode. More detail information about that is available in Table 564 (Page 605 of 840).)

(P.S. In my app, Mbed is going to act as a master and DAQ system end with FPGA is going to be a slave.)

3. Do you have any suggestion of the following condition? 

When I tested the AndordAccessory example from cookbook, I found that this program does not implement real USB host but make a trick with a method that using serial-USB port and all data transceiver under serial protocol instead of USB protocol for simplicity.

I suppose that USB host protocol is still under developing in mbed, and no reliable and stable library is available for directly using by now. Furthermore, UART3, one of the LPC1768 UARTS, is connected to USB port in mbed board and a library for mapping serial data between USB data is available in mbed library. Then a trick is made for simplicity.

In this way, if building a stable library in mbed part, there is the possibility that reach a higher speed rate like 777.216 Kbytes per second (24 bits * 128 channels * 2024 sample rate) or just a few modification in USBSerial also could achieve this goal.

In a word, if I want to implement a data link from SSP bus to USB with at lease 777.216 Kbytes per second, what should I do in your opinion? 

Gary Johnson wrote:

This reply is a little late, but you can get a continuous bit stream by using TI mode on the SSP controller. The simplest way on mbed is to declare it and set it up as if it were SPI, but jam it into TI mode before you transmit.

SPI         device     (p11, p12, p13);
  .
  .
  .

    // Configure TX data port
    device.format(8, 0);            // SPI 8 bit mode 0
    device.frequency(2000000);      // SPI bit rate
    LPC_SSP0->CR0 |= 0x0010;        // Switch to TI mode
  .
  .
  .
        while (i < len) {
            while ((LPC_SSP0->SR & 0x0002) == 0x0002) {
                LPC_SSP0->DR = xmt_msg[i];
                i++;
            }
        }
        while ((LPC_SSP0->SR & 0x0001) == 0x0000);
        for (i=0; i<20; i++);       // Allow extra time to clock out the last few bits

Regards,

- Gary