drivers: spi: RPi Pico PIO SPI code size and byte order.

[ThreeEights]

Use minimized PIO code for 3-wire operation.

Input and output buffers are conventionally stored in bus byte order. For 16 and 32 bit transfers, this is effectively big-endian, so txbuf and rxbuf need to be read as such. Those pointers also need to be declared uint8_t * instead of void *.
In addition, tx_count and rx_count are based on dts, and refer to whole transfers (8, 16, or 32 bits), not bytes.

Added rpi_pico.overlay to samples/sensor/magn_polling to demonstrate 32-bit word size, and updated the README.rst to make it independent of the specific sensor.

Fixes #72954

[ThreeEights]

Drat and darn: Testing revealed a timing issue in 3-wire/SIO mode. Previously, the TX logic could count on PIO instruction address being at the stalled pull instruction after the FIFO is empty, but that's not true with the refactored PIO code. Due to the asynchronous nature of the PIO vs the CPU clocks, the test would sometimes fail and the RX logic would reset the state machine before the TX had completed. The fix is to wait until the TX FIFO is empty, then sleep the number of clock ticks necessary to shift out all the data before starting the RX stage.

[ThreeEights]

@yonsch @soburi - When you have a chance, could you take a look at this pull request? I'd like to ferret out any issues as soon as we can.

[ThreeEights]

This fix is also needed for the next maintenance release of 3.7.

[MaureenHelm]

Sensor changes are ok, but would like @yonsch to review the RPi SPI driver changes.

[ThreeEights]

@yonsch - Do you have any further comments on this pull request?

[soburi]

@yonsch
ping

[MaureenHelm]

@MaureenHelm @yonsch - This also needs the backport v3.6-branch label. (Am I allowed to add labels?)

Added.

[ThreeEights]

@yonsch - Please take a look when you get a chance and see if the changes to drivers/spi/spi_rpi_pico_pio.c meet your approval. I took another look at the problem and redid the wait loop between the send and receive in 3-wire mode.
For those trying to follow along: The issue is that the CPU has no way of knowing when the PIO's state machine has finished clocking out the sent data. Since the SPI clock is typically running at a slower speed than the CPU (and thus PIO) clocks, some delay is needed to prevent the CPU from disabling the state machine (in order to switch to receive state) before the SPI clock is finished. My solution was to include a delay of approximately one SPI clock cycle, to allow the state machine to complete before being reset.

[ThreeEights]

@MaureenHelm @soburi - I had to rebase my changes onto the tip of the main branch for the mainline code. There's one update to samples/sensor/magn_polling/README.rst to fix a merge conflict, and the redone synchronization loop in drivers/spi/spi_rpi_pico_pio.c. Can you please review my changes when you have an opportunity?

[ThreeEights]

@yonsch - Have you had a chance to look at this again?

[ajf58]

LGTM.

Whilst a concern has been raised about the use of k_sleep, I'd prefer to have correctly working (but perhaps not optimal) code in main, rather than keeping the status quo of main having a known bug in it. The PR serves as a record of this discussion, and someone could raise a new issue against the use of k_sleep, if required.

[soburi]

Sorry for the late response.
I was busy preparing to speak at the open-source summit in Japan.

LGTM