Close

SPI, logically

A project log for Cruise Control Preset

This project supplements the existing cruise control in a vehicle, allowing you to automatically set the cruise control to a selected speed.

scott-hammerschmidtScott Hammerschmidt 08/05/2015 at 18:580 Comments

I looked at the transfers to the SPI OLED display today. It took me a little while to get my fx2lafw logic analzyer to work properly for this. On Windows, using a nightly build of Pulseview from sometime in May, I couldn't capture faster than about 3 MHz. I tried the same logic analyzer on the same laptop under Ubuntu, and things ran fine. Downloading the latest nightly build of Pulseview for Windows, it fixed the problem of capture rates, but introduced a new problem where it doesn't show me any more than about 10 ms of data (20 M samples at 16 MHz should be over 1 s worth). So I captured the trace in Ubuntu and saved it to a file, and then loaded into Pulseview in Windows. I could have just stayed in Ubuntu to analyze it, but I'm more familiar with the photo tools I use for the screen captures in Windows.

Here's the overall transfer. In this image you can see two complete transfers, each transfer consisting of 4 pages sent to the display. The time for the update is 39.51 ms, which compares favorably to the 43.8 ms I got using the timer.

The time between page transfers is about 12.45 ms. This is the draw time. This compares with 9.48 ms using the IIC display. So it seems that the SPI display must take a little longer to ready the transfer, since we're drawing the same thing?

The actual transfer time is shown below. Subtracting the two times, we get 1.15 ms. This compares to 3.57 ms per 2x size page transfer using IIC.

Here you can see what a page transfer looks like. Note that it's split into two parts. You can see the DC line go low for the first 3 bytes in each half.

Here's what the command transfer bytes look like. There are 8 sets of these per update, 2 per page. the 0x10 and 0x00 stay the same, the 0xB0 increments to 0xB1, 0xB2, etc. I'm guessing this is a page or offset counter for the display?

Here's the clock, you can see it's running at 4MHz. It's interesting that even though the clock is now 10x faster than IIC, it is only about 3x faster for a page transfer. The time between bytes for SPI is a larger percentage than that for IIC. This makes sense, since the time the processor takes to load the next byte for transfer is probably about the same, but since the SPI clock is faster a larger percentage of the time is now taken for loading the next byte.

Here's the time is takes to transfer one byte. This 2 us is indeed 10x faster than the 20 us it takes for a byte transfer using the 400 kHz IIC.

Time to load the next byte for transfer is 1.88 us. I didn't measure how long this took with the IIC display, looking at the photos it appears to be 4 to 5 us. I had kind of expected this to be the same, but there might be a larger delay when starting the IIC hardware?

Here's the transfer of one part of a page transfer. The time is 494.28 us. From the above, a byte load and transfer takes about 3.88 us. Dividing by that, it works out to around 128, which is reasonable since the 2x page size is 256, so half that is 128.

So, here's the final results. Using the IIC OLED display with the 2x page size, an update takes 86.8 ms. Using the SPI display and a 2x page size, it's 43.8. So about half the time using the SPI display. I'm planning on using the SPI displays. Since I would potentially like to use two displays (one for the cruise control stuff, the other for time and perhaps OBDII information), the lack of the CS line makes it a little more difficult. I may just order another set of displays for this project that have a CS line brought out to a pin.

I think I've done most everything I can to analyze the times taken for a display update. Now I'll start on parsing the binary data from the GPS 18x.

Discussions