Interactive Debugger/Monitor

[duane]

I am a spoiled professional programmer. I spend a lot of my day in a source level debugger. I miss that when I am working with the team on programming the robot.

I was wondering if anyone had tried to build a debugger for the FIRST robot?

Is anyone interesting in pursuing a debugger (or in this case what would be more correctly called a monitor)?

The one thing that would be very useful that I've not been able to work out is break points. In order to create a break point, the changes have to be inserted into the code. As far as I can tell, the code is in a read-only area (I actually think its eeprom) so I'm not sure it's even possible.

If the problem of break points can be fixed, I think we solve the rest of the monitor.

Any one have ideas or suggestions?

...Duane

[Ben Margolis]

Frequent (and intelligent) use of printf's.


Its really all you need.

[Mike]

Originally Posted by duane

I am a spoiled professional programmer. I spend a lot of my day in a source level debugger. I miss that when I am working with the team on programming the robot.

I was wondering if anyone had tried to build a debugger for the FIRST robot?

Is anyone interesting in pursuing a debugger (or in this case what would be more correctly called a monitor)?

The one thing that would be very useful that I've not been able to work out is break points. In order to create a break point, the changes have to be inserted into the code. As far as I can tell, the code is in a read-only area (I actually think its eeprom) so I'm not sure it's even possible.

If the problem of break points can be fixed, I think we solve the rest of the monitor.

Any one have ideas or suggestions?

...Duane

Although I don't have names or links now, I know there are a few simulators, of sorts, that accept a hex file and will output the pwm and other data according to (very limited) input. These are pretty old though, and not too advanced. Your best bet for testing things, if you don't have access to a full size bot, is a Robovation kit.

[Kevin Sevcik]

I don't think breakpoints are doable without support from IFI in a Master Code update. The Master processor's watchdog timer will time out and freeze the whole controller if you stop in the user code for any appreciable amount of time. And as far as I know, we don't have any direct inputs into the master controller to do anything about this. I suppose you'd have to somehow modify your code to stop processing user functions and code, but continue looping and updating control values.... Mostly it sounds incredibly complicated and quite likely to break any fragile code you happened to be trying this on.

[seanwitte]

IFI has a dynamic debugging tool, but I haven't used it. It's mentioned on this page: http://www.ifirobotics.com/rc.shtml#Programming. I think the viewer is part of the IFI dashboard application.

[Qbranch]

Aren't there pins on the board to connect and ICD? I think they are above the TTL pins.

Don't have an RC in front of me at the moment so i'm not 100% sure.

-Q

[seanwitte]

Originally Posted by Qbranch

Aren't there pins on the board to connect and ICD? I think they are above the TTL pins.

Don't have an RC in front of me at the moment so i'm not 100% sure.

-Q

Nope, RC doesn't support the ICD for the same reason posted above. Since the programmable microcontroller is a slave you can't pause and restart execution.

[chris31]

Has IFI ever posted the source to there Master Code? I dont think they have and all I see is the BIN file for it. Maybe if they released the code them people could start working on this.

[Kevin Sevcik]

They haven't and probably won't. I'm pretty sure they consider it their intellectual property and probably won't be releasing it any time soon.

[chris31]

Originally Posted by Kevin Sevcik

They haven't and probably won't. I'm pretty sure they consider it their intellectual property and probably won't be releasing it any time soon.

I understand how its "intellectual property" but maybe for the better of the FIRST community they would do it.

[duane]

Wow, what a great set of responses. I'll try and address a bunch of them.

Frequent (and intelligent) use of printf's.

Spoken like a true hard core debugger. And why are you using C? Shouldn't you be using assembly?

Of course that's what we all have to do. It's simply not enough for any reasonably complex debugging session. Try debugging an active PID routine with printfs. Not pretty and not useful. Until you try a real debugger or a monitor (as this will be) it's just not the same.

I know there are a few simulators

It's easy to simulate the processor. It's hard to simulate the world; that is the motors, sensors, and other inputs.

I don't think breakpoints are doable without support from IFI in a Master Code update. The Master processor's watchdog timer will time out

Figured that would come up. That's the easy one to fix. The monitor would sit between the master processor polling loop and the main user code. It would handle the polling loop to keep the Master Processor happy.

A breakpoint is just a jump into the monitor. The monitor then takes control and keeps the Master Processor happy. We just need to be able to write that jump instruction into the code!

IFI has a dynamic debugging tool

I've looked at the dynamic debugging tool and will probably use it this year if nothing else to become familiar with it. It also does not have breakpoints. Which makes me think that this might not be doable.

Has IFI ever posted the source to there Master Code?

IFI won't post the Master Code likely because of the risk that someone could take unfair advantage of something in it. They hope that there is nothing to take advantage of, but these teams are pretty creative.

We don't really need the all the sources, I just want a way to scribble an opcode into the program stream while it's running.

Thanks for all the great response. We'll get those creative juices flowing and come up with a good solution to this problem!

...Duane