I've written a script to communicate with MicroChip PICs using SPI. The script worked fine on a PyBoard and ESP32 with several PIC types. But the same script fails with an RP2040 Pico.
A readinto(buf3) always returns \x00\x00\x00 (buf3 is a bytearray(3)), while something different is expected.
After some trial and error I got the script working by specifying readinto(buf3, 0xFF). So the problem looks solved.
But unfortunately when using '0xFF' with PyBoard and ESP32 the script fails on these platforms.
I wonder why 0xFF is needed with the RP2 Pico, but why PyBoard and ESP32 apparently require the default (0x00).
An explication would be appreciated (a fix for the RP2 might be more appropriate).

My apologies: wiring error! Brief explanation:
The communications with the PIC is half duplex and on the side of the PIC I use one Pin (PGD in the picture below) for input and output. Therefore I use the following wiring 'trick':

But even after check and recheck I overlooked a wrong connection. It was pure coincidence that it worked by specifying readinto(buf3, 0xFF). After fixing the wiring a readinto(buf3) is OK. SPI of the RP2 works like with PyBoard and ESP32.

That's indeed strange because the implementation of spi.readinto() itself is not port-specific. It calls however a port specific transfer function. May it be that other parameters have to be aligned like phase or polarity, and the difference between the ports is some subtle timing, which may differ? Does SoftSPI have different as well?

This is indeed very odd. Just to clarify what @robert-hh is saying, the only place that second argument is used is to memset the buffer. It is not passed into the port-specific code.

Do you have a logic analyser and can see what's going on?

Does your PIC code care about the bits that are written during the write? (i.e. what does the PIC code expect to be transmitted on the controller's SDO during the read?)

My apologies: wiring error! Brief explanation:
The communications with the PIC is half duplex and on the side of the PIC I use one Pin (PGD in the picture below) for input and output. Therefore I use the following wiring 'trick':

But even after check and recheck I overlooked a wrong connection. It was pure coincidence that it worked by specifying readinto(buf3, 0xFF). After fixing the wiring a readinto(buf3) is OK. SPI of the RP2 works like with PyBoard and ESP32.