#94924 - ttursas - Wed Jul 26, 2006 10:08 pm
I'm starting to work on a small Wifi enabled game, and dswifi-lib looks like to be just what I needed, but I'm having trouble setting it up. It says on many www-pages that dswifi-lib can be compiled so that it doesn't need malloc() and free(). I even commented
#define SGIP_USEDYNAMICMEMORY
and
#define SGIP_MEMBLOCK_DYNAMIC_MALLOC_ALL
away in sgIP_Config.h -file, and it should do the trick, if I've understood the explanations correctly. But still many malloc() and free() calls are compiled. E.g., sgIP_DHCP.c needs them quite badly (no #ifdef-magic there).
Any ideas how to compile dswifi with static buffers? It would mean a lot of trouble if I linked also stdlib into my project just to get malloc() and free()... :(
#94925 - ttursas - Wed Jul 26, 2006 10:09 pm
Oh yes, I checked out the sources from the CVS repo. Should the older versions work better?
#95332 - ttursas - Fri Jul 28, 2006 8:33 pm
I'm just finishing my own malloc() & free() (a good exercise!), but it would still be nice to know if dswifilib could be fixed some other way... :)
#97682 - ttursas - Thu Aug 10, 2006 11:50 pm
Anybody actually got dswifilib to work without ndslib? I don't use it for various reasons, and I just cannot get dswifilib to co-operate. I can connect to an AP, but after I start sending UDP packets dswifilib seems to do some memory overwriting. Happens with my own malloc() and with libsysbases's malloc(). I tried to configure dswifilib so that it wouldn't use dynamic memory allocation, but no avail, I just get different, bad, behaviour...
It used to work for a while, but after I added more code to the project UDP packet sending started to crash my project.
Any tips? Debugging hints? Anything? Is this libnds related? I'm using DevKitPro r18 (is r19b really working?)...
#97687 - wintermute - Fri Aug 11, 2006 12:56 am
I'd suggest using libnds rather than trying to struggle on writing your own libraries. If you have trouble with it we're open to suggestions which might make it better.
The dswifi lib can and will call sgIP_malloc from interrupt code so you need to ensure that the function you're using to allocate memory is interrupt safe which newlib malloc isn't. You can wrap the calls to malloc to disable interrupts during the call and use the wrapper to allocate memory for your application or, do what we did with dsdoom and write some code to manage a separate heap to use with sgIP_malloc.
Yes devitARM r19b is really working, it was used to compile dsdoom. It also has the advantage of being able to compile arm946e-s native code without all the hassle that involved with earlier toolchains.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#97776 - ttursas - Fri Aug 11, 2006 2:29 pm
| wintermute wrote: |
I'd suggest using libnds rather than trying to struggle on writing your own libraries. If you have trouble with it we're open to suggestions which might make it better.
The dswifi lib can and will call sgIP_malloc from interrupt code so you need to ensure that the function you're using to allocate memory is interrupt safe which newlib malloc isn't. You can wrap the calls to malloc to disable interrupts during the call and use the wrapper to allocate memory for your application or, do what we did with dsdoom and write some code to manage a separate heap to use with sgIP_malloc.
Yes devitARM r19b is really working, it was used to compile dsdoom. It also has the advantage of being able to compile arm946e-s native code without all the hassle that involved with earlier toolchains. |
Thanks for the tips! I'll make my memory stuff interrupt safe, then! And upgrade to r19b as well :)
I've already written most of the stuff I need on DS (can do 2D and 3D graphics and play mods and sfx without any trouble just by using my own headers and small libs). Just for the kicks. And libnds hides some stuff from the user that I'd like to see and control myself. It's a nice lib to get started and some more, but I'd like to keep all the strings in my hands. Also to get to know the hardware better.