There are lots of WiflyInterface libraries. The WiflyInterface library here should support all the additions and changes of each within reason such that the API allows the program to make use of the the library rather relying on a fork of it with the feature.

Is anyone with a wifly module interested in contributing to this work and testing?

These are what I found doing a simple search

• https://mbed.org/teams/mbed-official/code/WiflyInterface/
• https://mbed.org/users/WiredHome/code/WiflyInterface/
• https://mbed.org/users/screamer/code/WiflyInterface/
• https://mbed.org/users/ddollar/code/WiflyInterface/
• https://mbed.org/users/lz307/code/WiflyInterface/
• https://mbed.org/users/yihui/code/WiflyInterface/
• https://mbed.org/users/zouloum/code/WiflyInterface/
• https://mbed.org/users/leihen/code/WiflyInterface/
• https://mbed.org/users/samux/code/WiflyInterface/
• https://mbed.org/users/sherckuith/code/WiflyInterface/

If you cannot post a reply here try to enable betamode

I think it would be a good idea to try and merge the WiflyInterface libs. It would be even better to start with the WiFly lib itself. The issue here is that Wifly uses hardcoded TX, RX pins. This is not compliant with the Sparkfun WiFly shield that uses a SPI-to-UART bridge between the shield pins and the module. That could be solved by a base class for the Wifly module and derived classes for either direct Serial port or SPI-UART bridge interfaces. The WiflyInterface in turn would be derived from those classes. Note that I have done a lib for the SC16IS750 I2C or SPI to UART bridge. See here for more info.

When compiling the WiFlyInterface library, I came across a couple compiler errors:

1. For the WiFly constructor, security mode WPA2_PSK is not supported. I require this mode at my location. I have a patched (I don't know who's code it was) WiFly.cpp and .h to include this mode.

/media/uploads/loopsva/wifly.zip

Note: the above link is not the correct wifly.zip with my patches. For some reason, I cannot I upload the correct version. Some other version is there and I cannot get rid of it. Contact me in person if you want a copy of this WPA2 wifly.zip patch.

2. Function "baud" is missing. e.g. wifly.baud(230400). Maybe this is no longer required. David Smart was using this function and I copied it.

3. Functions "getWiFlyVersion" and "getWiFlyVersionString" are missing.

...kevin

I was away, so didn't notice this thread until now.

Versions Compared

I just compared every variation that Sam Grove listed (above), looking [quickly] at the history of each, where they branched from, and if I could find relevant differences to carry forward. Admittedly, this was a pretty fast scan, but here's what I think I discovered:

What I Recommend

1. Adopt the latest from wiredhome - ideally with widespread testing to avoid the possibility of a major regression issue.
   But admittedly, I may not be impartial on this one, so invite critical review by others.
2. zouloum had a change of all wait() to Thread::wait(). This seems reasonable if there's no problem with backward compatibility.
3. zouloum's "set l r 0\r" in setProtocol(UDP) may have value, but I cannot find rationale for this change in the Wifly user manual 1.2r4.
4. leihen has a few changes - those specific to leveraging the built-in Network Time Protocol. I like the idea of leveraging what is already built-in to Wifly modules, and yet it is then not compatible with EthernetInterface. I didn't study that implementation in detail, but my initial thought is to leave that out.
5. Wim has a concept that permits communicating through a SPI interface to the Wifly module. If it does not compromise compatibility with EthernetInterface (and I don't think it should), then this could be pursued.
6. WiflyInterface and EthernetInterface should get to coexist in one binary. I'd like to be able to create an app that can use either of these - based purely on runtime.

Hi there, I have recently discovered a small postage stamp sized SoC module that has a very simple programing interface using AT commands, this provides ALL overhead management of network transactions, setting up an Access Point, joining an access point Creating AND joining access points simultaneously, MAC preprogramed DHCP Client AND DHCP Server....etc..

You setup the webserver, either udp or tcp, create your html, pull some .js from somewhere etc report back via the RS232 TTL serial, the module is an SoC as I said and also contains a host of peripherals ADC, PWM, interrupts etc....

http://www.banggood.com/ESP8266-Remote-Serial-Port-WIFI-Transceiver-Wireless-Module-p-947259.html

This is the cheapest I have managed to find it £2.02 per, I have already diverged from the SAM3X8E Arduino project down the rabbit hole.... and created a distraction for myself....

https://github.com/genguskahn/ESP8266-For-DUMMIES

This would allow for very frugal use of on-board resources by outsourcing ALL Ethernet and receive commands/results from the RS232.....

Most of the documentation is still in Chinese, I have a very detailed Chinese version that the basics can be translated from, if you know someone fluent in the particular dialect I can post it, got it after an email exchange with the tech guys from China.

There are a number of GitHubs and Forums already dedicated to the device.

I have used it with the three main types of Arduino(sorry newbie here was just referred, still speaking bad language), as that's been my flavour a for a while I have only had the little thing working since Monday and already stunned RF24 Arduino with 8266 bridge to three Arduino mini (328P 5v) light controllers UDP booom all from one webpage, RF24 buggy but concept works....

Hi Peter, there is some mbed work going on for the ESP8266 see here