1.2. Attitude1.4. Flowcharts and structured programming1.5. Product development cycle1.6. Quality Programming1.6.1. Quantitative Performance Measurements1.6.2. Qualitative Performance Measurements9.3. Naming convention9.5. C language Style Guidelines9.5.1. Code File Structure, the *.c file9.5.2. Header File Structure, the *.h file9.5.3. Formatting9.5.4. Code Structure9.7. CommentsAppendix 9. Solutions ManualA9.1. Checkpoint SolutionsJonathan W. Valvano Page 1Excerpts fromIntroduction to Embedded Microcomputer Systems: Motorola 6811 and 6812 SimulationJonathan W. Valvano1.2. AttitudeGood engineers employ well-defined design processes when developing complex systems. Whenwe work within a structured framework, it is easier to prove our system works (verification) and to modifyour system in the future (maintenance.) As our software systems become more complex, it becomesincreasingly important to employ well-defined software design processes. Throughout this book, a verydetailed set of software development rules will be presented. This book focuses on real-time embeddedsystems written in assembly language, but most of the comments should apply to other situations as well.At first, it may seem radical to force such a rigid structure to software. We might wonder if creativity willbe sacrificed in the process. True creativity is more about good solutions to important problems and notabout being sloppy and inconsistent. Because software maintenance is a critical task, the time spentorganizing, documenting, and testing during the initial development stages will reap huge dividendsthroughout the life of the software project.Observation: The easiest way to debug is to write software without any bugs.We define clients as programmers who will use our software. A client develops software that willcall our functions. We define coworkers as programmers who will debug and upgrade our software. Acoworker, possibly ourselves, develops, tests, and modifies our software. Writing quality software has a lot to do with attitude. We should be embarrassed to ask ourcoworkers to make changes to our poorly written software. Since so much software development effortinvolves maintenance, we should create software modules that are easy to change. In other words, weshould expect each piece of our code will be read by another engineer in the future, whose job it will be tomake changes to our code. We might be tempted to quit a software project once the system is running, butthis short time we might save by not organizing, documenting, and testing will be lost many times over inthe future when it is time to update the code. As project managers, we must reward good behavior and punish bad behavior. A company, in aneffort to improve the quality of their software products, implemented the following policies. The employees in the customer relations department receive a bonus for every software bug thatthey can identify. These bugs are reported to the software developers, who in turn receive a bonusfor every bug they fix.Checkpoint 1.2: Why did the above policy fail horribly? We should demand of ourselves that we deliver bug-free software to our clients. Again, we shouldbe embarrassed when our clients report bugs in our code. We should be mortified when other programmersfind bugs in our code. There are a few steps we can take to facilitate this important aspect of softwaredesign. Test it now. When we find a bug, fix it immediately. The longer we put off fixing a mistake themore complicated the system becomes, making it harder to find. Remember that bugs do not go away ontheir own, but we can make the system so complex that the bugs will manifest themselves in a mysteriousand obscure fashion. For the same reason, we should completely test each module individually, beforecombining them into a larger system. We should not add new features before we are convinced the existingsystem is bug-free. In this way, we start with a working system, add features, then debug this system until itis working again. This incremental approach makes it easier to track progress. It allows us to undo baddecisions, because we can always revert back to a previous working system. Adding new features beforethe old ones are debugged is very risky. With this sloppy approach, we could easily reach the projectdeadline with 100% of the features implemented, but have a system that doesn't run. In addition, once a bug01/14/19Page 2 Introduction to Embedded Microcomputer Systemsis introduced, the longer we wait to remove it, the harder it will be to correct. This is particularly true whenthe bugs interact with each other. Conversely, with the incremental approach, when the project scheduleslips, we can deliver a working system at the deadline that supports some of the features. Maintenance Tip: Go from working system to working system.Plan for testing. How to test each module should be considered at the start of a project. Inparticular, testing should be included as part of the software design. Our testing and the client's usage gohand in hand. In particular, how we test the software module will help the client understand the context andlimitations of how our software is to be used. On the other hand, a clear understanding of how the clientwishes to use our software is critical for both the software design and its testing. Maintenance Tip: It is better to have some parts of the system that run with 100% reliability thanto have the entire system with bugs.Get help. Use whatever features are available for organization and debugging. Pay attention towarnings, because they often point to misunderstandings about data or functions. Misunderstanding ofassumptions that can cause bugs when the software is upgraded, or reused in a different context thanoriginally conceived. Remember that computer time is a lot cheaper than programmer time. Maintenance Tip: It is better to have a software system that runs slow than one that does run atall.In the early days of microcomputer systems, software size could be measured in 100's of lines ofsource code or 1000's of bytes of object code. These early systems, due to their small size, were inherentlysimple. The explosion of hardware technology (both in speed and size) has lead to a similar increase in thesize of software systems. The only hope for success in a large software system will be to break it intosimple