Hi everyone
I’m a long time user of the BP 3.6, and recently got a BP 6. The issue I’m having is that the bit-order set by the “l” and “L” commands don’t seem to make any difference when in SPI mode, on the BP 6.
I attach three scope captures, first two are the BP 3.6 in “L” and “l” mode respectively, and final one is the BP 6, which behaves the same in either mode. In all examples the command used on the pirate is “[ 0xfa ]”.
Could you enlighten me if this is an understanding issue on my part, or if it’s a firmware issue?
Here are the firmware versions of both devices, in case it’s of any help:
BP 3.6: Firmware v6.3-beta1 r2151 Bootloader v4.4
BP 6: Firmware main branch @ 0f66f47 (Sep 1 2026 13:18:03)
Thanks in advance
German
1 Like
Welcome to the forum, and this is a GREAT bug report:
I appreciate that you included the firmware versions, what data was sent, what you expected, and what actually occurred. And your scope captures were clear and informative. Nicely done.
Clearly, the BP6 is able to send MSB-first without issue. I wasn’t aware of an LSB-first SPI protocol, so … I started digging in.
First thing I looked into was the datasheet for RP2350. It looks like only three frame formats are supported:
- Motorola SPI … always MSB first
- TI Synchronous Serial … also MSB first
- National Microwire … also MSB first
Just based on this, I don’t think the SPI peripheral on the RP2350 supports LSB-first transmission, so this would either need configuration of a PIO engine to reverse the bits (I think this is an easy DMA-based option), or software-based bit reversal.
@Ian – I think this one’s a decision for you:
-
Indicate LSB SPI mode is not supported and print an error message when use is attempted. Not the best long-term result, but depending on when a fix can be made, might be a good intermediate state.
-
Software-based bit reversal … on both transmit and receive. Should be relatively fast/easy (branch based on bit order, plus a single 256-byte lookup table), but … might need to limit data rate based on CPU clock.
-
Do some magic with PIO (+ DMA)? Seems more work than necessary, especially as the RP2350 does not allow directly chaining one peripheral’s events to a second peripheral’s triggers.
Of course, it’s very possible that I missed something in the datasheet … maybe there’s a configuration register for the SPI peripheral that I missed that does control the bit order?
Henry, thank you for your comments!
I came up with this while testing some LED matrix displays (OSRAM SCD55104). These things use this weird LSB-first mode on the data line. Note that this is not strictly defined as a SPI interface, but it’s easier to use SPI mode than bit-banging it 
If there’s anything else you need on my side, just let me know
Cheers, German
If you need to be unblocked rapidly, the only workaround I have for you immediately is to perform the byte reversal yourself. This is because I believe the RP2350 simply does not support sending LSB first for the SPI peripheral.
If you're feeling ambitious...
For your purposes, you might have better results creating a PIO program.
If I had to describe what a PIO peripheral is, I’d describe it as a real-time generic UART, which you can customize via a limited program space, and then assign four state machines to run instructions in that space.
While the instruction set initially seems limited (and it is),
in combination with the state machine’s configuration, of the PIO allows for multiple things to occur on a single cycle:
- Autopull … will automatically pull the configured number of bits from the output register (it’s called output, b/c that is how the code running on the RP2350 mcu sees it), and can be configured to pull MSB or LSB first.
- side-set of output pin(s)
- modification of one of the two registers (X/Y)
- For RP2350 (but not RP2040), can directly address the input/output FIFOs, so if you need a couple extra registers / temp storage …
When you feed a PIO module via a DMA channel, with creativity, you can get a surprising amount done.
In terms of updating the BP5/BP6 firmware … that’s a decision that @Ian will have to make. IIRC, he’s mentioned that he’ll be unavailable for a few days, so please understand if there is some delay in his response. 
And welcome again!
The byte reversal could also be done a layer up by pre-switching before its sent to peripheral