SPI using Pyton3
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:
But installing the
pyOnionSpipackage resulted in pulling in also the
python-basepackage, 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.
@Pavils-Jurjans again, I would recommend using
python-spidev(https://github.com/OnionIoT/python-spidev) instead of
However, we haven't yet released a Python3 compatible spidev module. But it'll be coming soon!
Ok, thanks, I will use this python module for now, and stick with Python 2.7 until you release the Python3 version.
Hmm, I just tested the
python-spidevand 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:
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:
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.
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.
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?
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.
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.
@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
@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 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).