Blake Ramsdell

I'm having some trouble with a 4.1.1.0 a5 Netduino Plus using SPI (MISO data is always 0xFF), and maybe it will help if I understand more about "variable-bit SPI" and the changes in the SPI area.

Based on my somewhat moron non-hardware-guy understanding of SPI from Wikipedia, it's basically just a continuous bitstream -- you drive SS low, you start SCLK, and then data is latched on MISO and MOSI, one bit each direction per tick of SCLK.

Now, the current NETMF abstraction for SPI provides several functions. In my case, I'm transmitting a byte, and then I want to receive a byte in return from my SPI slave device. So I do:

var statusBuffer = new byte[2];
statusBuffer[0] = 0xD7;
spi.WriteRead(statusBuffer, statusBuffer);

In the failure case, we are seeing MISO stuck at 0xFF. That is, statusBuffer[1] always equals 0xFF. It's supposed to be something different (specifically 0x8C).

So maybe if I understand more about "variable-bit SPI" it will help me diagnose this. I note from the provided ExtendedSpiConfiguration that the default value for BitsPerTransfer is 16. I am currently using a a regular SPI.Configuration, so I presume that I'm using 16 as BitsPerTransfer (the default).

So is a "transfer" defined as "the time between driving SS low and driving SS high"? If it is, then I may have some serious problems, because my transfers vary in length. I send various commands to the SPI slave device, and some commands are basically just the command byte, with a one byte response. Some commands have more structure (a command byte, three address bytes, 264 bytes of data), etc. So some transactions are one byte + one byte response, some transactions are 268 bytes + no response.

FYI, the device I'm talking to is a Xilinx XC3S50AN and the SPI documentation is here. The 0xD7 command is "Status Register Read". But I'm not sure understanding this is really needed.

My SPI code works fine on a Netduino Plus with older firmware and the 48KB RAM setup:

SolutionReleaseInfo.solutionVendorInfo: Netduino Plus (v4.1.0.5 b2) by Secret Labs LLC

I'm working with multiple NETMF platforms (Netduino and FEZ) and I note some slight variations when it comes to hardware resources. It looks like both platforms define slightly different mappings for the Cpu.Pin as well as the SPI devices.

I'm mulling what to do about the digital input mappings, but for the SPI devices, can I just use SPI.SPI_module.SPI1 instead of the Netduino version? They're the same value (0).