11 years, 5 months ago.

Has anyone succeeded in making a Wifly HTTP server?

Hi Folks,

I'm trying to assemble an HTTP server using a Roving Networks Wifly module. I can successfully compile and run the HTTPServerExample in the cookbook, using ethernet, including the RPC protocol. And I can successfully compile and run the WiflyHelloWorld example, join my wifi network, and telnet to the Wifly module via wifi. However, if I import the official mbed Wifly interface into the HTTPServerExample, the compiler reports many "TCPSocket" is undefined and "TCPSocketEvernt" is undefined errors arising from the HTTPRequestHandler and TTPRequestDispatcher. These are deep in the HTTPServer library. If I delete the EthernetNetIF library and the #include "EthernetNetIf.h" statement (still keeping the WiflyInterface library and calling it with #include "WiflyInterface.h") then the compiler gives a different error: "cannot open source input file "core/net.h": No such file or directory. This one is also from the HTTP Server library.

Has anyone succeeded in combining the HTTP Server Library with the Wifly Library? Or is there a different way to implement an HTTP server over the Wifly interface?



Question relating to:

Hi Yale, I've been waiting to see if you get any responses to this question, as I have been wondering about this very thing for some time. The Http server capability is very good, but to be tied down by a wire seems a bit in the past. Even if there are no current answers, it would be nice to know if there is some work going on in this area, or if it can be done at all with the wifly the way it is designed. Thanks for asking. Let me know if you figure it out.


posted by Laurie James 21 Feb 2013

3 Answers

11 years, 1 month ago.

I would say I have succeeded in this - SmartBoard WiFly is where I've documented my work. There is a lot more that could be done, and over time I'll implement some improvements. This page has a schematic for how I interfaced it, pictures of a PCB, and near the bottom is a link to my sample program.

Accepted Answer

