High Throughput SPI traffic part 1b - SPI without Buffers

Jan Cumps

17 May 2016

We know SPI as a 4*-wire protocol. But it doesn't have to be.

I'm checking high speed SPI data transfer with buffers, DMA and parallel data lines.

Let's analyse what the SPI cost is of my naive implementation, where I paint pixel by pixel.

SPI Traffic for a Single Pixel

Painting a single pixel on the LCD requires 8 SPI calls. In total we move 15 bytes.

The majority is spent on setting a draw window of 1 x 1 pixel. The paint command by itself just takes 2 bytes.

Code snippet

    _writeCommand(HX8353E_CASET);
    _writeData16(x0);
    _writeData16(x1);
    _writeCommand(HX8353E_RASET);
    _writeData16(y0);
    _writeData16(y1);
    _writeCommand(HX8353E_RAMWR);
    _writeData16(colour);

action	bytes	total
start point command	1 byte	1
coordinate x	2 bytes	3
coordinate y	2 bytes	5
end point command	1 byte	6
coordinate x	2 bytes	8
coordinate y	2 bytes	10
write data command	1 byte	11
write the pixel colour	2 bytes	13

The analyser trace looks like this:

And the protocol analyser tells us:

Almost 20 µS for a pixel. My SPI clock runs at 27.5 Mbits per second.

13 bytes per pixel is 1664 bytes for one line of 128 pixels.

2.6 ms per line (20µs x 128). 328 ms for the whole 128 x 128 bitmap.

A Slightly Less Naive Approach

Let's try a first speed bump by setting the window to one line in stead of one pixel, and then push the data after that.

Unbuffered still. We are looping through the line and send a pixel at a time over SPI.

But we only send the positioning and windowing bytes (11 of the 13) only once per line.

A saving of 1397 bytes per single line.

Code snippet:

void setBitmapInOneThrow(bitmap_t *bmp) {
  uint32_t xx, yy;


    for (yy = 0; yy < bmp->height; yy++) {
        _setWindow(0, yy, bmp->width, yy );
      loadBitmapInDMABuffer(bmp, yy);
        for (xx = 0; xx < bmp->width; xx++) {
        _writeData16(TXDATA[xx]);
        }
    }
}

We still spend the same time for these activities as in the previous implementation.

16 µS to get the LCD screen initialises. For a whole line now.

Beaming the full line of data, 128 x 2 bytes, took us 360 µS

The total time to draw a line decreased from 2.6 ms per line to 376 µS.

In the next blog, we'll try to bring the 360 µS pixel data transmit further down by using buffered SPI.

The Series
0 - Buffers and Parallel Data Lines
1a - Buffers and DMA
1b - SPI without Buffers
2 - SPI with Buffers
3a - SPI with DMA
3b - SPI with DMA works
4a - SPI Master with DMA and Parallel Data Lines
Hercules microcontrollers, DMA and Memory Cache

Top Comments

Parents

DAB over 9 years ago

Nice blog.

I like how you showed how to use some simple techniques to save time during the write cycle.

Back in the early days, 1970's, we were always coming up with time saving techniques due to the very slow cycle time, >1 microsecond per instruction, for the computers we had then.

Doing complex graphis, just 100 by 100 bits took a lot of time to read from disk and send to the output buffers.

We seldom ran at full resolution, 400 by 400, due to the time it took to display the image.

So your experience with SPI brings back a lot of memories for me as we waited for the technology to improve.

DAB
- Cancel
- Vote Up +3 Vote Down
- Sign in to reply
- More
- Cancel
Jan Cumps over 9 years ago in reply to DAB

Here's the test set-up:

A Hercules RM46 LaunchPad. The RM46 is part of TI's Hercules family. This one is specialised in industrial and medical applications.
Loads of safety features on that controller, including 2 ARM Cortex cores in lockstep. Each processor instruction is executed on both cores, and then output is compared.
All peripherals have redundant functionality - also for safe operation under harsh conditions. Memory consistency is checked at each instruction.

A Educational BoosterPack MKII, with 128 128 full colour display.
For this exercise, I'm moving loads of data via SPI to that display.
The BoosterPack has been idle in my lab for months. It didn't work on the Hercules LaunchPad by default.
It was only when I could lay my hands on a TM4C LaunchPad - where the display works - that I was able to understand its functionality, leading to my port of the display driver to Hercules.
I have to admit that starting without a working implementation, just with the datasheets, is not my forte. I respect everyone who can.

The Papilio Pro FPGA board that serves as my logic analyser and protocol decoder. In essence, this is just an FPGA running on its own, doing both the sampling and the communication with the GUI on my computer.
The only other logic on the Papilio is some flash t store the configuration (although not essential for this application; I could load the config to the FPGA at runtime if I wanted) and a USB chip (affraid to name it, because shabaz would chime in).

A few humble parts. LaunchPad + BoosterPack less than $50 together. The Papilio around the same amount if I remember well.
Endless joy and learning power.
- Cancel
- Vote Up +4 Vote Down
- Sign in to reply
- More
- Cancel
shabaz over 9 years ago in reply to Jan Cumps

Nice post!! Also that analyzer has got me out of a few holes over the years : ) A nice design that "just works"..
LOL @ ft*i. Thinking of creating a through-hole PCB (open source of course) design for MCP2221, I've been using the
stripboard prototype version for months now, reliable part from Microchip. Since it has a built-in ADC, that could be a value-add,
e.g. use it for testing what the applied voltage is, since not all hobbyists initially have a multimeter.
Open to ideas/suggestions though on any features you'd like to see in such a through-hole project, form factor, etc.
Another option is to turn the spare GPIO pins into an MSP430 programmer. Kind of like a beginners swiss army knife.
Just need to keep the parts count low.
- Cancel
- Vote Up +2 Vote Down
- Sign in to reply
- More
- Cancel

Comment

shabaz over 9 years ago in reply to Jan Cumps

Nice post!! Also that analyzer has got me out of a few holes over the years : ) A nice design that "just works"..
LOL @ ft*i. Thinking of creating a through-hole PCB (open source of course) design for MCP2221, I've been using the
stripboard prototype version for months now, reliable part from Microchip. Since it has a built-in ADC, that could be a value-add,
e.g. use it for testing what the applied voltage is, since not all hobbyists initially have a multimeter.
Open to ideas/suggestions though on any features you'd like to see in such a through-hole project, form factor, etc.
Another option is to turn the spare GPIO pins into an MSP430 programmer. Kind of like a beginners swiss army knife.
Just need to keep the parts count low.
- Cancel
- Vote Up +2 Vote Down
- Sign in to reply
- More
- Cancel

Children

No Data