My design calls for running a 160x128 display with 16-bits per pixel at 60 Hz.
This means I need
160x128 @ 16-bpp @ 60 Hz --> 20,480 pixels * 16 * 60 --> 327,680 bits * 60 Hz --> 19,660,800 bits/sec.
With overhead, a 22-25 MHz SPI bus can take care of that. Problem, the SEPS525 is limited to a SPI clock rate no faster than 60 ns, or ~16.667 MHz. But I cannot get my SPI bus to operate at this speed on a pic32. I can get clock with running the perpheral bus at a 1:4 divider and the sysclock at 60 Mhz, which yeilds 15 MHz. That's pretty close, but how many fps will I get for a display that large?
15,000,000 / 327,680 bits --> 45.78 fps*
Okay, that is a bit slower than I wanted. It's respectable, but I'm trying to acheive fluid motion of moving elements on my screen and that means I need to be between 50 and 60 fps, the higher of which I'm aiming for. This means that I cannot draw the whole screen all at once, at least every time. What happens if I just draw half? I know the SEPS525's memory is persistent when in window addressign mode, so I can just update portions of it, right? Let's draw just the left half or the right half, what do I win?
15,000,000 / 16,3840 bits --> 91.55 fps*
Wow. That's a bump... If I divide that into quarters, then I effectively double that number again, 183.11 fps*. Not bad, but this is too easy...
I have not shown any images of the gauge face, but it's also nothing out of the ordinary and very similar to a 270˚ sweep, but modified to fill the display as completely as possible. Knowing how it's drawn, I may not be able to get away with only drawing 1 quarter of the display since only one quaster of the display may have changes. If I happen to have *one pixel* in a quater change, I'd have to re-draw it entirety. I have several on screen elements though and they can all change an easily make it so all 4 quaters have to be updated. Well, this might be a waste.
But before disregarding the whole idea all together, let's get really small for a moment. I'll cut up the display in finer increments, say 8*8 and 16*16 grids? This would give me 320 and 80 sectors, respectively. If I take a moment and ignore the needle and extra text display, just focusing on the gauge's numbers and tick marks for the sake of this example, I'd have to update 51 of those 80 sectors, 63.75%, when using a 16x16 grid and 144 of 320, 45%, when using an 8x8 grid. Hmmm...
15,000,000 / (16^2 * 51 * 16 bpp) --> 15,000,000 / 208,896 --> 71.81 Hz*
15,000,000 / (8^2 * 144 * 16 bpp) --> 15,000,000 / 147,456 --> 101.73 Hz*
Huzzah!!!
Now, those numbers are theoretical and are completely ignorant of the setup time required to change addresses etc etc, of which will be easily cause measurable overhead. It is possible, and though requires a just little more computational overhead, to group contiguous block of memory. This means that for the 8x8 sectors those 144 updates are grouped into 28 updates, and the 51 16x16 sectors are grouped into 14 updates. That alone would speed things up to what, say 90% or more of the numbers I see there?
That means ~64 fps for 16x16 sectors and ~91 fps for 8x8 sectors!
Now things would also slow down with updates that fill more and more of the screen. But if I keep to an 8x8 grid, I have 40 sectors that never change from. That means I don't have to write out 12.5% of my frame buffer, ever, thus boosting my base frame rate from ~45 fps* to ~52 fps* and would only need 7 updates.
I've read that the PIC32 has an enhanced mode for its SPI buffers, making it so they are 128 bit FIFO buffers. If they behave as expected, this is enough for 8 pixels.