Page 1 of 1

No luck with SPI

Posted: Thu May 17, 2018 9:15 pm
by kwiley
I'm trying to use a PyBoard to control an SPI Arduino shield device. An Arduino Uno successfully communicates with the device, so I know the device is working properly. I have meticulously studied both the hardware (pin assignment and voltage assignments) and the underlying code (SPI library utilization) and I can't get the PyBoard to work. I've dumped the exact string of bytes to the terminal and confirmed that it matches the device's specs and the data the Arduino sendds. I've tried all four SPI modes (even though I've been told mode 0 is the correct one for this device). I've confirmed the wiring (MOSI-MOSI, MISO-MISO, SCK-SCK, SS pulled low). I've tried MSB and LSB (even though I've been told MSB is correct). I've tried 8 and 16 bits. I've tried a few different baud rates. I've taken a multimeter to the slave control pin and confirmed that it's low.

The only thing that makes any difference is whether I set the slave control pin. Set properly (low obviously) I get pure 0s back from SPI. Set high, I get pure 1s (FFs). So, I can get different behavior, which is encouraging, but I can't get anything meaningful. It works perfectly when run from an Arduino.

Another weird thing is that I get all 0s and all Fs even if I init the SPI object to the other (disconnected) SPI bus. It's as if the PyBoard doesn't care whether I direct it at the connected bus or the disconnected bus. It behaves the same, which is totally perplexing. Why would the SPI calls give different results based on the slave pin's high/low status for the other completely disconnected SPI bus?

I realize this post is unlikely to inspire obvious suggestions, as it is too broad a problem to nail down, but if anyone has any further ideas to try, I'd love to hear them.

Thanks.

Re: No luck with SPI

Posted: Fri May 18, 2018 3:04 pm
by pythoncoder
kwiley wrote:
Thu May 17, 2018 9:15 pm
...Why would the SPI calls give different results based on the slave pin's high/low status for the other completely disconnected SPI bus?...
Disconnected inputs have a very high impedance and can float to any potential between 0V and 3.3V. The actual voltage can be influenced by capacitance to adjacent pins and so can be influenced by them. This confusing effect can be eliminated by pulling the pin up or down with a resistor (you could use any value between say 2KΩ and 100KΩ).

As for your general query it's unlikely anyone will be able to help without a lot more information on the hardware.

Re: No luck with SPI

Posted: Fri May 18, 2018 5:18 pm
by kwiley
I guess one thing I'm worried about is that any of the numerous other pins on the shield might be receiving an important signal (including pull down or pull up) from the Arduino and that I need to correspondingly adjust them before PyBoard SPI connected to just a handful of pins will work.

Anyway, good point. I think I pulled all the *relevant* pins the right direction, but maybe I need to pull the rest of the shield's pins one way or another instead of letting them float.

Thanks.

Re: No luck with SPI

Posted: Fri May 18, 2018 5:20 pm
by kwiley
Oh, I'm rereading your response, and since you were responding to my claim that the two buses both react to changes even though only one was connected, that means you were referring to floating pins on the PyBoard, not the shield. Do you believe I need to pull additional pins on the PyBoard itself low or high, in addition to the pins directly relevant to SPI comms?

Re: No luck with SPI

Posted: Fri May 18, 2018 8:28 pm
by kwiley
If anyone is curious about my progress on this problem, I have gotten it to work by going directly to the machine module for SPI control. Attempting to operate SPI via the pyb module fails while identical code (modulo slight SPI naming differences) works via the machine module. Printing the spi object in each case shows some of the initial settings (bus, mode, baudrate, prescaler, polarity, phase, and bits, but no other settings are shown) and those shown seem to be in agreement across the two modules given nonparameterized spi creations (aside from the required bus parameter of course, and in the pyb case, the SPI.MASTER parameter obviously). I left baudrate, prescaler, polarity, phase, bits, firstbit all unstated (default), which appear to be correct for the particular SPI device I'm using.

I may be wrong about the following conclusion, but it appears by my experience so far that the higher level pyb.SPI module (which I presume simply wraps machine.SPI for all internal operations) is not working properly even though the lower lever machine.SPI module works fine. I'm sure I'm wrong because such an obviously DOA problem (pyb.SPI simply doesn't work as far as I can tell) would have been discovered and fixed long before making its way into release code, but I'm not sure how I'm wrong at this point. machine.SPI works and pyb.SPI doesn't, or so it seems (I'm sure this isn't the correct conclusion, but that's what I see).

I'm currently running v1.9.4. I had been testing with v.1.9.2 and briefly with v1.9.3 as well, all with the same problem. I didn't try the machine.SPI fix until after upgrading to v1.9.4 (hoping the firmware upgrade would fix the problem, only then trying machine.SPI after that didn't fix it). I haven't yet firmwared back to .2 or .3 to see if this recently discovered fix of using machine.SPI would fix the problem with those older versions.

Any thoughts on this?

Re: No luck with SPI

Posted: Mon May 21, 2018 6:53 am
by pythoncoder
When I referred to pullups it was on the Pyboard and it was intended to explain your results reading from an SPI bus which was not connected to hardware. There is no general requirement to use pullups.

Regarding the libraries pyb was developed first when MicroPython had only one target: the Pyboard. When MicroPython was ported to multiple targets machine was developed as an attempt at a host-independent abstraction of the various interfaces.

SPI is widely used under both libraries and it's unlikely that you've encountered a fundamental problem with either, but it's hard to be specific about your problem without more details.