Main Site Documentation

Yet another WiFi on Panda Question


#1

I have tried to find and follow through the various WiFi related discussions on the forum, in the tutotials and in the ebook. I understand having the network stack in a module as opposed to resident in the Panda.

For Ethernet, GHIElectronics.NETMF.W5100 provides a wrapper that provides an interface similar to the .NET sockets interface and hides the details of the interface to the ethernet module.

I have looked at the Connect Shield and WiFi bridge approach but that seems to be bulky and a bit of a kludge. I was hoping for something a little more elegent. :wink:

So for WiFi I am looking at either the new XBEE WiFi module (I currently have XBEE in various projects and so it would be easy to swap hardware) or either the WiFly Shield or new XBEE footprint module from Sparkfun.

So my question: Am I correct in my understanding that there is no wrapper similar to that provided by GHI for ethernet and so I will need to understand and implement the interface to whichever module I decide to use?

I conducted a search of all the usual places where I find code that I can use. I did not find anything. Does anyone know of anything that I failed to find?

Thanks.


#2

Correct, no wrapper from GHI but those modules are simpler than W5100. There is no “socket” on these modules. It is as simple as a serial-port-connection-over-wifi. In other words, there is no wrapper to write.


#3

Not sure what your ‘usual places’ are and don’t know what you found for code, so it’s a hard question to answer :wink:

If you mean code for the Xbee WiFi, it’s identical to the code for a regular Xbee: just a serial connection. Obviously, you have to configure your Xbees first, which can be done using Digi’s X-CTU tool or with AT commands via a terminal app.


#4

In transparent mode, the XBEE provides just a serial port interface and as you say can be used without a wrapper.

The XBEE WiFi module can also be used in API mode where communications to it are packetized. The main advantage is that it can support multiple sockets. So in this case it is not just a serial port replacement and a wrapper would be useful.

Actually, even in the transparent case a wrapper would be useful so that the application code could be written to a consistent socket interface and then used over both ethernet and wifi with changes only to the socket creation call. Also I have some things that I do on Panda and some on Chipworks so in this case a consistent interface would be useful as well as I share much of the applications code.

In any case, I got my answer: You guys who are much more linked in with NETMF don’t know of any support for these other than as a simple serial ports.

Thanks for the prompt reply.


#5

@ Duncan -

There’s some interest in abstracting the Xbee commands to a NETMF class. See this thread http://www.tinyclr.com/forum/21/4868/#/1/msg46135

It would be great to collaborate on a wrapper by starting with interface and/or base class designs. As noted in the other thread, there is an existing project on codeplex with the beginnings of this (that was news to me). After we’ve all agreed on the design, we can each come up with concrete implementations based on the different protocols.

Interested?


#6

@ ransomhall

Definitely could be interested. As always in these things, time is the constraint.

I agree with the comment in the other thread about considering using API mode rather than AT, even if this makes it XBEE specific. I currently use my XBEEs in the simple transparent mode. I am in the (very slow time constrained) processes of learning the API so that I can use it in API mode (host PC to multiple NETMF devices) and ultimately also using Zigbee (one of my applications is lighting control automation). Might drop them all if I could get a good WiFi implementation instead.

Seems to me that the process should be something like:
[ol]
Define general approach. I favour a common interface built on standard NETMF socket interface
Define the interface.
Architect and build the basic class hierarchy
Add specific subclasses for various devices and modes (simple serial, XBEE API, AT command, Zigbee, WiFly, …) as somebody wants each enough to do the work.[/ol]

Duncan