I am working on my project using a SSD-1306 128 * 64 display connected in I2C (see picture below).
It is working, but for me, display refresh is too slow. I2C speed is limited here with the hardware to 200kbs.
My question, as it was my first project using a display like that, do we have GCBASIC supported displays with (much) better refresh rate and display speed ? I am not fixing on I2C, can be also SPI.
Is basically SPI given better results ? Do you have good advice for another kind of display?
For text: Now writes each of the 5 font columns as a single buffer byte + one Write_Data_SSD1306, then one blank inter-character column = far fewer SPI/I2C transactions.
And, stay away from used Filled functions. They are inherently slow.
I have not yet tried SPI in my project, have also no SPI screen available.
Need first to procure some, and I am looking for good references.
I assume, I need also to select new PIC for my project, the PIC18F16Q41 have not enough ports and not enough program memory, and so, need also to redesign a PCB :)
For the long Winter time :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SPI can be way faster than i2c.
I have an ongoing project where video is sent to a little 1" SSD1331 (96x64 pixels resolution, 16bit colours = 12288 bytes per frame ) at more than 170 Frames Per Second (with some assembler, with and without DMA). It is in early development stages.
The early version (before doing assembler tricks) is here: https://sourceforge.net/p/gcbasic/discussion/projects%26guides/thread/4fd89c1c99/
It sends a photo repeatedly to the sceen updating all pixels in SSD1331 sequential mode (just data,data,data,data until the frame is finished) at 15 FPS (fetching the data from a data block or table). The demo runs at "Masterfast" SPI speed and can be increased slightly for this screen.
Here is an example where I sent video via serial to this very early version: https://lineaudio.se/div/GLCDfireworks.mp4 (the flickery is not visible looking at the screen)
Uploading the picture to an array and fetching from there is faster. Just sending the pixel data for alla screen pixels is/was about 30FPS or more (about 400,000 bytes per second) with this early version and without assembler or DMA tricks.
-Just to get an idea how much faster SPI can be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
:-) If my business work load permitts (not looking bright at this moment).
I am not an artist and I am not able to create the graphics, but it would have been very cool with a christmas movie in "La linea" style. As it is monochrome, I think a short episode could be conained in a Data block. https://en.wikipedia.org/wiki/La_Linea_(TV_series)
Good idea?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And, have a look in the Help. Look for any 8-bit bus device. These will be faster. There are many 8-bit bus devices.
I have just written a one off driver for a 8-bit bus OLED for a SH1101a.
The OLED is updated directly, with no frame buffer. The program writes straight into the display controller's own memory, and only when something needs to change.
The hardware path, OLED_Write: the SH1101A is on an 8080-style parallel bus that the program drives by setting pins directly. So, this is the fastest method.
Put the data bytes on PORTD.
What gets redrawn:
OLED_Clear writes zeros to all 8 pages × 132 columns. It only runs when the whole screen changes: start-up, openin the menu, or switching screens.
DrawScreen draws the fixed labels once. The update routines about every 50 ms.
The screen updates look instant and nothing is redrawn, it's simply overwritten in place.
Speed: one byte is roughly 25–30 instructiono a character (3 positioning commands plus 6bytes) takes about 25 µs. A full scale row of 126 bytes takes about 0.3 ms, and a full clear about 3 ms.
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear GCBASIC Community,
I am working on my project using a SSD-1306 128 * 64 display connected in I2C (see picture below).
It is working, but for me, display refresh is too slow. I2C speed is limited here with the hardware to 200kbs.
My question, as it was my first project using a display like that, do we have GCBASIC supported displays with (much) better refresh rate and display speed ? I am not fixing on I2C, can be also SPI.
Is basically SPI given better results ? Do you have good advice for another kind of display?
Thank a lot
Try attached. This is an optmised library.
For text: Now writes each of the 5 font columns as a single buffer byte + one Write_Data_SSD1306, then one blank inter-character column = far fewer SPI/I2C transactions.
And, stay away from used Filled functions. They are inherently slow.
Last edit: Anobium 4 days ago
Use a DWIN display. All the hardware is completed in the DWIN and there are very cheap.
Do you have some good references, because what I saw so far, these screens are not so cheap. Thank
I was getting via Aliexpress direct from DWIN for 14GBP for my customer project earlier this year.
The performance and functionality is amazing.
But, have you used DMA for GLCD? But, this is chip dependent. Using DMA gives huge performance increase for SPI.
I have not yet tried SPI in my project, have also no SPI screen available.
Need first to procure some, and I am looking for good references.
I assume, I need also to select new PIC for my project, the PIC18F16Q41 have not enough ports and not enough program memory, and so, need also to redesign a PCB :)
For the long Winter time :)
There is a really good thread ( on the forum ) about using DMA and SPI. Amazing results.
SPI can be way faster than i2c.
I have an ongoing project where video is sent to a little 1" SSD1331 (96x64 pixels resolution, 16bit colours = 12288 bytes per frame ) at more than 170 Frames Per Second (with some assembler, with and without DMA). It is in early development stages.
The early version (before doing assembler tricks) is here: https://sourceforge.net/p/gcbasic/discussion/projects%26guides/thread/4fd89c1c99/
It sends a photo repeatedly to the sceen updating all pixels in SSD1331 sequential mode (just data,data,data,data until the frame is finished) at 15 FPS (fetching the data from a data block or table). The demo runs at "Masterfast" SPI speed and can be increased slightly for this screen.
Here is an example where I sent video via serial to this very early version: https://lineaudio.se/div/GLCDfireworks.mp4 (the flickery is not visible looking at the screen)
Uploading the picture to an array and fetching from there is faster. Just sending the pixel data for alla screen pixels is/was about 30FPS or more (about 400,000 bytes per second) with this early version and without assembler or DMA tricks.
-Just to get an idea how much faster SPI can be.
And, is a video in the making for Christmas?
:-) If my business work load permitts (not looking bright at this moment).
I am not an artist and I am not able to create the graphics, but it would have been very cool with a christmas movie in "La linea" style. As it is monochrome, I think a short episode could be conained in a Data block. https://en.wikipedia.org/wiki/La_Linea_(TV_series)
Good idea?
Thank a lot for your feedbacks, I will check.
And, have a look in the Help. Look for any 8-bit bus device. These will be faster. There are many 8-bit bus devices.
I have just written a one off driver for a 8-bit bus OLED for a SH1101a.
The OLED is updated directly, with no frame buffer. The program writes straight into the display controller's own memory, and only when something needs to change.
The hardware path, OLED_Write: the SH1101A is on an 8080-style parallel bus that the program drives by setting pins directly. So, this is the fastest method.
What gets redrawn:
The screen updates look instant and nothing is redrawn, it's simply overwritten in place.
Speed: one byte is roughly 25–30 instructiono a character (3 positioning commands plus 6bytes) takes about 25 µs. A full scale row of 126 bytes takes about 0.3 ms, and a full clear about 3 ms.