WiFiRS9110(SPI.SPI_module.SPI2, (Cpu.Pin)37, (Cpu.Pin)32, (Cpu.Pin)7, 24000)?

I’ve found a sample that exercises my WiFi RS21 board and it works well and has allowed me to gain some insights.

However the sample code uses the constructor described in the post’s title.

What exactly does that mean? how would I work that out myself if I’d had no example source - just my Raptor my RS21 and the documentation?

At the highest level the RS21 module is plugged into the socket 1 of the Raptor.

Could one have varied any of those constructor arguments? are those specific arguments particular to the Raptor? would some other mainboard have to use different pins etc?

Thanks

The constructor is passing firstly the SPI module in use, then several pins to use for other functions. If you use intellisense and hover over the constructor you’ll see details of what the parameters mean (like reset and CS lines etc).

You then need to map that back to physical pins. There are many ways to do that going from hardware to Gadgeteer, but in most cases you don’t need to if you use the Gadgeteer driver. What are you actually wanting to do ?

BTW can you put the constructor into the text of a message, the title isn’t copyable in the reply page.

@ KorporalKernel -
the code you used is for the “plain NETMF way”. For new applications the GHI.Pins Namespace should be used: For raptor and Socket 1 the constructor is::
netif = new WiFiRS9110(Microsoft.SPOT.Hardware.SPI.SPI_module.SPI2, GHI.Pins.FEZRaptor.Socket1.Pin6
, GHI.Pins.FEZRaptor.Socket1.Pin3, GHI.Pins.FEZRaptor.Socket1.Pin4, 24000);
As Brett already mentioned it is often easier to go the Gadgeteer way (add the module with the designer and use the generated wifiRS21 instance)

Thanks both of you.

First, i tried using the wifirs21 generated by the designer, then found the doc for that module is marked obsolete, this caused confusion as im green with GHI and .netvMF. My question is really “how did you know what args to pass in the constructor above?”.

Clearly they’re a function of board type and socket number, but how did you obtain these values?

Given the documentation published, how could I work out those constructor arg values myself?

If these values came from GHI engineers because they have internal knowledge, then fine but in that case this should be systematically documented/explained.

PS - this explains my earlier confusion: https://www.ghielectronics.com/community/forum/topic?id=20118

If you haven’t seen it already, one thing you really must be aware of when trying to work with Gadgeteer at the pins level is the socket standard. Using this table, you will know which pin of certain socket types match to the SPI pin arguments passed to the constructor.

https://www.ghielectronics.com/docs/305/gadgeteer-sockets-quick-reference

Certainly helpful to review that, I have seen it but glossed over it.

Here’s the constructor again:



I read the G400-S doc by GHI and in their they advise to use SPI2 - OK so that's fine.

Several points are still far from clear:

1. The Cpu pin enum is platform neutral, not sure what purpose it ultimately servers given actual platform distinctions.
2. Clearly the pins referred to here are literal 37, 32 and 7 - are these the physical pin numbers on the G400-S ?
3. There's the GHI.Pins.G400 - which frankly is THE one to use in all G400 examples in my opinion...
4. Looking at GHI.Pins, we see 37 -> PB5, 32 -> PB0 and 7 -> PA7 - none of these labels match what's defined in the G400 chip spec though..

There are three SPI sockets on the Raptor so I guess I could connect the RS21 to any of these. Then I'd expect to alter the above pin numbers, but how?

Is there a table that maps socket number and socket pin number to chip pin number? Is that's what's missing here?

...tick tock tick tock..

Ahh I see there is: http://www.ghielectronics.com/downloads/schematic/FEZ_Raptor_Mainboard_SCH.pdf

Now I see, now its beginning to make sense - one requires a knowledge of the socket to CPU pin mappings.

.....

I’m beginning to see now. The three pins in the constructor are not directly SPI pins, the driver (I presume) defines these itself and we never need to specify them - it “knows” its a Socket S anyway.

The three pins are for selecting the device/module, interrupting the CPU and resetting the device/module - I wasn’t clear on this earlier.

One question now seems to remain, Socket S clearly defines pin 6 as device select, but pins 3 and 4 for Socket S are defined as GPIO, not specifically associated with SPI functions. So how do we know that pins 3 and 4 serve this role…ahh I see the socket layout for the RS21…

OK I’m finally getting it…

@ KorporalKernel - Sorry, I’ve been away most of the day. So, is there still an outstanding question or have you figured it all out? Sounds like you have.