Arduino shield compatible SPI

NETMF & Gadgeteer
1

So I am trying to access an Arduino shield via SPI (Arduino digital pins 11-13). On the Domino these pins (in the same header location) are marked as SPI1/11/12/13.

When I instantiate my SPI.Configuration I am passing the following value in as the last parameter (SPI_module):
Microsoft.SPOT.Hardware.SPI.SPI_module.SPI1

Will this map the SPI MOSI/MISO/SCK to the SPI1/11/12/13 pins on the Domino?
SPI1/11 - MOSI
SPI1/12 - MISO
SPI1/13 - SCK

Thanks!
Greg

2

Have you seen this? http://www.tinyclr.com/downloads/Domino/Broch_FEZ_Domino.pdf

This tells you exactly where every pin is. They are also marked on FEZ Domino so they are easy to find. Look at the board one more time please :wink:

Also, there are many many example drivers fro all kind of components/shields so we may already have your shield driver online. Have you checked?
For example, the WiFly driver already uses those PSI pins you need so you can just cope the code from there.

3

Thanks! Yeah, I have looked at a couple bits of FEZ SPI sample code; mainly what I was wondering is if “Microsoft.SPOT.Hardware.SPI.SPI_module.SPI1” correctly mapped to the pins that I think it should (SPI1/11/12/13) on the Domino. The samples seem to indicate so.

Will keep on poking…
Greg

4

Got it working! Reading the dev id data via SPI seems to be working - at least I am getting back valid looking data. Interesting thing is that I am expecting 4 bytes return data but am getting 5. The first is always set to 255 but the following bytes match what I should be getting back!

Its nice to have a little success now and then :wink:

Thanks!
Greg

5

I have just thought of something, are you using SPI.WriteRead? If so then your first byte in read will be the returned byte of the command you have sent? The way SPI works, it swaps bytes between the master and slave.
So, if you are sending a byte and reading 4 bytes then you will receive 5 bytes because sending the first byte must return a byte…did I help or I got your more confused?

6

That was the issue! Using SPI.WriteRead() which takes a third param - number of bytes in original cmd - fixed it up for me. I’m used to playing at a lower level with SPI :wink:

Thanks!
Greg