@ Bauland - After looking at the datasheet for the nRF8001, their use of the “chip select” does have a dual purpose which is a request a transaction and wait for the “RDYN” from the nRF8001 to indicate it is ready for a SPI transfer to begin. This is not a typical SPI bus transaction, hence your request to share a GPIO line with the SPI chip select seemed odd to me.
In looking at the Trr timing (page 26) there is no max. time giving to wait to the “RDYN” signal to indicate that the nRF8001 is ready. Note 1, does say this will take up to the time of a “radio event” plus the typical response time. I could not find any timing for “radio event” so this maximum time to wait is unknown to me. It may exist in the Bluetooth protocol how ever.
I was going to suggest that .NETMF typically sets the SPI chip select active well in advance of the data transfer, but with out knowing what the maximum time to expect before the nRF8001 will respond with “RDYN” this would not be reliable.
The one solution I can see is to build you own SPI bus protocol in software accounting for the “RDYN” pin. Yes would be quite slow.
Another solution would be to select an unused GPIO pin for the nRF8001 chip select line in the SPI.Confifguration (or possibly your code of GPIO_NONE may work), the before starting a SPI bus transaction, have a software bring “REQN” active (low) and then have the software poll for the “RDYN” signal to go active (low) then call the _spi.WriteRead method. There would be some extra delay, as the .NETMF time to assert the fake chip select is kind of wasted, but likely faster then the software SPI solution.
P.S. This was kind of inline with my original post concerns that the SPI chip select can cause the SPI device to change state, at least the vendor described the behavior in your case.