Wow, what a great set of responses. I'll try and address a bunch of them.
Quote:
|
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.
Quote:
|
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.
Quote:
|
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!
Quote:
|
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.
Quote:
|
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