SPI using Pyton3

Pavils Jurjans

There was that email from Onion to the user community where users were encouraged to switch to Pyton3, because Python2.7 will be at EOL soon.

So I went ahead and installed it (instructions at https://docs.onion.io/omega2-docs/installing-and-using-python.html)

Next, I wanted to install SPI module, do to some experiments with APA-102 RGB LED strip. I found this page:
https://docs.onion.io/omega2-docs/spi-python-module.html#spi-python-module

But installing the pyOnionSpi package resulted in pulling in also the python-base package, so I figure this is a Python 2.7 module. I can't find any trace of corresponding package for Python3. Does it exist? Because if it does not, and maybe also other specialized modules for Omega are not migrated, then there is good incentive to stick with Python2.7.

Lazar Demin

@Pavils-Jurjans again, I would recommend using python-spidev (https://github.com/OnionIoT/python-spidev) instead of pyOnionSpi
However, we haven't yet released a Python3 compatible spidev module. But it'll be coming soon!

Pavils Jurjans

Ok, thanks, I will use this python module for now, and stick with Python 2.7 until you release the Python3 version.

Pavils Jurjans

Hmm, I just tested the python-spidev and it just gives bad output. The clock is uneven, and the data has only one instance of "1", followed with pause, and then left at HIGH for long time:

alt text

Here's the code I use for testing:

import spidev
spi = spidev.SpiDev()
spi.open(32766, 1)
to_send = [0x01, 0x02, 0x03]
spi.xfer(to_send)
spi.close()

Meanwhile, the pyOnionSpi, that appears to be based on the buggy spi-tool, at least gives me correct output:

alt text

import onionSpi
spi  = onionSpi.OnionSpi(1, 32766) # Due to the spi-tool bug, bus and device param values are swapped
spi.write([0x01, 0x02, 0x03])

So I am not sure why you are suggesting to switch to something that doesn't appear to work at all.

Lazar Demin

Tested it many times internally, works well with displays and other devices.
It's important to remember that spi-tool and python-spidev are just userspace programs that make requests to the kernel to use the SPI hardware.
There isn't anything in python-spidev that can confuse the hardware enough that it will produce bad output.

What is the clock speed you're seeing with python-spidev? It's possible that python-spidev's default transfer rate (clock speed) is greater than the sampling rate of your logic analyzer, resulting in what looks like an uneven clock and bad data.
That actually happened to me the first time I used python-spidev

See the writebytes.py example for a pointer on changing the clock speed.

Pavils Jurjans

Dammit, you're right! I should've checked the time scale on the crippled diagram.

But now I stumble on the next problem. I connected my APA-102 RGB LED strip to the GPIO pins 7 (CLK) and 8 (MOSI), and it appears that this connection causes some bad interference with Omega:

At boot, about 20 of LEDs are lighting up and twinkling, showing that there is some data being sent out of SPI. Since I am not using the CS1 pin, my interpretation is that the data that is meant for SPI device 0, now is captured by the LED strip (it says here, that "..device 0 (CS0) is connected to the flash memory used by the Omega").
Omega is working with random glitches, perhaps the communication with device 0 is being messed up.

Perhaps I am missing some simple fix here? Perhaps I should let the LED strip receive signal from MOSI only when CS1 is high?

Lazar Demin

@Pavils-Jurjans said in SPI using Pyton3:

Perhaps I should let the LED strip receive signal from MOSI only when CS1 is high?

Yeah, a small circuit that leaves MOSI floating unless CS1 is asserted will resolve your issue. Just be aware that CS is active-low in the default SPI mode.

Pavils Jurjans

Pardon my ignorance, but could you, please, point me to an example of such circuit? I am not sure I can come up with the best solution. Being a programmer rather than electronics engineer, all I can think of is throwing in an AND gate where CLK and (active-high mode) CS are inputs and the output goes to the LED strip.

Lazar Demin

@Pavils-Jurjans It would likely be a non-inverting CMOS circuit, where CS1 controls whether the Omega's MOSI is connected to your LED strip

Pavils Jurjans

@Lazar-Demin Thanks, I ordered bunch of 74HC125D chips, and it seems to do the trick.

I set up only the CLK line to go through the buffer, though. But as long as the APA102 LED strip works, and the communication with flash memory (SPI device 0) is not disturbed, there's no need to make the similar setup for MOSI, too.

There's another problem surfacing now, though. The spi.xfer(byte_array) command sends only 28 bytes correctly, and then the rest is just a bunch of zeros or 0xff. It is as though there's some internal buffer with size of 28 bytes.

import spidev
spi = spidev.SpiDev()
spi.open(32766, 1)
spi.max_speed_hz=100000 # 100 KHz

size = 50;
spi_data = [0x00] * size

for offset in range(size):
  spi_data[offset] = offset

print spi_data

spi.xfer(spi_data)
spi.close()

Pavils Jurjans

@Pavils-Jurjans Ok, finally, got this working! The missing data problem was solved by changing the frequency to 200KHz. Apparently, the hardware SPI gets unreliable with low frequencies. Now I wonder what is the maximum frequency, as I tried 3.2MHz and it still works (For my 300 pixel APA102 RGB LED strip, I measure about 200 updates per second).