[home] :: The ten secrets of embedded debugging
0 products in your
0 products in your
The ten secrets of embedded debugging
Forwarded from: embedded.com
By Stan Schneider and Lori Fraleigh
Debugging your system may be the most important step in the development process. Here are ten hard-won lessons from the embedded trenches.
Once upon a time, a developer seeking a higher plane of embedded proficiency climbed the Mountain of Experience to consult The Oracle at the summit. The Oracle knew that embedded systems programmers faced perils unknown to mere mortals, such as devices that must run for months without crashing, strict memory and processing limits, and the mysteries of real-world interactions.
New programmers still flush with classroom memories of template libraries and single-step debuggers could not absorb The Oracle's wisdom. It took many frustrating years of experience with embedded systems to appreciate the value of The Oracle's enlightenment. Each day, programmers would come seeking answers to questions like, "How can I write faster code?" and "Which compiler is best?" The Oracle rejected these immature supplicants with a terse "Ask not questions of little import. Only those who are worthy may understand my answers."
Our developer asked The Oracle, "O Oracle, how can I see and understand what my system is doing?"
The Oracle responded, "Your question shows unusual maturity, young pilgrim, for understanding is the key that opens the door to improvement. It is better to light a single candle than to curse the darkness."
And The Oracle shared these Ten Secrets, the results of years atop the Mountain of Experience:
1. Know your tools
2. Find memory problems early
3. Optimize through understanding
4. Don't put needles in your haystack
5. Reproduce and isolate the problem
6. Know where you've been
7. Make sure your tests are complete
8. Pursue quality to save time
9. See, understand, then make it work
10. Harness the beginner's mind
11. Know your tools
"When all you have is a hammer, every problem looks like a nail."
Good mechanics have many tools; you can't fix a car with just a hammer. Like good mechanics, good programmers need to be proficient with a variety of tools. Each has a place; each has a Heisenberg effect; each has power.
Tools promise great insight into system operation. Tools designed for embedded systems let you see, live while it happens, what your program is doing, what resources it's using, and how it interacts with the external world. The insight they provide is truly powerful; you can often quickly spot problems, issues, or inefficiencies that would take days to discover by other means.
Once upon a time, a developer seeking a higher plane of embedded proficiency climbed the Mountain of Experience to consult The Oracle at the summit. The Oracle knew that embedded systems programmers faced perils unknown to mere mortals, such as devices that must run for months without crashing, strict memory and processing limits, and the mysteries of real-world interactions.
New programmers still flush with classroom memories of template libraries and single-step debuggers could not absorb The Oracle's wisdom. It took many frustrating years of experience with embedded systems to appreciate the value of The Oracle's enlightenment. Each day, programmers would come seeking answers to questions like, "How can I write faster code?" and "Which compiler is best?" The Oracle rejected these immature supplicants with a terse "Ask not questions of little import. Only those who are worthy may understand my answers."
Our developer asked The Oracle, "O Oracle, how can I see and understand what my system is doing?"
The Oracle responded, "Your question shows unusual maturity, young pilgrim, for understanding is the key that opens the door to improvement. It is better to light a single candle than to curse the darkness."
And The Oracle shared these Ten Secrets, the results of years atop the Mountain of Experience:
1. Know your tools
2. Find memory problems early
3. Optimize through understanding
4. Don't put needles in your haystack
5. Reproduce and isolate the problem
6. Know where you've been
7. Make sure your tests are complete
8. Pursue quality to save time
9. See, understand, then make it work
10. Harness the beginner's mind
11. Know your tools
"When all you have is a hammer, every problem looks like a nail."
Good mechanics have many tools; you can't fix a car with just a hammer. Like good mechanics, good programmers need to be proficient with a variety of tools. Each has a place; each has a Heisenberg effect; each has power.
Tools promise great insight into system operation. Tools designed for embedded systems let you see, live while it happens, what your program is doing, what resources it's using, and how it interacts with the external world. The insight they provide is truly powerful; you can often quickly spot problems, issues, or inefficiencies that would take days to discover by other means.