#115288 - ttursas - Sun Jan 14, 2007 6:25 pm
I've been using dswifilib in our Wright Flight game, and after making lots of cleanups today,
decided to give it back to the community. :) Anyway, this version can only do UDP,
but still it works much better for me than the original version. Moved almost all array
variables to heap from stack, and fixed a 128KB heap buffer for the traffic.
http://www.iki.fi/~vhelin/nintendoDS.html
The base dswifilib version for this is hmm... some release from the end of 2006, with some
UDP bugfixes.
#115305 - ttursas - Sun Jan 14, 2007 10:33 pm
Seems like dswifilib got a DSLite bugfix, so I'll assimilate the fixes to dswifilib-wf, test it
for a while, while developing v0.2.2 of Wright Flight, and release the sources again in
a week or so.
Just today my DSLite crashed twice while testing v0.2.1, but the original blue DS worked
fine, so these fixes are welcome. :)
#115311 - ttursas - Sun Jan 14, 2007 11:21 pm
Have to add that to me it looks like the ARM7 side of dswifilib was running out of IRQ
stack, but without the proper tools it's hard to say. Anyway, I think the IRQ's have 256 byte
stacks, and the ARM7 side of dswifilib pulled over 512 bytes from the stack in some
situations. And did overflowing happen in the ARM9 IRQs as well? Anyway, using this
version you shouldn't get those...
#115603 - Mighty Max - Wed Jan 17, 2007 7:57 pm
The default irq dispatcher from libnds calls the interrupt routines in system mode, thus using the user/system stack.
The irq stack is only used within the dispatcher itself.
_________________
GBAMP Multiboot
#115873 - ttursas - Fri Jan 19, 2007 9:46 pm
Thanks for the info!
As I'm not using libnds, this could really be the reason why I've had so much trouble
with dswifilib so far. Anyway, nice to know! :)
#116654 - ttursas - Sat Jan 27, 2007 11:00 pm
I finally updated the sources to contain the fixes that were made to dswibilib in Jan 2007.
I haven't tested the updated lib that well, because I'm on a sick leave from work.
Too much work 1, me 0... :P
EDIT: Have to change that to: Too much work (getting also work that is not included in my
job description), changing and incomplete specs, constant interruptions, and very noisy
working enviroment 1, me 0.
#116693 - 0xtob - Sun Jan 28, 2007 12:48 pm
Since I'm having some latency problems with the original wifilib, I want to give your version a shot. For some reason, it doesn't want to connect though. After calling Wifi_AutoConnect(), the first call to Wifi_AssocStatus() returns ASSOCSTATUS_CANNOTCONNECT. The initialization is exactly as in the wifilib examples and the code I'm testing this on works with the original wifilib. Any hints on what might be going wrong here?
Oh, it turns out the release version works fine, but the debug version has this problem.
Edit: Disregard the last sentence. I forgot to copy the release version to my libs folder, so I was still using sgstair's version.
Btw: What were the problems you had with the original wifilib that this version does not have?
_________________
http://blog.dev-scene.com/0xtob | http://nitrotracker.tobw.net | http://dsmi.tobw.net
#116702 - masscat - Sun Jan 28, 2007 3:23 pm
0xtob:
If you are using the inter-arm fifo handler from the dswifi example template then that could be the cause of your latency problems. Here is a thread about it.
Also, if you are using TCP and only sending small amounts of data it will not get sent out immediately. See here for a hack.
#116703 - 0xtob - Sun Jan 28, 2007 3:57 pm
Thanks masscat, the FIFO fix looked like it could solve my problem but unfortunately it doesn't. I already bugged sgstair with this, and even he isn't sure what's causing it.
In case anyone wants to have a look: I have this test code (stripped down version of kaossds) that broadcasts 2 3-byte UDP packets in each frame, which should well be possible with the DS's bandwidth. In practice, packets become more and more delayed after some minutes as the Tx buffer fills up, then it overflows causing packets to get lost. I've been investigating this for several days now and the only "solution" I've found was to only send every three frames.
Any ideas what might be causing this?
_________________
http://blog.dev-scene.com/0xtob | http://nitrotracker.tobw.net | http://dsmi.tobw.net
#116704 - masscat - Sun Jan 28, 2007 5:11 pm
Did you do the fifo fix on the arm7 as well?
#116705 - 0xtob - Sun Jan 28, 2007 5:15 pm
Yep, I replaced the arm7 FIFO handler with the same code.
_________________
http://blog.dev-scene.com/0xtob | http://nitrotracker.tobw.net | http://dsmi.tobw.net
#116706 - ttursas - Sun Jan 28, 2007 5:16 pm
| 0xtob wrote: |
| Btw: What were the problems you had with the original wifilib that this version does not have? |
I had two kinds of problems with the original dswifilib: First, sometimes I could send lots
of UDP data without any trouble. Or at least dswifilib thought so. In reality no data left the
sending DS. Second, sometimes my app would just freeze after sending a couple of UDP
packets. Third, ok, this also happened: I could send was it 12 UDP packets and after that
sends would fail.
After moving lots of variables from stack to heap I don't get these anymore. Well, sometimes
the app crashes after a while, but otherwise the UDP stuff seems to work.
And for the record, I'm not using libnds, if that matters.
#118224 - wintermute - Sun Feb 11, 2007 5:45 am
| ttursas wrote: |
And for the record, I'm not using libnds, if that matters. |
As it happens it probably matters rather a lot.
Your issues with blowing the irq stack with dswifi are entirely due to your interrupt dispatcher.
The libnds interrupt dispatcher switches to system stack for all interrupt handlers. The irq stack is only used within the dispatcher itself.
For what it's worth, there were some problems in the libnds dispatcher caused by my misunderstanding of a particular issue. This has since been resolved and it seems like it has also alleviated 0xtob's latency issues.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog