You have connected a display to your prototype, selected the communication settings and sent a command. There are pulses on the wire, but the display does not behave as expected. One question is easy to overlook: does the hardware send the individual bits in the order the display expects, or does the software merely show the right setting?
This was a concrete problem in a Bus Pirate discussion opened September 10, 2026. A developer testing OSRAM SCD55104 LED displays found that changing the tool's SPI bit-order option did not change its output. They supplied the firmware versions and captures. On September 15, the maintainer posted a fix, and the reporter confirmed that both modes then worked.
That is one resolved firmware report, not evidence that current Bus Pirate releases generally fail or that every blank display has the same cause. Its useful lesson for a small hardware team is the method: compare the requested setting with the signal that reaches the device, and tie the result to a software version.
One byte can travel in two directions
A byte contains eight bits. For the value 0xFA, the usual written binary form is 11111010. Most-significant bit first, or MSB first, sends that sequence from left to right. Least-significant bit first, or LSB first, sends 01011111 instead. The value you intended to communicate has not changed; the agreed transmission order has.
If an analyzer interprets the second sequence as MSB first, it displays 0x5F. That does not mean the application asked to send 0x5F. The decoding settings are part of the observation. Keep them in the capture record, alongside the transmitted value and the receiver's required order.
MicroPython's SPI classes expose this as a firstbit setting. Explanations of it sometimes use "big-endian" and "little-endian" loosely, but bit order inside one byte is different from the order of several bytes in a larger value. Changing one should not be assumed to change the other.
Separate bit order from byte order
Suppose the device expects the two-byte value 0x1234. Its protocol may require byte 0x12 followed by byte 0x34, or the reverse. Within each byte, it also defines which bit arrives first. Writing the buffer in reverse order swaps whole bytes; it does not reverse the eight bits within each byte.
For the buffer [0x12, 0x34], reversing the byte order produces [0x34, 0x12], while reversing the bits within each byte produces [0x48, 0x2C]. Neither is automatically the right fix for a display command, and neither example is a command to send to an attached device; use the device's actual command format to decide.
The same care applies to names in a graphics library. A color order such as RGB or GRB describes how color components are arranged, which is another layer again. If a screen shows the wrong colors, establish which layer is wrong before changing several options at once.
A common API does not promise identical hardware support
The MicroPython 1.29.0 SPI reference documents both SPI.MSB and SPI.LSB, and distinguishes hardware SPI from SoftSPI, which generates the signals in software. Keep that distinction in mind when reading example code: a constructor that says machine.SPI and one that says SoftSPI may not accept the same options.
For example, the RP2 hardware-SPI implementation in MicroPython 1.29.0 explicitly raises NotImplementedError for an LSB-first request. That is a versioned implementation fact, not a reason to conclude that no RP2040 or RP2350 application can talk to an LSB-first device. A different driver or software implementation can make different choices.
In the Bus Pirate case, the maintainer applied a software bit-reversal function, and the user then confirmed the update. That fix belongs to that tool's firmware; it does not change what MicroPython's hardware-SPI class implements. Do not copy a workaround between software stacks without checking where the conversion already happens. Reversing the data twice undoes the intended change.
Make the next test small enough to understand
Start with a short pattern whose bit order is easy to distinguish. For an isolated interface check, 0xFA is more revealing than all zeros or all ones, which look the same when reversed. With a real device attached, choose a documented, appropriate transaction; an arbitrary test byte may itself be interpreted as a command.
Write down the expected first-to-last bits before capturing the transfer. Check the clock, sampling edge, word length and selection signal as well as bit order. A shifted or unexpected value is a reason to investigate these settings, not proof of a particular fault. The analyzer should decode according to the receiver's requirements, rather than whichever setting makes its displayed number look familiar.
If the chosen implementation cannot provide the required order directly, compare a suitable software driver, a deliberate data conversion or a custom interface implementation, and evaluate the resulting transfer on the actual workload. We have not measured those alternatives against each other for this note.
Keep the fix with the prototype
Once a documented command works, repeat the product interaction that failed at first. Save the firmware version, driver configuration, expected command and a representative capture together. If the prototype later moves to another board or another engineer's computer, those details make the working behavior reproducible.
This is especially useful for a design or education team using an unusual display module: the handover can say what was sent and what the device did, instead of only "SPI enabled." The forum report reached a confirmed resolution because both sides could compare a specific pattern and a specific software version.