September 2006


DS Wifi16 Sep 2006 03:33 am

Another revision hits the presses, get your downloads at the Sourceforge dswifi files page.
There are some major bugfixes in this release, but besides that, it’s not really changing functionality much.
Many of you might thank me for the following changes:
*Fixed major bug in arm7 (potentially causing arm9 to lose track of the buffer, and lock up I/O – odd that I hadn’t seen this happen, but someone else certainly had, and let me know about it)
*Changed default behavior to use internal allocation system for memory (fixes interrupt allocation bug) (this was pretty stupid on my part, but it is fixed now. Now, for default behavior, the lib allocates a block of memory at startup and the default functions alloc/free from this small heap (you can still use your own, if you like, but you have to add an extra flag to the arm9′s init call, which is WIFIINIT_OPTION_USECUSTOMALLOC. The default heap size is 128k, but there are flags to specify 64k, 256k, and 512k as alternate heap sizes. 128k is probably more than most people will need, if you need lots of TCP connections (>7), then you will need to specify a larger heap size.)
*Fixed bug that could cause _CANNOTCONNECT to come up incorrectly when associating (this was a “transient” problem, occurred due to 2 state changes that were offset by a bit, causing a condition I didn’t initially expect – it is fixed now and Wifi_AssocStatus() should return values consistent with what you’d expect)
*Fixed blocking send() to actually be blocking. (odd that, I evidently didn’t set it up earlier. It is blocking-capable now though)

I’m not re-releasing the examples package because they’re essentially the same; there is only one difference and that’s I’ve removed the sgIP_malloc and sgIP_free functions from the wifi_lib_test project.
On a side note, if you do notice any bugs in the lib, please do contact me, via IRC (#dswifi on efnet or blitzed) or other means. I’m expecting to set up a bugtracker in the near future too, so there will be a more formal way to yell at me :)
Ok, And for those of you who are unhappy cause your favorite feature got left out (be it probe requests, the WFC data alternate WEP key format, or native Nintendo USB key compatibility) – sorry, but this project has become stagnant, probably because I’m continually trying to refine it and just don’t feel like it anymore really; I’ve decided to put the whole lib on standby for the immediate future, and when I continue (probably mid-november) I’ll start with a complete rewrite of the 802.11 system and the TCP stack, for version 0.5 – at that point I’ll have the chance to actually do some of these things *right*, and I perhaps won’t be as frustrated with a codebase based on flawed assumptions and a general lack of understanding ;)

I’ll post again sometime soon with information about what projects I am presently going to be pursuing, and which ones are on the back burner.

DS Wifi07 Sep 2006 01:41 am

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.

Uncategorized01 Sep 2006 09:26 pm

Hey all,
I’ve had lots of fun (read: not fun) things to deal with lately, nothing really interesting just a series of small things that have added up to eat up all my available time and then some.
So: DSWifi release 0.3b has been delayed, but I am meaning to get it out soon – I’ve decided to drop the extra features I was planning for it (As they’ll be addressed in the oncoming rewrite) and merely add the bug fixes I’ve been planning, to get it out the door soon
Also, the rewrite I’ve alluded to will wait for a while, specificly until the Wii comes out or thereabouts; as I’d like the 802.11 and new TCP/IP system to work on that system as well (the sgIP rewrite may come sooner, as I am planning to play with the gamecube in the meantime, and I’d like to port sgIP to it. – if this happens I’ll release a version 0.4 with just the sgIP TCP/IP rewrite)
As far as stuff goes, I have my plate quite full of projects at the moment, so everything is moving very slowly – I’m trying to prioritize and only work on the top 2 or 3 projects, but it’s far more difficult than advertised! wish me luck! :)
(oh, and about the downloadable DS demos – I may or may not get around to adding the latest set, not sure if I really want to at this point. There are some other people who have the latest ones though, I’ll add the link on here / the wiki if I can figure out where)