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).


Just for the record, the downsides of monitor:
- monitor occupies code space
- monitor occupies RAM/stack space
- monitor occupies UART (and the related resources - rarely is able to work through other pin(s), but that's still loss of some resources)
- sometimes monitor occupies also an interrupt and often hijacks the reset vector
- monitor requires writable code space
- to achieve breakpoint, monitor rewrites the code at the breakpoint by a jump/call; this might interfere with the code following after the breakpoint
- (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