I started this project a few years back, something to do in my spare time, to re-create a digital gauge that was provided in a particular automotive community. It was designed to fit inside the MK IV Jetta instriment cluster and provide a 60 fps gauge face (frame rate high enough to not be perceptible and appear analog) on an OLED display (sunlight readable) for measuring the about of pressure provided by the turbocharger. It was also expanded to allow monitoring a thermocouple for EGT's (exhaust gas temperature) which is fairly important in a number of setups.
I had a chance to learn about the original design since a friend hand one and I was able to photograph it. As I recently overcame a software hurdle, I started looking at the display interface options, specifications, technical limitations, and interconnect options. Due to a recent data sheet indicating that I'd be limited to a 10 MHz serial/SPI interface on the display driver, I dove heavily into the PIC32's PMP, or Parallel Master Port, interface. It's windely more complex due to addressing and multiplexing or demultiplexing. However, the display driver data sheets I've found have left me a bit puzzled on the timing configurations of the parallel connections. After researching the topic in general, I wasn't the only one.
Well, it turns out that a long shot request of mine panned out. I was not sure that the display driver would maintain the contents of it's VRAM when switching it over to it's windowed addressing mode. I had since determined that the original gauge's designer/creater had bit banged a parallel interface on the same driver, SEPS525, that was one of my options. He happened to reply to my request to answer a few questions regarding his design, especially with my intent to clone his fundamental design. He confirmed that the contents of the RAM were persistent in the windowed addressing mode. This meant that even though the SPI interface could support my ideal 60 fps, I could draw the initial frame with significant speed, even if I daily chained 3 displays, then I can just issue updates to various parts of the screen instead of redrawing it's entire contents!
Now if I decided to stay with a PMP design, I'd need 10 or 11 wires per device. Since I was creating a modular design, I'd have to provide additional lines, making my grand total of 15 lines. For 3 displays, this is 45 traces. Fun routing, right? Thanks to the pinouts of the displays I was seeing, I was limited to two 8-bit transfers. It's not safe to transfer certain bits nex to each other because they can flip one another, which is called cross talk. This is why PATA didn't develop futher beyond UDMA 6 and UDMA 7 speeds.I could get around this in software, but this would add additiona overhead and can be cumbersome. Now, thanks to the eureaka moment previously mentioned, I decided to see what I could do with SPI.
I ran some numbers. If I had a 25 Mhz SPI bus, it would take 39 ms to update all 3 displays if they were daisy chained to one bus. Since I'm limited to a 15 MHz bus on the MCU, this grew to ~65.5 ms. If I'm looking at 3 gauges in a gauge cluster and I *had* to redraw all of my screens, I can do so inside of 75 ms which wouldn't be noticable. But wait, as I recall the PIC32 I was designing with actually had 3 SPI channels. A little googling around and I came across proof that I can run the channels virtually in parallel. This cut my refresh rate to ~21.8 ms, in other words a touch above 45 fps for each display. Not too shabby.
Now, this is below my 60 fps design goal, but if I simply alter my drawing to just update portions of the screen, then even with overhead, I don't have a problem at all. All things considering, I can drive 3, 160x128 displays at 16-bits per pixel, at 45 fps in a worse case scenario. If I do a simple horizontal division of the display and only redraw one half or the other, I'd bump this over to 90 fps assuming the overhead isn't a bottleneck. More gains are by had with more divisions, with diminishing returns though. So, overall I think I'll be sticking with hardware SPI on my PIC32 project 