Would this work on a Orange pi pc?

[marksev1]

Hello,

does this library have something specific to the Raspberry Pi or do you think that it would work on a Orange Pi Pc too?

Thanks

[rm-hull]

If the Orange PI:

• has SPI and exposes it via the /dev/spidev0.0 devices, and
• the python dependencies install ok (particularly the spidev package), and
• you wire up the device to the GND, 5V, SPI.MOSI (master-out, slave-in), SPI.CE (chip-enable) & SPI.CLK (clock) correctly

Then I can't see any reason why it wouldn't work.

If you run the following commands at the bash prompt on your OrangePI, what output do you get?

$ dmesg | grep spi
$ ls -l /dev/spi*

[marksev1]

msev@orangepipc:~$ dmesg | grep spi
[    0.469611] sunxi_spi_chan_cfg()1376 - [spi-0] has no spi_regulator.
[    0.469803] sunxi_spi_chan_cfg()1376 - [spi-1] has no spi_regulator.
[    0.470592] spi spi0: master is unqueued, this is deprecated

and

msev@orangepipc:~$  ls -l /dev/spi*
crw------- 1 root root 153, 0 Jul 25 01:17 /dev/spidev0.0

Thanks!

[rm-hull]

So the kernel supports it, try and install the python dependencies, the 40-pin header has the relevant pinouts (looking at the diagram I grabbed earlier), so if you have a device ... try it!

[marksev1]

Cool! I have the orange pi already, need to order the 8x8 max7219 led matrix :)..When I get it and test it I'll let you know. Great news! Should I close the issue or will we let it open till I report the test results?

[rm-hull]

Don't mind whether you close this issue or keep it open, but it would be great keep me up-to-date with what you find & we can then add a section to the readme for any other OrangePi who may be interested.

The LED matrix is pretty cheap, and readily available from ebay sellers in China - I don't know where you live, but in my experience, delivery from China (to the UK) is pretty reliable and only takes a week or two.

Main thing is to have fun playing with it though :-)

[marksev1]

indeed I shall :-D

[thijstriemstra]

@marksev1 any news?

[rm-hull]

Trawling over some forums, someone appears to have gotten the 0.2.3 version working on an Orange Pi: https://forum.armbian.com/index.php/topic/1616-spi-kernel-driver/#entry12518

I am in the process of seeing if I can get it working on an Orange Pi Zero: current status: ~not~ working

References

https://forum.armbian.com/index.php/topic/840-h3-spi/

[rm-hull]

Update: latest version (0.4.4) working on an Orange Pi Zero, with port=1

[marksev1]

Thanks :)

[soif]

BTW for those having headaches on orangePi, here is my working configuration on OrangePiPC+:

in /boot/armbianEnv.txt

overlays= spi-spidev
param_spidev_spi_bus=0
param_spidev_max_freq=1000000

also I add to change the frequency speed in the example, to match the one in armbianEnv.txt

serial = spi(port=0, device=0, gpio=noop(), bus_speed_hz=1000000)

without changing the Freq, some garbage characters, bugs were happening all the time.

BTW I did not make any test with faster frequencies....

[rm-hull]

without changing the Freq, some garbage characters, bugs were happening all the time.

Ohh! that's very interesting @soif, thanks for the update.

... paging @drspangle ...

[drspangle]

@rm-hull Thanks for the heads up.

@soif I've found in my experience that setting the bus speed to between 1 and 4 MHz and the spi-transfer-size to 32 (which is the smallest possible value to use with a MAX7219) has been the most stable. Still, when using 6+ MAX7219 modules, there are stability issues. I believe that this largely has to do with transient voltage spikes along the data line (currently investigating this). Sadly this isn't something that you can fix by further dropping down the clock speed below 1MHz or the spi bus MTU below 32.

One source of trouble I've encountered lately is that there is a lot of capacitance when using jumper wires with dupont connectors and breadboards. If you have the option, soldering connections wherever possible drastically improves stability. If you want to use a lot of modules (in my case I'm using 80 of them) you will undoubtedly need to create a PCB to connect all the modules together, and solder everything in place. I'm also experimenting with whether it is necessary to add a buffer chip every 4 modules or so to ensure the data line remains at 5V, because there is some voltage drop and weird transients that occur when wiring DOUT to DIN on several of the modules in series.

Also, you are guaranteed to have corruption all over the place if you don't follow the documentation (connect the power, ground, clock, and cable select pins in parallel). The 3V3 to 5V0 boost converter mentioned in the docs is also a must, or you will undoubtedly have corruption, as the pulses will not be stable enough to always engage the Schmitt trigger in your drivers. This is assuming that the Orange Pi uses 3V3 on GPIO 10 (MOSI), GPIO 8 (SPI CE0), and GPIO 11 (SPI CLK), which is the standard configuration for a Pi. If using the MOSFET-based boost converter schematic in the docs, make sure your resistors are low enough ohms that it doesn't affect the rise time of the pulses - this is generally why it works better when you reduce the clock speed to <4 MHz. You may also need to add extra buffering capacitors on your VCC line, as I've found that is an issue that can also lead to weird bit flips, and thus display corruption.

[soif]

@drspangle : Thanks for reporting your experience, I will then try to push it to 4Mhz : I guess that I have to change the limit in ArmbianEnv, too right?

Also, as I intend to use the OrangePi for some others cpu intensive tasks (ie speech recognition) at the same time, does increasing the Frequency really cost some valuable CPU cycles, or not ?

---

In my case , I've used

• a 4 x MAX7219 on the same pcb module, ( so no solder issues) from aliexpress
• a separate powerful 5V PSU
• some 3.3v -> 5V level shifters (as suggested in the documentation.... )

it looks pretty stable currently

As I intend to use 12 modules (3 x 4), I will report As soon as I receive the next ordered modules

the spi bus MTU below 32.

where did you changed this ?

[drspangle]

@soif These config options are supported by the command line parser used in the luma examples. Use --spi-bus-speed and --spi-transfer-size arguments to configure them. I think @rm-hull would be better qualified to remark on how to set these separately without kludging things together, but I think you would likely save a lot of time and headache to modify one of the examples in https://github.com/rm-hull/luma.examples so you can use the command line argument parser framework he's set up. AFAIK there is no need to modify the OS configuration settings aside from what is required to setup SPI in the first place. The driver used under the hood by the luma framework seems to accept the arguments and adjust the frequencies and MTU and so on for you.

[drspangle]

Also, as I intend to use the OrangePi for some others cpu intensive tasks (ie speech recognition) at the same time, does increasing the Frequency really cost some valuable CPU cycles, or not ?

This depends on whether you're doing the concurrency properly. I don't know what the specs are on your device, but it's easy to use an entire core just doing the display driving, and the frequency doesn't affect this much. It will affect the percentage of cycles used for iowait, but you will need to do some performance benchmarking on your own. There's a performance benchmarking tool inside the luma.examples repo that you ought to use to profile the rendering framerate and CPU usage you can expect for your number of modules. Check the command line args for that as well.

[soif]

Thanks for the explanations and advices. 🍺