dswifilib without libnds?

[ttursas]

Is it possible to get dswifilib to work without using libnds? I'm not using libnds, but would love to use dswifilib, but no matter

what I do, dswifilib doesn't work properly. I can connect to an AP, but when I send UDP packets they usually vanish, and often my

program just halts. With DevKitARM r18 things used to work better, but after switching to r19b I haven't been able to send a single

packet. Mario Kart works 100%, and so do the test apps that use libnds.

 

Any hints? Also, fiddling with dynamic memory settings doesn't help at all. I don't use malloc() / free() myself, but also wrote them

myself, to see if that was the problem, but it wasn't. Is there something I should aware of when not using libnds?

[sgstair]

Have you tested your malloc/free functions at all? I can't be sure because I really have no idea what sort of environment you're in, however the problems you're having do sound like they are related to memory allocation.

 

-Stephen

[ttursas]

Have you tested your malloc/free functions at all? I can't be sure because I really have no idea what sort of environment you're in, however the problems you're having do sound like they are related to memory allocation.

 

-Stephen

 

Yes I did test them on Linux before porting to DS. Also, it doesn't seem to matter wether I use my own malloc() & free() or those that

come with libg/libc.

 

What I've done is that I've written my own header files plus created my own small libs to do the things I need. Currently dswifilib is the

only external lib that I use (on purpose, plus all those that DevKitARM forces). I know, I'm looking for trouble, and got some, but

there's no better way to learn these machines than go through the registers bit by bit.

 

Anyway, I'll double check free() and malloc(), but is there anything else that could cause behaviour like this? If I can connect to an

AP, does it mean that the interrupts work 100%? I've checked them about twenty times, but still there could be something wrong

(I've copied the inits from your examples, just converted them to use my header files).

 

Thanks in advance, and huge thanks for making dswifilib!

[ttursas]

Hmm, it also seems that if I compile dswifilib with -O0 for both arm7 and arm9 Wifi_AutoConnect() gets stuck in

ASSOCSTATUS_ACQUIRINGDHCP. With -O2 for both (and my project) I always get ASSOCSTATUS_ASSOCIATED.

 

Doesn't matter if I put -O0 also for my project, as long as I compile dswifilib with -O0 Wifi_AutoConnect() gets stuck.

 

Any ideas what could cause this?

 

Also, should I use

-mcpu=arm9tdmi -mtune=arm9tdmi

or

-march=armv5te -mtune=arm946e-s

with DevKitARM r19b for ARM9?

 

Does it matter as long as I compile my project and dswifilib using the same CPU model? I have another (a networkless 2D) project

that can be compiled with both settings and it works just fine.

[ttursas]

I'm dev'ing under Linux, and I use M3-SD for testing (none of the emulators for Linux are any good. Any Windows emulators

that support Wifi and 3D?). DevKitARM r19b, dswifilib 0.3a, and I have the latest libnds headers for dswifilib.

[ttursas]

Also, should I use

-mcpu=arm9tdmi -mtune=arm9tdmi

or

-march=armv5te -mtune=arm946e-s

with DevKitARM r19b for ARM9?

 

I tested both, and didn't have any visible effect on anything.

 

But I managed to send an UDP packet to my Linux server finally with DevKitARM r19b. I commented away

 

#define SGIP_MEMBLOCK_DYNAMIC_MALLOC_ALL

#define SGIP_USEDYNAMICMEMORY

 

in sgIP_Config.h. This is the way it worked better with DevKitARM r18. The sources still want sgIP_malloc() and sgIP_free()

so there is dynamic allocating going on (using libg), but at least it doesn't get stuck. Tested four times, could send an UDP

packet only once. Seems like it is a memory related bug, but no idea why just one UDP packet.

 

Somebody said in gbadev.org's forums that these malloc()s and free()s should be interrupt proof, which libg/libc's functions

are not, or write a dswifilib specific free() and malloc(). I don't use free() or malloc() in my code, so they are only there for

dswifilib. Is it still a problem?

[sgstair]

Ok, to address a few issues here...

 

No, it's not odd at all for the association to work but the sending/receiving to not work - the reason for this is 802.11 is handled almost 100% purely in the arm7, and anything on top of that (DHCP, UDP, TCP, ICMP) are all handled in the arm9. The transport mechanism for moving data from arm7 to arm9 and back is a large circular buffer, which is accessed without cache in the arm9 (unless you've managed to cache memory mirrors, which would royally screw the arm9 lib up)

