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

[CuriousOne]

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?

[tumbleweed]

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

[Jerson]

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

[HenrikOlsson]

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.

[richard]

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

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