Lomax
Posts: 189
Joined: Wed May 20, 2015 9:43 pm

Curious SPI behaviour with spidev-3.4

Fri Feb 22, 2019 12:54 pm

I'm trying to get a Pi Zero W to talk to a MAX7219 LED driver over SPI using spidev-3.4 and the Python max7219 library v0.2.3, but the LED driver doesn't respond and the data coming out of the SPI0 port when running the included example looks very odd:

Image

While I'm somewhat new to using the SPI port that just doesn't seem right, and my scope doesn't detect any valid data either. By contrast, when I compile and run spidev-test.c I get something quite different, which my scope readily decodes:

Image

Does this issue look familiar to anyone?

Edit: Forgot to mention, the measurements were taken upstream of a 3.3-5V level converter (needed for the MAX7219), hence the 5V range. And to clarify, the blue channel in the images above shows the SPI0 MOSI data line (BCM #10), the red is SPI0 SCLK (BCM #11), and the green SPI0 CE0 (BCM #8). One notable oddity with the first sample, apart from the lack of any discernable data, is that the clock looks very weak; it barely reaches 2V. Finally, in case anyone's wondering, absolutely nothing was changed between capturing these samples; all wiring remained unchanged, so did the settings on my scope, and the configuration of the Pi - the only thing altered is the command executed (python sevensegment_test.py vs ./spidev_test -D /dev/spidev0.0).

Lomax
Posts: 189
Joined: Wed May 20, 2015 9:43 pm

Re: Curious SPI behaviour with spidev-3.4

Sat Feb 23, 2019 11:49 pm

Ok, so I buckled under and replaced the max7219 Python library with the latest version - now called Luma.LED_Matrix and of course it all works perfectly. My preferred version 0.2.3 is quite old, from 2016, but it is nice and clean unlike the whole "Luma" thing which is a big sprawling library that supports lots of different display types and LEDs (including "NeoPixels" and full colour OLED displays). I'm only interested in talking to MAX7219 chips, so all the extra bloat is rather unwelcome. Be that as it may, the Luma.LED_Matrix library does work, and below is a capture of the SPI traffic it generates:

Image

Interestingly, this looks very similar to the non-working data generated by max7219 v0.2.3, but notably the clock pulses are much stronger, and the data is correctly decoded by my scope (a little hard to see due to the timebase, but the black squares at the top represent captured bytes). I would love to know what exactly has been changed to fix this, but when the library was renamed to Luma.LED_Matrix it was completely restructured and there is no unbroken history for the relevant files. It's still using spidev 3.4 though, so that's not it. Grateful for any input!

Lomax
Posts: 189
Joined: Wed May 20, 2015 9:43 pm

Re: Curious SPI behaviour with spidev-3.4

Sun Feb 24, 2019 12:23 am

Sometimes it helps to be stubborn - I just wish I knew beforehand when that is. This time it paid off: just after I posted the above, I (somewhat desperately) searched the forums for "max7219", in the hope that a recommendation for some other library might turn up (though a similar search on Github had drawn a blank). I soon found @razi's post mentioning that the clock frequency needed to be explicitly set for the max7219 Python library to work correctly on Pi3 systems. Makes perfect sense, in fact I'd been down that path already based on what I was seeing on the scope, but had satisfied myself that spidev would default to 500kHz when no clock speed had been specified. It turns out I must have misunderstood something, because applying @razi's patch fixed max7219 v0.2.3, and I can now use it to control my 7-segment displays. Whohoo!

User avatar
DougieLawson
Posts: 36312
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Curious SPI behaviour with spidev-3.4

Sun Feb 24, 2019 1:03 am

Lomax wrote:
Sun Feb 24, 2019 12:23 am
I soon found @razi's post mentioning that the clock frequency needed to be explicitly set for the max7219 Python SPI library to work correctly on Pi3 systems.
FTFY.

It's all SPI in python or any programming language with the 4.14 kernel or later
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

danjperron
Posts: 3405
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: Curious SPI behaviour with spidev-3.4

Sun Feb 24, 2019 1:08 am

Looking at your first chart of your scope and It was on my mind that the spike is a full SPI exchange. You only see a pike because your timing of your scope was way to slow.

I checked the python library and there was no clock speed set then it was obvious that the SPI could be way too fast.

A small change in the original python library to set the clock speed should fix the problem.

I suppose the patch you talked about is what it does!

cheers !

Lomax
Posts: 189
Joined: Wed May 20, 2015 9:43 pm

Re: Curious SPI behaviour with spidev-3.4

Sun Feb 24, 2019 1:50 am

DougieLawson wrote:
Sun Feb 24, 2019 1:03 am
Lomax wrote:
Sun Feb 24, 2019 12:23 am
I soon found @razi's post mentioning that the clock frequency needed to be explicitly set for the max7219 Python SPI library to work correctly on Pi3 systems.
FTFY.

It's all SPI in python or any programming language with the 4.14 kernel or later


Ah, good, thank you!
danjperron wrote:Looking at your first chart of your scope and It was on my mind that the spike is a full SPI exchange. You only see a pike because your timing of your scope was way to slow.


Yes, I should have mentioned, I did of course look much closer, and it's complete garbage:

Image

Something like 8MHz? Didn't make any sense to me at the time - clearer now!
danjperron wrote: I checked the python library and there was no clock speed set then it was obvious that the SPI could be way too fast.

A small change in the original python library to set the clock speed should fix the problem.

I suppose the patch you talked about is what it does!

cheers !


Yep, all good now, thanks!

Return to “Interfacing (DSI, CSI, I2C, etc.)”