WiFi modules and control software

I've been playing with BlueGiga WF121 WLAN module lately. Not the cheapest module you could get, but then again, it has TCP/IP stack built-in (so you don't have to have an OS or write that yourself) and more importantly all necessary legal certifications and approvals so using it is way safer (in legal sense) than some random cheap module - unless you want to spend some serious money on having your device tested and approved yourself.

The serial interface of the module is pretty nice, but unfortunately not completely asynchronous. Some operations (like TCP/IP connect) pretty much require that you wait for response before doing anything else which pretty much ruins entire idea of having non-blocking, asynchronous system - something I've worked pretty hard to accomplish (on simple MCU without operating system so no threads or tasks to make things easier)

Note that above I said response. The command interface of this module is written so that module sends response almost immediately - most of the time just in tens of milliseconds or so, and later (possibly much, much later) comes an event - connected successfully or failed. I'm not writing a hard real-time system here so I could block - that is, wait for the response - which in turn contains necessary information (in this case id to newly created connection) to handle the event later, but still, I've worked pretty damn hard to write new system to be as non-blocking as possible so I don't like that idea (slippery slope and all - I waited there a bit so might as well wait here too...). Especially I hate the case where response is corrupt or doesn't arrive, which might cause a long (too long) blocking period.

Other way to handle this would be to create another abstraction layer in the application that would take care of this, but I don't like the idea either. A lot of code to do so very little, especially since I typically have only "background" and "foreground" operations going on. Foreground being ones that user sees, and background operations are allowed to have high latency so they can typically wait.

So I decided to build system so that these few operations that are dangerous cause other similar commands to fail while they are being processed. If failed operation was background operation, that's fine - system will retry the operation later. If it was foreground operation the system can retry a few times (transparently to user, aside just a bit longer wait), then notify about it if problem persists (retry / cancel?). Problem averted.

I hope. All this is mostly theoretical at this point, as I haven't tested anything on actual board yet (only on evaluation kit connected to PC - I've written the connection layer so that exactly same code is used both PC and embedded), but most of the above (especially failures and how they could be/should be handled) can be said to be well-informed guesses, based on what I've learned in past on building similar systems.

Once again, practical experience takes all the fun out from writing code as you have to think issues like these - or more to the point, can't avoid thinking issues like these before you even have anything built.