160 byte framebuffer at 50 fps, internal RAM or external SRAM?

Hello.
I'm doing a graphic project, where content of WS0010b OLED display will be updated really fast, 50fps at least.
The framebuffer size is 160 bytes. Will PBPs arraywrite/arrayread operations provide enough speed at 18F running at 64mhz, to read and write that array at that speed, or better to use external, parallel SRAM for that?

Pretty much any external ram is going to be slower than internal storage.

I think the bottleneck will be the serial interface speed (SPI) which is normally used in small OLEDs. I could not find this display WS0010B on searching for it. Unless the PIC supports a SPI DMA engine, the bit banging will slow you down tremendously

160bytes @ 50Hz is only 64kbits/s (average). Even SHIFTOUT should be able to handle that.
Running the SPI or MSSP module at a moderate 1Mbit/s will transfer those 160bytes in less than 2ms leaving 18ms for processing between frames.

Not sure why you're even considering external RAM.
Even a double buffer should easily fit an 18F series part unless you're using a lot of RAM for other tasks of course.

Also not sure what part ARRAYREAD plays. Transfering the buffer would be done using a normal loop or, as Jerson mentions, DMA if you want to go the extra mile.

/Henrik.

Quote:

---

I'm doing a graphic project, where content of WS0010b OLED display will be updated really fast, 50fps at least.
The framebuffer size is 160 bytes.

---

why 160 bytes ? to employ the entire screen area you need 200 bytes in graphics mode

Quote:

---

Will PBPs arraywrite/arrayread operations provide enough speed at 18F running at 64mhz

---

i cannot see anyway that arrayread or arraywrite would be useful in transferring a frame buffer to the display

the displays are very fast, pbp has no trouble uploading a full 200 byte frame to the display in 1.37mS using 4bit parallel interface with the standard built-in lcd routines
plenty fast enough

Attachment 10049