Editor's note: From time-to-time, we publish blogs on topics related to analog design, though perhaps not perfectly matched. This is one of those blogs. The problems described are not exactly related to analog design, but the overall problem -olving method or sequence of events is valid and therefore useful.
An embedded systems developer starts a project with a blank computer screen and emerges from the office a week later with a product that's perfectly functional and ready for prototyping. The developer's code compiles without even a warning, and the schematics produce not a single design rule violation.
Then the embedded developer wakes from a blissful dream, goes to the office, and faces reality. The IDE stubbornly repeats the same cryptic compiler errors, no matter what code changes the developer makes. The developer's board designs, already long overdue, still have a discouraging work-in-progress look, with disconnected power nets and routing that would confuse Rube Goldberg.
The axiom "nobody knows everything" has never been truer than it is in embedded systems development. Developers scramble to gain expertise with a collection of new-to-them ICs and conflicting use cases as product deadlines whiz by and marketing-driven feature-creep piles on more and more features to a project's already ambitious specifications.
Fortunately, help is on the way. IC vendors -- in particular, microcontroller (MCU) vendors -- provide a wealth of online self-help resources geared toward embedded developers. Additionally, these vendors staff teams of capable engineers that can answer your questions and help you overcome the challenges you face during the system design process. You just have to know where to look for help and how to ask for help effectively.
The first step is admitting you have a problem
The most frustrating part of problem solving can be developing an understanding of what you do not know. One of the most useful skills an engineer can acquire is to develop an intuition for where the root cause of a problem might be located.
Even if the developer doesn't know the solution, he or she must be able to draw a box around the problem to some extent. Simply saying it doesn't work and throwing up one's hands will only lead to more stress. We all benefit from the fact that we operate in a deterministic world. The problem being observed is caused by one or more factors in the system being developed. Take a deep breath, procrastinate on the Internet for a bit, and then dig into the solution.
In addition to the requisite product datasheets, IC vendors provide resources such as user forums, knowledge bases, application notes, and reference designs. They create these resources out of a primal survival instinct. Every customer who finds an answer autonomously is a customer for whom staffed engineers will not have to expend any energy and time helping directly. This frees up company resources to generate more self-help resources, and it enables staff engineers to make progress on all their other responsibilities, such as validating new designs and generating collateral for soon-to-be released products.
Developers might be surprised at the breadth and depth of the resources available to them, as well as the frequency with which their exact issue has been explored. The accuracy of these resources is no accident. Most of these articles and documents get written after a developer like you contacts technical support.
Engineers on staff monitor incoming questions and convert helpful answers to documents and knowledge base articles, so that the next developer facing the same issue will have easy access to that information. This positive feedback loop ensures a constantly improving and refining digital curation of answers just waiting to save the day.