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.

Y.

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.

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.

Y.

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

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

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.