Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] SPI Speed and power usage

Status
Not open for further replies.

pyrohaz

Member level 1
Joined
Jun 4, 2013
Messages
32
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Activity points
1,523
Hi,

I'm building a relatively low power circuit using a PCD8544 based LCD (the kinds that are extremely cheap off ebay!). They accept data through SPI at up to 4MHz but what I'm wondering is what would be the best SPI speed to use? I'm sending data over in a "framebuffer" manner (504bytes/transfer) and only need an update rate of minimum 10fps meaning a whopping transfer speed of ~5kb/s. Obviously, most standard SPI rates will fulfil this requirement. All I'm wondering is will I get any notable battery life increases using a slow speed as opposed to a fast speed? With a fast speed, I can blitz the transfer then disable the spi peripheral though the cost of a high clock speed might affect power consumption where as with a slow speed, the slower clock obviously requires less power.

Any recommendations?

Thanks,
Harris
 

This is more of a function of the clock speed used for the processor. If you clock your processor at 4MHz you will use more power than if you clocked it at 1MHz. So if you lower your processor speed down enough to still drive SPI at 6kHz then you will be okay. SPI clock only runs when the you are transmitting so it is only consuming power while active. However the main processor is still consuming power regardless of SPI. So you will save the most power by optimizing the system clock. Also using sleep states can save even more power.

One thing that you have to consider is if there is any processor sensitive or long/critical pieces of code that need to be executed often or between each frame. Depending on this you may have to use a faster clock speed and transmit over SPI at a higher speed as you are limited in terms of optimizing your system clock speed for low power.

More than likely the LCD and its controller will be the limiting factor in terms of limiting power consumption for your application.

You could also only transmit the data that changed in the frame buffer, so that you spend less time/power transmitting redundant frame data.

I hope this helps.
 

This is more of a function of the clock speed used for the processor. If you clock your processor at 4MHz you will use more power than if you clocked it at 1MHz. So if you lower your processor speed down enough to still drive SPI at 6kHz then you will be okay. SPI clock only runs when the you are transmitting so it is only consuming power while active. However the main processor is still consuming power regardless of SPI. So you will save the most power by optimizing the system clock. Also using sleep states can save even more power.

One thing that you have to consider is if there is any processor sensitive or long/critical pieces of code that need to be executed often or between each frame. Depending on this you may have to use a faster clock speed and transmit over SPI at a higher speed as you are limited in terms of optimizing your system clock speed for low power.

More than likely the LCD and its controller will be the limiting factor in terms of limiting power consumption for your application.

You could also only transmit the data that changed in the frame buffer, so that you spend less time/power transmitting redundant frame data.

I hope this helps.

Thats really useful actually, thanks a lot! Apart from having some form of "events list", is there any fast way I can detect a change in the framebuffer? Obviously, I could have a second frame buffer and compare between the two but that means sifting through a 504byte pair of arrays and comparing them which isn't particularly light on processing power!
 

You could divide the frame into pages. So you have an array of pages for the each frame in the frame buffer. If you make a change to one of the pages you set a flag stating that the whole page has to be updated or transmitted to the display controller. How big you make the page size will determine how much memory you use versus how efficient the update is. (Efficiency being sending only what you need to update and nothing more.)

So if I have a string "My dog ran away today" and I used a frame size of 3 I would have:
"My ", "dog", " ra", "n a", "way", " to", "day", " ", ....

Now if I update the string to be "My cat ran away today", then I would have:
"My ", "can", " ra", "n a", "way", " to", "day", " ", ....
So only one page were affected and therefore I only need to send 3 bytes instead of 21. This example is 100 percent efficient for this page size.

Now if I update the string to be "My dogs ran away today", then I would have:
"My ", "dog", "s r", "an ", "awa", "y t", "oda", "y ", " ", ....
So six pages were affected and therefore I needed to send 18 bytes instead of 24. This example is 29.2 percent efficient for the page size.

Efficiency = ((<bytes changed> + (<total number of bytes> - <bytes sent>)) / <total number of bytes>) * 100

How big you make the page size is going to take some trial and error.

- - - Updated - - -

So when you make a change to the frame inside a page you set the update flag for that page. When you go to transmit that page you will know that address of the page and the size of the page, from this you can generate the address on the display you need to write to. (Note sending the address over and over will make very small pages inefficient if the changes are big, which would cause many pages to need updating.)
 

Ah yes, I see! As the character size is 8x5, I'm thinking of dividing the screen into 6 pages so that any time a character is changed, I only have to update 1 row of text (if that makes sense), that seems much more efficient compared to writing the whole frame buffer every time a small change is made.

Thanks a lot!
 

In the end, I've decided to split each character up into a "mini" buffer so I write the character to a 8x5 memory buffer, then print this to the screen, the power seems to have dropped (on average) by a couple of uA so not drastic though every saving is worth it, thanks for your help :)
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top