Hardware SPI performance

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I've been making progress with my little game device project, recently redesigning it to use an ATmega1284p and a colour OLED display.

I made a few errors with my pin assignments and am writing the display data by bit-banging.

Another error in my design meant the MCU is running at 8MHz. (Didn't realise it can't run >8MHz without a crystal)

This is giving me a frame rate of about 2fps

My old ATTiny85-based project, running at 16MHz PLL using a monochrome OLED could manage >100fps.

The MONO OLED is 128x64 pixels, each byte sent sets 8 pixels at a time.

The COLOUR OLED is 128x128, 2 bytes required for EACH pixel, so obviously a LOT more data needs to be sent.

I've never really used hardware SPI since most of my work has been with the tiny85 which doesn't really have it?

If I were to rework my board to use the hardware SPI pins, can I expect much of an improvement in speed?

My limited understanding of how it works is that I can feed it whole bytes at a time and do other stuff in between?

How much of an improvement am I likely to see? I'm struggling to believe I'm going to get the nearly 50+ times that I need to match the MONO version, even 15 times seems unlikely to get a usable 30fps.

I need to revise the board anyway, so I'm trying to decide if I should just go back to a monochrome display :)

Thanks
-Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use USART_MSPI. You can get gapless SPI e.g. 8MHz with F_CPU @ 16MHz.
128x128x2 in 32.77ms or 30FPS if you are really lucky.
.
In practice you should use a better algorithm or faster MCU. e.g. only draw minimal rectangles or pixels that change.
Yes, you can make dramatic animations with a monochrome OLED. Colour requires intelligence.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At the highest SPI clock speed, don't expect to do much during transfers. At the very least, you will have to load a new byte every 8 clocks. Lets say that your SPI clock is 1/4 the MCU clock. That gives you 32 MCU clocks to do something and that something is likely going to be getting the next byte ready. 

 

Now, if you use a XMega with DMA, that scenario changes. But, without DMA, that is about as good as you can do.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Colour requires intelligence.

Perfect. Thank you. Monochrome it is!

Seriously though I want to make this thing as simple as possible and I don't think I want to have to worry about tracking what's changed and what hasn't. I want to just blast out a pixel buffer as fast as I can.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The color OLED requires 128*128*16==2**18> 0.25E6 bits/frame.

16fps 32fps requires 4e6 8e6 bits/sec, which requires F_CPU> 16e6/sec .

Going to monochrome saves a factor of four: fewer pixels and fewer bits/pixel.

32fps 64fps requires F_CPU> 8e6 .

 

Neither of these calculations involves computing the bits to be transferred.

 

Edit: factor of two

Iluvatar is the better part of Valar.

Last Edited: Mon. Nov 12, 2018 - 10:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:

16fps requires 4e6 bits/sec, which requires F_CPU> 16e6/sec .

 

SPI can go up to half the CPU clock.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Half the CPU clock as a master. Quarter the CPU clock, max, if slave. Driving a display should require the MCU to be a master.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Nov 12, 2018 - 10:56 PM