David Smart / WiflyInterface Featured

MODIFIED from mbed official WiflyInterface (interface for Roving Networks Wifly modules). Numerous performance and reliability improvements (see the detailed documentation). Also, tracking changes in mbed official version to retain functional parity.

Dependents:   Smart-WiFly-WebServer PUB_WiflyInterface_Demo

Fork of WiflyInterface by mbed official

Resources

• SmartBoard - Wifly is a small adapter I created to plug in (another) adapter to my baseboard.
• SmartBoard - Baseboard is a baseboard I designed for a variety of small projects.
• Cookbook - WiflyInterface, especially the "More Details" section.
• Components - WiFly
• Search - WiflyInterface

Derivative from mbed Official

• Documentation update, improved consistency, documented parameters that were inadvertently omitted.
• Avoid c++ string handling, which causes dynamic allocation and free, side effect, fewer CPU cycles spent for same purpose.
• Fixed socket APIs to support non-blocking mode.
• Increase communication baud-rate to Wifly module
• sendCommand - added retries for improved robustness.
• setConnectionState - method to force the connection state (used by TCPSocketServer)
• gethostbyname - added a length parameter to the size of the buffer being written
• flushIn - a private method to flush the input buffer
• Changed the timeout from 500 to 2500 msec for commands - measured some at 700 to 850 msec.
• Performance improvements - reduced some unnecessary delays.
• Added additional security options for the wi-fi connection (that are supported by the WiFly module).
• Added setSecurity API which permits revising the security when connecting to, or selecting from, one of several access points.
• Improved DEBUG interface (slightly more consistent printout).
• gathers information from the Wifly module on reboot (SW version info), which permits customizing behavior based on Wifly capabilities (like the improved security).
• Avoid potential for recursive crash (if exit fails, it calls sendcommand, which calls exit...)
• Update to support permissible SSID and PassCode lengths.

Robustness testing

I've had some mixed behavior with the Wifly module, some of which seems to be traceable to the module itself, and some in my derivative code. The result, after running for minutes, hours, sometimes days, it hangs and I have to reset the module.

To test, I created a fairly simple test program -

• check for Watchdog induced reset and count it.
• initialize the Watchdog for 60 sec timeout.
• Init the Wifly interface and connect to my network.
• Wait 10 seconds and force mbed_reset().

If the Watchdog induces the restart, then it is pretty clear that either:

• The communications hung with the Wifly module causing the failure.
• The Wifly module decided to go unresponsive.

If it gets to the end, it typically takes about 4 to 6 seconds for the boot and connect, then the 10 second delay.

But I can't really pin down the root cause easily. My strongest theory is that the Wifly module has rebooted, and since I don't store the high baud rate I configure it for, it resets back to 9600.

Also, one of the objectives for my revised send( ) is to avoid the c++ string, as that can fragment memory, and it wasn't very well bounded in behavior.

Latest tests:

I think with these numbers, +/- 1 means that the changes have had no measurable effect. Which is good, since this incremental change eliminates the c++ string handling.

Test Software

This is pieces of a test program, clipped and copied to here. What I have compiled and run for hours and hours is almost exactly what you see. This uses this simple Watchdog library.

#include "mbed.h"
#include "WiflyInterface.h"
#include "Watchdog.h"

Serial pc(USBTX, USBRX);

Watchdog wd;
extern "C" void mbed_reset();

// Pinout for SmartBoard
WiflyInterface wifly(p9, p10, p30, p29, "ssid", "pass", WPA);

int main() {
    pc.baud(460800);                         // I like a snappy terminal
    
    wd.Configure(60.0);                     // Set time limit for the test to 1 minute
    LPC_RTC->GPREG0++;                      // Count boots here
    if (wd.WatchdogCausedReset()) {
        LPC_RTC->GPREG1++;                  // Count Watchdog events here
        pc.printf("\r\n\r\nWatchdog event.\r\n");
    }
    pc.printf("\r\nWifly Test: %d boots, %d watchdogs. %s %s\r\n", LPC_RTC->GPREG0, LPC_RTC->GPREG1, __DATE__, __TIME__);
    
    wifly.init(); // use DHCP
    pc.printf("Connect...  ");
    while (!wifly.connect());               // join the network
    pc.printf("Address is %s.  ", wifly.getIPAddress());
    pc.printf("Disconnect...  ");
    wifly.disconnect();
    pc.printf("OK. Reset in 10 sec...\r\n");
    wait(10);
    if (pc.readable()) {
        if (pc.getc() == 'r') {             // secret 'r'eset of the counters
            LPC_RTC->GPREG0 = 0;
            LPC_RTC->GPREG1 = 0;
            pc.printf("counters reset\r\n");
        }
    }
    mbed_reset();                           // reset here indicates successful communication
}

Major change is in how to checks for expected response. Prior code used the C++ string method of concatenation, which could continue to allocate memory to exhaustion, even if it was only interested in a few character response.