Just because I figured this should probably make it out to the public; I’ve done something horrible in the wifi lib that could potentially make code running alongside it crash. To be clear, this will be fixed in 0.3b, which I am trying to get out as soon as I have time to do so.
However, just because it’s good to know if you’re developing an app using 0.3a, here’s the details of the bug:
In the wifi lib, when receiving packets and under a few other circumstances, the Wifi lib in it’s present form performs a malloc call from within the Wifi_Timer() call, and can also perform a malloc call from within the Wifi_Sync function, for FIFO messages – the only problem is both of those calls are often within interrupts, so the possibility of pre-empting a malloc in “normal” code (which, malloc is also called in printf, for reference) is nontrivial. The only problem with this, is that malloc wasn’t really designed for that, so a malloc call preempting another malloc call can cause fatal problems, corrupt the heap, or crash your code.
There are a few ways to deal with this problem, the first of which is to use a seperate heap allocator, which is the solution I’ll be incorperating into 0.3b. Those of you in the know can also implement some form of locking, wrapping allocation calls in interrupt disabling code, or something similar.
Another thing to make note of is this modification will cause the wifi lib to eat up a specific amount of memory on startup (which will be user selectable, probably set to 64k or 128k for a default) – there will also be the option to disable the new memory management if you have your own solution; which will be an extra flag that will be necessary to use in the init call!
So, if you’ve had some problems with the wifi lib crashing for the past few versions, it’s likely my fault, combined with your use of malloc/printf; all will be fixed soon though, and 0.3b includes a few other bugfixes for various other problems – I’ll list the fixes when it comes out.