High Throughput SPI traffic part 1b - SPI without Buffers

RE: High Throughput SPI traffic part 1b - SPI without Buffers

Jan Cumps — Thu, 19 May 2016 21:02:45 GMT

Issue resolved in less than an hour.

It was pebkac. Datasheet says that we can have 128 values in our buffer.

I was trying to send 128 at a time and that failed.

The reason for this:

[View:/resized-image/__size/1153x675/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-61886904-1c65-45fd-a975-bd1aebdabf9e/contentimage_5F00_189145.png:1153:675]

I'm using 3 transfer groups.

1 to send single 8-bit values (for LCD commands)

1 to send single 16-bit values (for single pixel drawing)

1 to send buffered 16-bit values (for multiple pixels at the same time)

I didn't get that the buffer is shared between the groups. So I can't use all 128 buffer positions in group2, because 2 of the 128 available buffer positions were already taken in group0 and group1.

I restructured my code to reduce the buffer size, and all works (FAST [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-61886904-1c65-45fd-a975-bd1aebdabf9e/1780.contentimage_5F00_1.png:16:16] ).

I'll prepare a blog tomorrow.

RE: High Throughput SPI traffic part 1b - SPI without Buffers

Jan Cumps — Thu, 19 May 2016 19:21:42 GMT

I was hoping that the next step would be easy: switching to buffered SPI.

I've used it before for small buffers.

I'm now trying to develop a design that buffers a full line of 128 16 bit values.

It doesn't work as expected (unless - as shown above - I hack registers at debug time) , so I'll have to spend some more time learning Hercules buffered SPI.

I'll first try to replicate a test bed I made a year ago that works with 64 16-bit values.

That's the consequence of working with the Hercules ARM family. Extremely powerful and safe; Equally extremely complex to work with. The good side of that is that when it works, you are a subject expert forever [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-61886904-1c65-45fd-a975-bd1aebdabf9e/contentimage_5F00_1.png:16:16] .

Hang on...

RE: High Throughput SPI traffic part 1b - SPI without Buffers

Jan Cumps — Tue, 17 May 2016 22:51:37 GMT

Sneak preview:

This isn't a full functioning implementation yet, but by tweaking some SPI registers in debug mode, I managed to push 128 16-bit values in one go:

[View:/resized-image/__size/881x145/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-61886904-1c65-45fd-a975-bd1aebdabf9e/contentimage_5F00_189144.png:881:145]

82 µs for a full line. Compared to non-buffered mode where it took 360 µs, we have between 4-5 times faster throughput.

This is a prediction of what the non-DMA buffered mode will give us at 27.5 Mbit/sec, wih a single data line.

My calculator says that 16 bits * 128 = 2048 bits.

It took me 82 µs to move them.

2048 / 0.000082 = 24975609.75609756.

The theoretical speed was 27.5 megabits.

I moved 24.975610 megabits

Efficiency: 90.82%

RE: High Throughput SPI traffic part 1b - SPI without Buffers

DAB — Tue, 17 May 2016 18:33:55 GMT

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