Hi David, Thanks for this. It's what I was looking for. I was able to get it to work on a LP1768 and a KL25z, although both baud rates had to be slowed down (115200) on the KL. I used Sparkfun level shifters for the LP and an additional 3.3V power regulator for the KL because its 3V output didn't supply enough current to the Wifly. KL is thin in free memory (Free() reports about 2500 bytes free and it can crash for a long URL). Otherwise they are both pretty stable, but intermittently for some browsers (FF, Chrome, Android) the close-connection routine will fail, possibly due to a keep-alive directive from the browser. I was able to improve that some by monitoring GPIO6 (follows Wifly's red led), but it's not perfect. Any ideas? I can give you more details off line if that would be useful. Please post any new features or if you are able to make Poll() non-blocking. Thanks again for filling this important gap in the available MBED software.


posted by Yale E. Goldman 17 Jun 2013

Hi Yale. Hopefully, you browsed the source and saw the long todo list. I need to add a new item to it - when a web page has additional items on the page (e.g. img src=...) it rarely will serve the image. It seems the follow-up request for the image is usually not even seen. At the moment, I have been running it in a Connection: Close model, and forcing the connection to close is quite expensive. It requires sending the $$$ which has to be surrounded with 0.25s of delay. I'm not sure I can trace to this as the issue, but seems suspicious. In any case, I encourage feedback - including proposals to revise the code.

posted by David Smart 17 Jun 2013

Hi David,

Thanks for your note. I’ve made many, many small modifications to your software to make it more robust in my application. Besides changing the contents of the dynamic web pages for my specific application, the main ones have been to force closure when the program as you posted it would maintain a connection too long (detected by monitoring the wifly GPIO6 hardware terminal). A different problem I’m having is to upload a file to the MBED server. It’s almost working but it drops characters consistently after a number of bytes. My guess is it’s related to TC/IP flow control between the browser and the server. Your SendFile() routine works very reliably and I’m guessing it implements such flow control but I don’t understand it well enough. I tried this

bPtr = buffer; n = client.receive(bPtr, sizeof(buffer));

The file being uploaded is smaller than MAXRECSIZE. It drops a few characters after 500 bytes received, resumes, drops chars again.... The following code works better, but still isn't reliable

while (wifly->readable()) { c = wifly->getc(); if ((bPtr - buffer) < MAXRECSIZE-1) *bPtr++ = c; pc->putc(c); }

Do you have an idea what could be causing the characters to be missed or have you added upload capability to your latest version? If you're interested I can send you my files directly but they are way too kludgey for me to post them to the site and expose my poor programming knowledge and habits.

Thanks again for your efforts.


posted by Yale E. Goldman 08 Jul 2013

Hi Yale, I continue to make changes as well - not all in the right direction (so I call those "experiments"). Since the interface from the mbed to the Wifly does not use hardware flow control, the limiting factors are mostly the uart baudrate, and the speed of the local file system. That is likely why the SendFile works well. I think the mbed supports HW flow control, but the pins are not brought out (in some project I saw a tacked on wire but didn't want to go that route).

File upload is on my list, but I haven't done anything. If you're partway there I'm very interested in your work, and the other enhancements you've made. Feel free to post them as pull requests, or we could arrange a side-channel email to zip and ship. I look forward to your updates! - David

posted by David Smart 09 Jul 2013

Hey guys, I also spent some time on the same issue. I created a complete new concept around the Wifly Interface library so that it is RTOSable. I finally found that due to the limitation of the Wifly module (only being able to handle one open communication channel at a time) it is not possible to guarantee that web pages with multiple references will be transmitted reliably. Looking at the release notes document from RovingNetworks it seems like they are working on that 'multiple simultaneous channels' feature. I guess we either have to wait for an update of the firmware or change to an alternative hardware which supports what we Need (actually found something else and looking into that direction now). - Henry

posted by Henry Leinen 09 Jul 2013

Hi Folks, I have the upload working pretty well, now, although it does drop characters if the file is too big. There are various other mysteries about it. My email address is <goldmany@yahoo.com> and I would be interested in having more dialog. I you want me to send a zip of my current version, please let me have your email addresses, either here of off-site. All the best. Y.

posted by Yale E. Goldman 14 Jul 2013
11 years, 5 months ago.

Hi Laurie,

Thanks for your note. I was surprised not to get an answer back from Samuel Mokrani who wrote the Wifly interface. He seems very responsive to other queries. It’s supposed to be directly compatible with all of the applications that operate with the Ethernet library but I was unable to use the HTTP server library with the Wifly library. I did get a simple web server working based on this program http://mbed.org/users/arhpoon/code/RN-XV_simple_server/ which uses an earlier, less robust, version of Sam’s Wifly interface. My program serves my purposes okay but isn’t very stable and I had to write a lot of spaghetti code to make it respond properly to various browsers and also for various intervals the browser or the server are idle. There are various other problems with it, so I still would like to get the official HTTP Server to work with the official Wifly interface. But I haven’t made any progress on that.

If you come upon any solutions to my original problem, please let me know.


11 years, 5 months ago.

Hi Yale,

Sorry for the late answer... The HTTPServer server example uses the old Ethernet library and not the new one (EthernetInterface). The WiflyInterface interface and the EthernetInterface libraries have the same API so a program working with EthernetInterface is directly compatible with the WiflyInterface library. That is why the HTTPServer is not compatible with the WiflyInterface.

At the moment, the protocols implemented using the new EthernetInterface library are: http://mbed.org/handbook/TCP-IP-protocols-and-APIs. As you can see there is no HTTPServer currently.

A good starting point to have the HTTPServer working with the new WiflyInterface is to firstly port it to the new EthernetInterface library.

Cheers, Sam

Thank you Sam, That certainly helps my direction! Laurie

posted by Laurie James 24 Feb 2013

Hi Sam, Thanks for the answer. It clears up why I couldn't get it to work. But updating the HTTPServer to the newer Ethernet Interface seems beyond my available time and ability. Is there anyone else who would be able to do it? Y.

posted by Yale E. Goldman 26 Feb 2013