Help with speed difference between SBCs

To be clear, this is not any actual problem with luma.lcd. I’m filing it as a means of asking for help in how to debug a speed difference I’ve observed between two SBCs. Pointers or suggestions would be appreciated, after which this issue can just be closed.

Note that one of the marketing points for the C4 is improved SPI frequency.

Also recall, from one of my earlier filings, that RPi SPI frequency appears to be constrained to an even frequency, rather than a frequency that is a power-of-2. Opening that up in luma.core’s serial.py would permit a wider set of usable frequencies. I have locally hacked on the installed serial.py for the experiment below.

Type of SBCs

Raspberry Pi 3 Model B v1.2 Odroid C4

Linux Kernel version

RPi: Linux raspberrypi 5.4.51-v7+ #1333 SMP Mon Aug 10 16:45:19 BST 2020 armv7l GNU/Linux C4: Linux C4 4.9.113 #1 SMP PREEMPT Fri Aug 14 20:30:41 UTC 2020 aarch64 GNU/Linux

Other versions

luma.core: 1.17.1 on both luma.lcd: 2.5.0 on both luma.examples: commit ceb01960 on both (from Wed Oct 21 16:53:13) spidev: 3.4 on both Pillow: 7.2.0 on both RPi.GPIO: 0.7.0 on RPi, 0.6.3post1 (the RPi.GPIO-Odroid version) on C4

Both displays are ILI9341, connected as the sole device on each SBC’s spi0 outputs.

Expected behaviour

On both SBCs I am trying the following demo from luma.examples:

python bounce.py \
  --interface spi --display ili9341 \
  --width 320 --height 240 \
  --backlight-active high \
  --gpio-reset-hold-time 0.2 --gpio-reset-release-time 0.2 \
  --spi-bus-speed 48000000

Actual behaviour

On RPi, the bounce demonstration noticeably increases in FPS as the SPI frequency is increased. The attached photo shows the results when running with a 50 MHz spi-bus-speed, getting almost 19 FPS. (It varies over time, with the photo showing 18.9. Most of the time it is running just a bit over 19.)

The second photo shows the C4, running with 48 MHz. Its FPS is behaving identically to when the bounce demo is invoked with an 8 MHz speed.

RPi:

C4:

The command line option is certainly getting parsed on the C4, for specifying spi-bus-speeds lower than 8 MHz has a definite effect. I can get it go far slower!

I’m trying to understand where the “bottleneck” is, given the lack of any error responses from spidev when speeds >8 MHz are specified. Any suggestions?

As I mentioned at the start, this issue is just a request for assistance. If we can’t dream up any debug ideas, I’ll just close it out.

[mattblovell]

@rm-hull, the change to serial.py is indeed quite a small one:

@ -294,7 +292,7 @@ class spi(bitbang):
                  bus_speed_hz=8000000, transfer_size=4096,
                  gpio_DC=24, gpio_RST=25, spi_mode=None,
                  reset_hold_time=0, reset_release_time=0, **kwargs):
-        assert(bus_speed_hz in [mhz * 1000000 for mhz in [0.5, 1, 2, 4, 8, 16, 32]])
+        assert(bus_speed_hz in [mhz * 1000000 for mhz in [0.5, 1, 2, 4, 8, 16, 20, 24, 28, 32, 36, 40, 44, 48, 50, 52]])

All of those (well, the higher ones, I didn’t try going extremely slow) worked with the ILI9341 display I have. I tested 60 MHz as well, and it did work! Of course, bounce.py performance does not keep increasing with increasing SPI frequency (maxing out in the 18.5 to 20 FPS range).

@thijstriemstra, I’ll see about upgrading Pillow. On RPi, I’ve just been using what pip provides. On the Odroid, I used the package that entware provides.

Thanks, Matt

Update: I just tried the 500 kHz speed. It works as well, if you want to call ~0.7 FPS working. 😃

[mattblovell]

Here’s the device driver change for Odroid:

https://github.com/hardkernel/linux/commit/98774b14800f028b86288b18262227af623559b7