| ??? 07/09/07 14:40 Read: times |
#141630 - Actually ... Responding to: ???'s previous message |
Jan Waclawek said:
A good monitor can do most of the things the "freeICE" can, including running the code at full speed - there is nothing easier than to run the application code at full speed, simply ljmp into it... - exceptions are, for example, it cannot stop on breakpoint conditionally at full speed (but most freeICEs can't either), it cannot stop on data memory access, and of course there is no sort of tracing nor data inspection at full speed. It can place breakpoints, though, and usually can also be "hard stopped" by the user, after which the data can be inspected (this is the most often used debugging method anyway - run it until a breakpoint, then inspect the variables and optionally singlestep). Actually, if ULTRAMON51 is implemented as suggested, which is in a "vonNeumanized" address space, it can set breakpoints and run traces. Trace, of course, is not done without the usual delay between instructions, but breakpoints certainly are helpful. Just for the record, the downsides of monitor:
- monitor occupies code space There's no way to avoid that. - monitor occupies RAM/stack space ULTRAMON51 takes that into consideration and minimizes it. It's true enough, though. - monitor occupies UART (and the related resources - rarely is able to work through other pin(s), but that's still loss of some resources) That's why, one of these days, I'm going to disassemble ULTRAMON51 and route its console through an external UART. - sometimes monitor occupies also an interrupt and often hijacks the reset vector It definitely occupies an interrupt for breakpoints. - monitor requires writable code space It requires, in this case, that the memory space be "vonNeumanized." - to achieve breakpoint, monitor rewrites the code at the breakpoint by a jump/call; this might interfere with the code following after the breakpoint That's how it works. It definitely fouls up interrupt responses. The documentation deals with "how to live with this." - (correct me if I forgot something)
The list is long enough to justify the "freeICE", for sure, where available; a monitor can still be useful in other cases. JW Since monitors are probably the least painful way to "debug" code, requiring no external hardware and a minimum of local hardware (ULTRAMON51 assumes you can provide the extra code and data space, as well as one AND gate, which may not always be the case), they do make some demands and limit your operation somewhat. They're adequate for many tasks, though. RE |
