Timeline for How to use breakpoints for debugging
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 2, 2016 at 15:03 | comment | added | Mikael Patel | @JRobert Nice Pro-Con summary! I have tried to address some of the Cons by allowing the debugger to be tailored. There is a set of defines that will allow footprint sensitive applications to reduce the debug shell to a minimum. As any debugger for embedded systems it is difficult to debug time critical (continuous) code with break-points. The only alternative is observation points. These could be optimized by using a trace buffer and remove serial output in time critical code. | |
| Dec 2, 2016 at 14:33 | comment | added | JRobert | .... Con: Higher impact on the program's code-space, some RAM space, & possibly run-time, if examining time-critical code; some learning curve to compile in (and later, remove) the library calls; the need to anticipate break-point locations or re-compile them in when you discover where you need them. The Cons are not a criticism of Mikael's work; they come with this technique. | |
| Dec 2, 2016 at 14:30 | comment | added | JRobert | Mikael's donated library lets you set conditional breakpoints, print variables' values, memory status, call traces, & examine-and-change variables at a breakpoint. Pro: Doesn't need hardware ($$), doesn't beat-up as hard on the Flash (as setting and removing breakpoints with a hardware debugger would). .... | |
| Dec 2, 2016 at 13:59 | history | answered | Mikael Patel | CC BY-SA 3.0 |