I’ve attached a SPI LCD display (ST7789 - 240x240 pixels) on the zero board.
It work fine but it’s limited to less than one frame per seconde probably because the SPI device is limited to :
param_spidev_max_freq=10000000
So what i did:
change param_spidev_max_freq in /boot/uEnv.txt
overlays=meson-g12a-spi-spidev
param_spidev_spi_bus=1
param_spidev_max_freq=120000000
recompile and install the kernel and especialy meson-g12a-spi-spidev.dts file :
But the display is still limited to less than 1 frame per second. I don’t have an oscilloscope to check the SPI clock speed but it always seems limited to a very low speed
Is there a way to increase the SPI clock (maybe I use a bad multipler)?
param_spidev_max_freq (int)
Maximum SPIdev frequency
Optional
Default: 10000000
Range: 3000 - 100000000
So, I can apparently set the clock up to 100 Mhz, but even after a recompile and even if I can see that spi.max_speed_hz is well set to 100 Mhz in spidev (I also check that it’s well set with “dtc -I fs /sys/firmware/devicetree/base”), the SPI is still very low (probably 10 Mhz). I’ve tested on both spi on 2 different Radxa Zero.
Do you have any idea? Is there a hardware clock limit to only 10Mhz ?
I found an interesting error that I miss previously in “dmes” when I activate SPI.
I have the same error log on 2 different Zero SBC.
I’ve tested with 2 debian raw images (one from january and the last one) and I even rebuild the kernel and I’ve always the same problem. To reproduce this kernel error, you juste have to activate spidev in /boot/uEnv.txt
I got a good fps on my ST7735s lcd, although when i try to run large videos and scaled down to 128x128, i tends to get choked on cpu since it tries to downscale it and write to framebuffer.
But for relatively small resolution video / display, it can be handled ok.
I’ve make a bench raspberry vs Raxda zero on the same SPI display 256x256 :
Raspberry can display 500 frames in 37 seconds (and It could be probably be improved)
Raxda zero can display 500 frames in 154 seconds
It’s insufficient to display animations on Raxda
As you can see on my video, the Raxda zero (at the bottom) display blinks a lot more compared to Raspberry (at the top)
param_spidev_max_freq (int)
Maximum SPIdev frequency
Optional
Default: 10000000
Range: 3000 - 100000000
But In my experience, it’s only limited to 12Mhz maximum (the frame rate is reduced if I set param_spidev_max_freq bellow 12 000 000 but It does not increase if I set above 12Mhz)
I’ve try to modify the SPI clock (spicc1: spi@15000 {}) in meson-g12-common.dtsi but without success. I don’t know if we can increase the clock or even if we can use an other clock for SPI
I use a 256x256 display, it’s 4 time more data to transfer vs 128x128.
I got same issue.
I have a 0.96inch(160*80) screen,using python language to write screen program.
before find your problem I thought problem in python mraa library because use raspberry B+ didn`t have this issue
I’ve make some benchmarks, I found that spi data rate is approximately 8 time slower in radxa zero compared with raspberry pi 4, resulting in a low frame rate.
It’s realy the spi bus which is the bottelneck and probably because the spi clock rate is too low (I can’t be very assertive because I don’t have an oscilloscope to check the clock rate). It’s still low if you increase param_spidev_max_freq or spi.max_speed_hz (in spidev)
You can maybe improve the smoothness of your screen if you use the linux “fb” frame buffer (fbtft) instead of directly drawing your screen with Python (PIL wich don’t use fbtft if used with spidev) because it’s possible that the linux “fb” only refresh the tiny screen portion which differs from the previous frame instead of refreshing the whole screen (that’s probably the reason why you could have a good frame rate with a low frequency if you have only tiny difference between each frame )
my observation is that spi rate is to low to properly display video/animation/gif/transition effect on a 240x240 diplay on radxa zero. It could probably be acceptable with a lower screen resolution : it’s almost smooth if I only use half of the display (240x128) and probably even better with your resolution (160x80)
As you have said ,it only 6MHz.
I try to use spidev but the library will report segmentation fault Error without other messages. so i abandoned the library.
libmraa library Spi Instance writeByte function what each loop write only one byte.so this is another reason why my screen is solw .
Could you please write up a basic step by step on how to get an SPI display working? I have an ST7789V - it it really just as simple as editing the armbianEnv.txt file to include the module and set the appropriate parameters?
Unfortunately it still does not make sense as actual instructions. The first page contains a few paragraphs that look like they’re supposed to be instructions, but aren’t actually instructions. They’re statements of information, but the comments above those blocks do not tell you either whether you’re supposed to see that information somewhere and correct it if it’s missing, add it to something, or fix it if it’s not there, or indeed where to put those parameters or that information.
The comments also don’t actually tell you what to do with that information, where the information is supposed to go or come from, or why. It’s not instructions, it’s just disassociated information. You can’t actually follow the steps to achieve goal, because they’re not all steps.
The conceit is that the instructions as written assume that the reader is going to be both familiar and comfortable with compiling their own device drivers and descriptors (as near as I can tell). This is a poor assumption.
Most of us just want the driver support for the most commonly used hardware ready to go, and not have to roll up our sleeves and compile our own drivers. Product engineers are supposed to be doing this, and this should not be an end-user level issue. If this is within your skill set, then hurray, well done - but that’s not most of us.
In the interim, if anybody can translate those data statements into actual instructions, I think the entire community would benefit.
I can confirm that the demo code is working and is clear enough. You must have the necessary knowledge to follow the instruction and build the device tree : basic linux knowledge, bash, etc… you don’t need to be a linux expert but a minimum level is required because it’s not plug and play and you should connect the corrects pins to your device because most devices are specific to Raspberry devices and because the Zero is a rather recent SBC
As a professional technical writer and lead programmer with decades of experience in both, I can confirm that it is not clear enough. Connecting the pins is something anybody can look up, that’s fine. And, I’m sure it’s clear to you. However, I ask you to consider the possibility that more people need to be able to follow this procedure than can necessarily fill in the blanks present in the documentation.
Can you hand these instructions to somebody who has never rebuilt a device tree before and expect them to successfully complete the task? For most people this will be their first exposure to the process.
The answer to “how does this work” should not be “if you don’t surf, don’t start.”
