SPI with CS set to Cpu.Pin.GPIO_NONE

I am perplexed, I set the SPI with the CS to none in order to move it on my will but then do not read properly … why?

@ coccoliso - Does your device work if you specify the GPIO pin as part of the SPI Configuration?

is an FTDI FT800 LCD and works perfectly with CS set by SPI as initializing and correct display of widgets but this (and other same) chip for transfer an image in a massive way (32K) requires that the CS is held low for all his writing.
I’m quite depressed by this.
I wrote a low-level routines (bit-bang) directly in .NET but to move all content from SD this manner takes more than 10 seconds …a catastrophe . :’(
I understand this is not a “standard way” to operate with SPI but this thing also happens in other cases where is needed a more flexible protocol.

@ coccoliso - CS none and CS low are very different.

@ coccoliso - I assume you are using a GPIO pin to drive CS low before you use the SPI.WriteRead, or SPI.Write commands, and drive CS high after. Or are you bit banging the whole SPI bus transaction?

bit-banging .NET routine is an attempt to bypass the limitation but it is impractical for the loss of performance.
with SPI I set down the CS output before communication to then put it up at the end.
This mode frequently occur with industrial chips … massive transfers are made in this way and the limitation worries me.

@ coccoliso - I assume you by limitation you mean the SPI bus CS signal on the NETMF platform. I don’t think this should be a a concern. The CS line only goes to the FT800 so that meets this chips requirement.

Does that describe your concern?

What transfer times do you get when you manage the CS line, and use the SPI interface for the transfer?

FT800 has a 4096 bytes partitioning so now try to rewrite the source piece for loading BMP and let you know if it works.