I am using the pigpio Python module's SPI functionality as a master (communicating with an external SPI slave). In the same Python script I'm also using my own bit-banged SPI driver on the same pins (Broadcom 8, 10, and 11) with RPi.GPIO, but not at the same time of course.
Most of the time, my Python script runs fine and I see the expected SPI signals on the scope. However sometimes on a consecutive run of my script I see that pigpio's SPI method
spi_write() doesn't generate a chip-select on CE0 (Broadcom 8) any longer.
My main Python script runs a bunch of
unittest test cases against my SPI slave, and sometimes the tests do fail because the slave is not behaving correctly - this is expected. I suspect that one of these failures is leaving pigpio in a state where it can no longer control the CE0 pin on the next run. I can't quite nail down what the failure is. (I am doing a pi.spi_close(handle) in my
The behaviour I expect is this:
pi = pigpio.pi()
handle = pi.spi_open(0, 32000, 0)
After this, I expect
gpio readall to show that CE0 is ALT0. And normally it is ALT0. However when things have gone awry (CE0 isn't toggling on the scope anymore when I run my test cases) `gpio readall' shows that CE0 is OUT. When I execute the 3 lines of Python shown above in an interactive session, CE0 doesn't change to ALT0 after the open like it did before.
Is there some type of cleanup or close operation that I'm missing here? Is there some state that RPi.GPIO can leave the GPIO pins in if it's not cleaned up properly during a
tearDown(), one that prevents pigpio from working again?