Hi, hope this post is fine in regard of rule 2.
Currently doing some fun stuff with an Arduino and have it hooked up to an 128x160px and communicate with it over SPI. If i color in all 20480 pixels it takes about 2 seconds to be done and i can watch the rows change one after another.
I was wondering if there are some tricks to speed this process up a bit or does it really just come down to minimizing the pixels to be changed?
The module im using is this one: https://www.waveshare.com/wiki/1.8inch_LCD_Module
Here is also my current code if anybody cares to take a look, even though i just rewrote the example code more or less so i would understand it. https://codeberg.org/bvoigtlaender/open-phone/src/branch/main
That display can run a maximum SPI clock speed of 15MHz. That’s enough to update the full screen about 45 times a second when using RGB565 mode. If you are using an ATmega based Arduino, it’s probably the CPU that’s limiting your speed. Color graphics take a lot of processing power. Just make sure you’re using hardware SPI and that the SPI clock is set as high as it will go without going over 15MHz.
Thank you for your reply. Sorry for forgetting the most important part about my setup. The Controller i am using, it is a NORA-W106 on a Arduino Nano ESP32 and according to its docs it has a clock speed of up to 240MHz, so i guess that would be enough depending on if that’s also base clock speed its running on right now…
NORA-W10 series modules have a dual-core system with two Harvard Architecture Xtensa LX7 CPUs operating at a maximum 240 MHz internal clock frequency.
Currently i set the SPI speed using
SPI.setClockDivider(SPI_CLOCK_DIV2);Which would be 120MHz to my understanding assuming it runs at maximum speed. Too fast for SPI but that is not how it feels like. I will try some things out once i am back home especially as the method i use seems to be deprecated.
I noticed that you use digitalWrite multiple times for each transmitted pixel. That function is pretty slow - you should instead manipulate the microcontrollers registers directly for maximum performance. If you are using an Arduino, this article will help: https://roboticsbackend.com/arduino-fast-digitalwrite/
Thank you for the article it is really interesting. Always assumed it would already do just that but it does make sense considering the amount of Controller it has to support. Will be changing that anywhere it gets called often.
Make sure that you are not writing one pixel per SPI transaction. The connection, whether HW SPI or bit banging, requires some time to open and close. This adds up quickly. Generally, is best to write a frame per transaction (or as close as possible) so that there are fewer open/close delays.
If you’re using an AVR based Arduino, you’ll likely need to optimize things if you want to do anything like animation so that as little CPU time as possible is used for anything but writing to the SPI bus and minimize blocking operations.
Thank you for your input. That does sound reasonable, currently i am closing and opening for each pixel i am setting. However the example code mine is based on also implemented away to set the cursor on an area. And i can then probably just provide more bytes than just two here. I will try this out later!
I don’t think mine is AVR based. It is the architecture of the CPU right? The datasheet says it has two Harvard Architecture Xtensa LX7 CPUs
You’re welcome!
However the example code mine is based on also implemented away to set the cursor on an area. And i can then probably just provide more bytes than just two here. I will try this out later!
That sounds like it could help.
I don’t think mine is AVR based. It is the architecture of the CPU right? The datasheet says it has two Harvard Architecture Xtensa LX7 CPUs
Ok. That means that you definitely should be able to get more performance out of an SPI display. If you’re able to access both cores, you could likely improve performance by dedicating one to communicating with the display, which, if the display supports it, may be able to effectively eliminate the connection setup/teardown as a factor.
