DADebug
Jeffrey Lee (213) 6048 posts |
Any chance of getting this added to CVS? I have a feeling it’s going to be the easiest way of getting debug output from the USB modules. printf() output has the nasty habit of trapping the machine in recursive interrupt handlers, or changing the behaviour of the system due to the slow screen updates/serial ports, or even stopping serial input from working (or maybe the machine gets stuck somewhere – debug output still continues, at least) Which is a bit of a nuisance if you’re doing what I’m doing and looking at the debug output of the USB stack when you connect the OTG port to the EHCI port :) |
Ben Avison (25) 445 posts |
OK, I’ve fast-tracked it for you. Short and sweet module but invaluable for debugging interrupt handlers. But then I would think that, since I wrote it myself. ;-) I’ve also put castle/RiscOS/Sources/Programmer/TxtDebug online too – uses the same API (so only one of the two can be loaded at once) but writes to the framebuffer, bypassing the VDU system – can result in a messy screen but again can be very useful for some other types of interrupt handlers, especially ones where real-time output is significant rather than volume of debug. I’m a little surprised we didn’t release these earlier – if I’d noticed I’d have done them earlier. |
Jeffrey Lee (213) 6048 posts |
Cheers! (Although I would have been happy with it being uploaded sometime later today – you didn’t have to stay up ‘till 3am :P) |
Jeffrey Lee (213) 6048 posts |
You’ve probably spotted already, but I’ve updated DADebug a bit. There was a compile error from objasm because the source didn’t have an AREA defined (I’m guessing this wasn’t a problem 10 years ago!) I’ve also rewritten the makefile to use makefile fragments, and added some (optional) semi-hacky code for ROM support. There’s also a bit of extra code that can be enabled to cause *dadprint to be called every 60 seconds, which I found rather useful during the stage where the board seemed to stop responding to serial input. |