Team dedicated to component libraries on developer.mbed.org

Super WiflyInterface Library

10 Apr 2014
11 Apr 2014

If you cannot post a reply here try to enable betamode

11 Apr 2014

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.

11 Apr 2014

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

27 Apr 2014

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:

UserVersionDerived fromKey Difference
wiredhome68:d9a3920cc4074:0bcec6272784Many improvements - but I might not be impartial enough.
Security, baud rate, reduced memory allocation, getWiflyVersion*, RawSerial, non-blocking, and more... The update today lists the changes in each of the header files.
screamer6:5176e08640785:81e264dbbf03Nothing unique identified
ddollar5:5c9c3fdd67fb2:8e54830d0df7Nothing unique identified
lz3077:3152fcc743901:fb4494783863Nothing unique identified
yihui5:26ae56c7cb3d1:fb4494783863Nothing unique identified
zouloum10:dd993a4bf2bf1:fb4494783863"set I r 0\r" in setProtocol(UDP), changed all wait() to Thread::wait()
leihen12:4f95e6a365db4:0bcec6272784Added baudrate, Added Wifly module specific enableTime() NTP and RTC and getTime(), Revised several APIs to be virtual, revised exit() method.
samux13:108340829accnot "derived"older version of the same content as mbed official
sherckuith11:002225507f448:9a3cd07ed7e8Numerous changes, nothing unique identified

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.
29 Jan 2015

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....

29 Jan 2015

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