SPI support of firstbit

[robhamerling]

I tried to run a program for TM1638 on a RP2040 Pico. The program uses SPI and works fine on PyBoard and ESP32, but the RP2 Pico Micropython firmware (1.20.0-68) seems to lack support for 'firstbit', which is required for the TM1638. Nevertheless SPI.MSB and SPI.LSB are defined (for what purpose?).
Must I conclude that use of SPI is a 'mission imposible' situation (temporary or permanently)?

This REPL session shows the error message:

MicroPython v1.20.0-68-g3229791b6-dirty on 2023-05-11; Raspberry Pi Pico W with RP2040. 
Type "help()" for more information.
>>> from machine import SPI, Pin
>>> sbus = SPI(1, sck=Pin(10), mosi=Pin(11), miso=Pin(12))
>>> sbus.init(polarity=1, phase=1, firstbit=SPI.LSB) 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: LSB
>>> 

[scruss]

Pin definitions seem to have shifted a bit on the Pico under 1.20

I do seem to remember using mcauser's MicroPython TM1638 LED Driver (via Awesome MicroPython)with a Pico, though.

[robert-hh]

Pin definitions seem to have shifted a bit on the Pico under 1.20

@scruss Hardly. The pins stay the same, only the default pin assignments for SPI, I2C or UART may have changed.

@robhamerling firstbit=SPI.LSB is not support by the Pico port for the hardware SPI and generally not supported by SoftSPI, although it could easily be added. The keyword value is present because that part of machine.SPI is common to all ports. So the only choice for you would be to transposed the data yourself, maybe using a byte- or nibble-table.

[robhamerling]

@roberthh: Thanks for the suggestion for using a DIY bit-reversion. The code for the reversion won't be a problem, I found several examples. Adapting the driver without disrupting the existing working for systems wih supported SPI.LSB may need some ingenuity (and time...).

[peterhinch]

See #11404

[robhamerling]

@peterhinch: Great, already 2 weeks ago. I missed that!

[robhamerling]

FYI:
The code to compensate for the missing support of firstbit=LSB in the SPI driver wasn't too complicated.
Essentially it requires a procedure to reverse the bits in a byte, see e.g. the code below.
To be able to use the driver for the TM1638 with systems with and without support of firstbit=LSB
the presence of LSB support can be detected with a try/except: when the try fails a flag can be set
as signal that for every SPI byte in and out the bits must be reversed.

# table to reverse the bits of a nibble
REVNIB = bytearray(b'\x00\x08\x04\x0C\x02\x0A\x06\x0E' +
                   b'\x01\x09\x05\x0D\x03\x0B\x07\x0F')

# procedure to invert the bits of a byte:
# translate and exchange the nibbles
def diyrev(self, x):
    return (REVNIB[x & 0x0F] << 4) | (REVNIB[(x & 0xF0) >> 4])

# detect the presence of support for firstbit=LSB
try:
    spi.init(firstbit=SPI.LSB)
except NotImplementedError:
    print("Info: firstbit=SPI.LSB not supported by SPI driver")
    diylsb = True            # use DIY code for firstbit=LSB

[peterhinch]

For fast bit reversal algorithms see here.

[robert-hh]

Just today I made a PR to support LSB for SoftSPI. I did not look into the RP2040 port, whether the hardware driver supports LSB.