Do you mean gdb (debugger)? If so, it should be possible, and I was looking at it a while ago (with the USB<->Link cable), but I never got around to really digging into getting it to work. It’s not really high on my priority list right now, but when I get some time I might look into it again. I know David Tucker was very interested in adding gdb support, but I think he’s really busy, so I wouldn’t count on him getting it done soon either.
Yup, the debugger, it would be great to being able to make debugging without having to print on screen each variable.
Yeah, I did a very simple debugger where I had the link interrupt handled with a debugging ISR so I could send a command over the link cable, it’d interrupt the program and either read/write memory, registers, etc. It didn’t have a good interface though (just a command line app that’d ask for the command, ask for the address/reg, then ask for the value to write, or length to read). It worked, and if gdb wasn’t going to be possible I was gonna write my own simple debugger that imports the memory map so you could watch variables and things, but I dropped that idea when I talked to David Tucker and he suggested gdb wouldn’t be too difficult. I figured there’s no point in spending time going to a non-standard and fairly limited debugger when I could instead spend the time to make a backend for gdb and we’d have a really good debugger (with some good available frontends).
The biggest limitation that I came across was that we don’t have a good way to do breakpoints. There’s a TRAP register, which will allow a single breakpoint, but if you want several breakpoints, that’s very difficult because we don’t have either hardware to watch the memory busses and halt on a certain address, or for a software solution we can replace code at a certain address with a jump to our debugging handler which will halt the execution… except with a flash cart, to rewrite a single instruction we need to erase the block, and rewrite the entire block with the modified code. That’s a little time consuming for just a simple operation (probably ~1-2 seconds each time you set or clear a breakpoint)… although it is doable. It’d be much nicer with an SRAM cart (which I’m almost considering building, since that’d be really quick for programming as well).
Well even having just 1 breakpoint, and being able to make a trace from there would be ages ahead of what we have to do now (program blindly), and about the 1-2 seconds delay.. well it maybe takes me 10-20 to change a print instruction, compile again and reach the problem execution point, so I don’t think that will bother me.
Hope you have time to give this feature a go.
BTW… what about a profiler? I don’t have any experience with them so I don’t know if there is one already, but I suppose it’s not that simple.