Open mbutsch-sts opened 1 year ago
SPI doesn't really distinguish byte boundaries: a 16-bit value is two concatenated 8-bit values. What happens if you send or receive two 8-bit-bytes? We have plenty of libraries where 16-bit values (or larger) are sent that way.
I looked at the datasheet for this device. The protocol is approximately SPI, but the chip-select line appears to be inverted (active high).
I tried sending/receiving two 8 bit values and it works. Is there a reason to not allow configuration of the actual transfer size, especially since there is already a parameter for 'bits'?
Different chip families have different SPI frame size capabilities. Eight bits is always availble. RP2040 is unusual in allowing 4-16 bits. Other chips are just 8 bits (e.g., nRF), 8 or 9 bits (MicroChip SAMD), 8 or 16 bits (STM), etc.
If we were writing a library for the AT93C46D or helping someone, we would recommend using an 8-bit frame size, so that the library would usable without changes and without conditional code inside it, across all chips that implement SPI.
So yes, we could support the RP2040's availability of 4-16 bits, but it's supporting the unique capabilities of a particular chip, so it's a lesser priority than just supporting a universal 8-bit SPI protocol in general (which we already do).
The 9-bit size on the SAMD's I think may be a remnant of a use case of 8-bits + parity, which you don't see much anymore.
OK, thanks. This got me over my issue. I appreciate the responses / assistance.
I am new at CircuitPython and may be misunderstanding some things.
I am trying to use CP's SPI functions on a Raspberry Pi Pico to access a SPI device (AT93C46D) with a transfer size of 16 bits. When I use the configure method, it reports that only 8 or 9 bits are allowed. I believe this is happening because of the line referenced below. https://github.com/adafruit/circuitpython/blob/4b4fb47088dca33e85a5eaeb14096aa16692340f/shared-bindings/busio/SPI.c#L202
The datasheet for the RP2040 seems to indicate that the SPI controller supports a transfer size of 4 to 16 bits.
Is there a reason for CP not to support it?
How would I get this issue fixed?
Thanks, Mark