The 3 major points of failure for the wifi lib then are as follows:

1) malloc/free not working correctly

2) update/fifo functions not setup correctly (Wifi_Timer should be called periodically, and a fifo message interrupt would be very nice, though not essential)

3) (very rare to see this happen, unless you play with the memory protection) the "uncached memory mirror" might be cached, which would throw the lib into any number of crazy erroneous states.

Those are just the big 3 points of failure, and I'd expect the lib to be able to work outside of libnds with only minor modification, so I'm interested to hear what you may have encountered.

 

-Stephen

(other side notes - using arm946e-s is more accurate, but arm9tdmi should be compatible with the cpu. - the malloc/free only need to be safe if you are using other code that malloc's or free's)

Edited August 13, 2006 by sgstair

[ttursas]

Ok, to address a few issues here...

 

No, it's not odd at all for the association to work but the sending/receiving to not work - the reason for this is 802.11 is handled almost 100% purely in the arm7, and anything on top of that (DHCP, UDP, TCP, ICMP) are all handled in the arm9. The transport mechanism for moving data from arm7 to arm9 and back is a large circular buffer, which is accessed without cache in the arm9 (unless you've managed to cache memory mirrors, which would royally screw the arm9 lib up)

The 3 major points of failure for the wifi lib then are as follows:

1) malloc/free not working correctly

2) update/fifo functions not setup correctly (Wifi_Timer should be called periodically, and a fifo message interrupt would be very nice, though not essential)

3) (very rare to see this happen, unless you play with the memory protection) the "uncached memory mirror" might be cached, which would throw the lib into any number of crazy erroneous states.

Those are just the big 3 points of failure, and I'd expect the lib to be able to work outside of libnds with only minor modification, so I'm interested to hear what you may have encountered.

 

Those are good things to know! [edited some crap away]... Somehow I managed to get it to work once, could send lots of UDP

packets, but after a while the app got stuck. Now I'm not sending a single UDP packet once more... Hmm... I'll triple check

everything.

 

Did more testing, and updates using Timer3 should work 100%. It seems that IPC IRQs don't take place, or happen very

rarely (tested by incrementing the background color, have both screen in use already). Perhaps because no UDP

packets are transferred... No idea about caching the uncached memory mirror (yet), but at least I don't move the

cache (don't even know how to do it, yet). All my vars are in bss. Tested also TCP, and no effect. It just gets stuck.

 

About memory stuff, I guess I'll need to write a test app for libc's malloc() and free(), to see if they work well with my

own stuff. Could be that they somehow break without libnds, etc.

 

I'm taking my laptop and NDS with me to Turkey (one week holiday, scuba diving and other fun stuff ).

I just installed DevKitARM in Windows, and will be using Windows to do the dev'ing there. Could be that this stuff compiles

into something different under Windows than Linux, but most probably not. Anyway, I'll post more findings when I return.

Edited August 14, 2006 by ttursas

[sgstair]

Ok, good luck - If I think of anything else it might be I'll post it here.

 

-Stephen

[ttursas]

I'm taking my laptop and NDS with me to Turkey (one week holiday, scuba diving and other fun stuff ).

I just installed DevKitARM in Windows, and will be using Windows to do the dev'ing there. Could be that this stuff compiles

into something different under Windows than Linux, but most probably not. Anyway, I'll post more findings when I return.

 

It was too hot in Turkey (the worst day was +48C) for serious dev'ing, and we were busy getting cheated all the time by the

locals (the Turkish sense of humor, or greed, I guess, never going back anyway). But I found out that if I compiled the same

sources under Windows, I could always send one UDP packet from NDS to Windows, and then the NDS game got frozen.

Weird. Same DevKitARM but different result.

 

Next I'll check malloc() and free(), and do other testing (like add some debugging stuff to dswifi)...

[ttursas]

It was too hot in Turkey (the worst day was +48C) for serious dev'ing, and we were busy getting cheated all the time by the

locals (the Turkish sense of humor, or greed, I guess, never going back anyway). But I found out that if I compiled the same

sources under Windows, I could always send one UDP packet from NDS to Windows, and then the NDS game got frozen.

Weird. Same DevKitARM but different result.

 

Next I'll check malloc() and free(), and do other testing (like add some debugging stuff to dswifi)...

I did some testing and couldn't make malloc() and free() to break (lots of malloc()s, free()s, and memory writes and reads). Also

my own memory manager passed the tests...