3 ms·
Thing that annoys me is I know that debuggers could do a quick grab and dash. Either stop the program snag the state of a variable and go. Or set a sample poin
by Gibbon1 3y ago
Thing that annoys me is I know that debuggers could do a quick grab and dash.
Either stop the program snag the state of a variable and go. Or set a sample point where when it gets hit the debugger takes a sample of local state and continues. It aught to be able to do that within a few hundred clock cycles.
Myself I use error/debug printf, a command line interface, debugger, and sometimes an oscilloscope.
With error/debug printf I leave them in and just turn them on/off with a compiler switch. Over time they tend to evolve into something that provides good info on what's going on.
The command line interface allows me to inspect the program state on the fly and run tests on the fly.
The debugger allows me to do random look sees of what the program state is and follow the call tree.
Oscilloscope allows me to inspect/debug/verify timing issues.
My suggestion to you is implement a command line interface to you program so you can interact and inspect your program while it's running. It's really not hard at all. Implement commands as a table. { "command", handler, extra_data}
- smusamashah 3y agoI don't know how this can be used in a very old and large codebase where no single person knows everything. There is too much state and unknowns at any given time. IDE with breakpoints does help explore the state through stack.