We've reported on Stephen Stair, his Wiki, and his DS Wifi Library before. So we've decided to follow up on the guy and see what he's been up to. In the latest post at his blog, we noticed a few development notes for the Wifi Lib 0.3a. Here's what Stephen had to say about the bug he's discovered in 0.3a. The short version of what he's said? Basically if your wifi lib's been crashing on you, it's probably his fault. Stephen assures that the bug will be fixed when the next version 0.3b is released. He says he's doing his best to get 0.3b out as fast as he can:"In the wifi lib, when receiving packets and under a few other circumstances, the Wifi lib in its 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!"
Via Stephen\'sWeblog
We've reported on Stephen Stair, his Wiki, and his DS Wifi Library before. So we've decided to follow up on the guy and see what he's been up to. In the latest post at his blog, we noticed a few development notes for the Wifi Lib 0.3a. Here's what Stephen had to say about the bug he's discovered in 0.3a. The short version of what he's said? Basically if your wifi lib's been crashing on you, it's probably his fault. Stephen assures that the bug will be fixed when the next version 0.3b is released. He says he's doing his best to get 0.3b out as fast as he can:"In the wifi lib, when receiving packets and under a few other circumstances, the Wifi lib in its 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!"
Via Stephen\'sWeblog