RP2 SPI oddness with default pins. I'm foxed.

[peterhinch]

I have encountered this at least twice but have failed to produce a simple repro. If a hard SPI interface is instantiated with (e.g)

spi = SPI(1)

the interface works, in that signals appear on the expected pins, but the application behaves erratically. By contrast this is reliable:

spi = SPI(1, sck = Pin(10, Pin.OUT), mosi=Pin(11, Pin.OUT), miso=Pin(28, Pin.IN))

I encountered this with the NRF24l02 - see code comment - and also with a display driver. The display application would run under some circumstances but not others, e.g. worked on USB connection to PC but not when launched on power up by main.py. At one point it worked on USB but only if I ran rshell first. None of the symptoms made any sense until I remembered the NRF24l01.

The odd thing is that, in the failing state, a scope or LA shows perfect signals on the pins.

The workround is obvious: always specify pins. But it would be good to know what is going on...

[robert-hh]

@peterhinch The code configures the GPIO mode to GPIO_FUNC_SPI, but nothing besides that. Your example with specifying the pins performs additional configuration. Since you see signals at the LA, it would be interesting if the difference is only related to the miso pin. Could you try to run both variants, but only specify miso?

[peterhinch]

I re-tested the three variants as follows

1. SPI(1) failed.
2. SPI(1, miso=None) failed.
3. SPI(1, miso=Pin(28, Pin.IN)) passed.

Testing was done by power cycling the system: the above behaviour seems consistent.

[peterhinch]

Your patched code works fine with this invocation:

self.spi = SPI(1, sck = Pin(10), mosi=Pin(11))

Where a port doesn't support specifying pins I would hope that the constructor would throw an exception if args were passed. If a port doesn't allow specifying miso=None an exception should be thrown if it's attempted.

The RP2 behaviour (without your patch) is simply wrong, with an outcome which can be confusing. At one point I suspected a hardware fault.

[robert-hh]

For consistency with the previous setting: If you do not specify miso=xxx, the default value is used. I do not know if you mean that with "fine". If miso shall not be used, you have to specifiy miso=None.

[peterhinch]

I tested miso=None successfully. The fact that not specifying miso also worked illustrates the intermittent nature of this fault. Pin conflicts are like that, I guess.

The one thing I'm sure of is that specifying an unused pin (GPIO28) always works...

Re other ports, in some cases (STM32) the hardware does not allow alternative pins. I would suggest that the constructor should work as follows

spi = SPI(1)  # OK
# Or
spi = SPI(mosi=Pin("X8"), miso=Pin("X7"), sck=Pin("X6"))  # The only legal pins

The following would throw an exception

spi = SPI(mosi=Pin("X8"), miso=None, sck=Pin("X6"))  # Disallowed by hardware
# Or
spi =  SPI(mosi=Pin("X8"), miso=Pin("X7"), sck=Pin("X1"))  # Disallowed by hardware

[robert-hh]

The fact that not specifying miso also worked illustrates the intermittent nature of this fault. Pin conflicts are like that, I guess.

The last setting rules. If you instantiate SPI first and then the Pin at GPIO8, it is configured as Pin object.

I do not know yet how to deal with STM or Renesas. ESP8266 could have the single miso=None option like MIMXRT. Anything at changing STM32 code is quite a bit of work, since it is quite convoluted, often changed. And the Renesas people just picked the wrong template for their port. They should have chosen rp2 instead of stm32.

[robert-hh]

I added a miso=None option to ESP8266. But that's it for the moment.

[robert-hh]

So that is the state now of the port_spi branch in my copy of the repository:

• rp2 Sample implementation done for miso=None
• esp32 All of mosi, miso and sck can be set to None in the existing state
• samd miso=None is supported already
• nrf Sample implementation done for miso=None; possible for the other signals as well
• mimxrt Sample implementation done for miso=None, based on the actual state of the port.
• esp8266 Support a keyword parameter miso=None, even is selecting miso, mosi and sck is otherwise not supported.
• SoftSPI Sample implementation for miso=None.
• stm32 Selecting miso, mosi and sck is not supported.
• renesas-ra Selecting miso, mosi and sck is not supported.

[scruss]

fwiw, it doesn't look like pin 28 is the default for SPI(1):

>>> spi = SPI(1)
>>> spi
SPI(1, baudrate=992063, polarity=0, phase=0, bits=8, sck=10, mosi=11, miso=8)

[robert-hh]

That was the intention, because it could be assigned w/o warning. miso was not used for that application, but Pin8 was needed for something else.