Making Embedded Systems Design Patterns for Great Software (Elecia White) (z-library.sk, 1lib.sk, z-lib.sk)

Elecia White Making Embedded Systems Design Patterns for Great Software Second Edition SECOND EDITION

EMBEDDED SYSTEMS “Elecia White did it again! This second edition of her highly acclaimed book makes the fascinating subject of embedded software development approachable and fun. It covers all the essential topics necessary to orient newcomers in the intricacies of embedded development processes, patterns, and tools.” —Miro Samek Embedded systems expert, author, and teacher Making Embedded Systems linkedin.com/company/oreilly-media youtube.com/oreillymedia Interested in developing embedded systems? Since they don’t tolerate inefficiency, these systems require a disciplined approach to programming. This easy-to-read guide helps you cultivate good development practices based on classic software design patterns and new patterns unique to embedded programming. You’ll learn how to build system architecture for processors, not for operating systems, and you’ll discover techniques for dealing with hardware difficulties, changing designs, and manufacturing requirements. Written by an expert who has created systems ranging from DNA scanners to children’s toys, this book is ideal for intermediate and experienced programmers, no matter what platform you use. This expanded second edition includes new chapters on IoT and networked sensors, motors and movement, debugging, data handling strategies, and more. • Optimize your system to reduce cost and increase performance • Develop an architecture that makes your software robust in resource-constrained environments • Explore sensors, displays, motors, and other I/O devices • Reduce RAM, code space, processor cycles, and power consumption • Learn how to interpret schematics, datasheets, and power requirements • Discover how to implement complex mathematics on small processors • Design effective embedded systems for IoT and networked sensors Elecia White is the founder and a principal embedded systems engineer at Logical Elegance, Inc. She’s worked on ICU monitors, inertial measurement units for airplanes and race cars, educational toys, and assorted other medical, scientific, and consumer devices. A graduate of Harvey Mudd College in Claremont, California, Elecia is also cohost of Embedded.FM, a podcast about embedded systems, engineering careers, and creative technology. 9 7 8 1 0 9 8 1 5 1 5 4 6 5 4 9 9 9 US $49.99 CAN $62.99 ISBN: 978-1-098-15154-6 SECOND EDITION

Elecia White Making Embedded Systems Design Patterns for Great Software SECOND EDITION Boston Farnham Sebastopol TokyoBeijing

978-1-098-15154-6 LSI Making Embedded Systems by Elecia White Copyright © 2024 Elecia White. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Brian Guerin Development Editor: Shira Evans Production Editor: Katherine Tozer Copyeditor: Penelope Perkins Proofreader: Emily Wydeven Indexer: Ellen Troutman-Zaig Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea October 2011: First Edition March 2024: Second Edition Revision History for the Second Edition 2024-03-01: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781098151546 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Making Embedded Systems, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Embedded Systems Development 2 Compilers and Languages 2 Debugging 3 Resource Constraints 5 Principles to Confront Those Challenges 6 Prototypes and Maker Boards 8 Further Reading 9 2. Creating a System Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Getting Started 12 Creating System Diagrams 13 The Context Diagram 13 The Block Diagram 14 Organigram 17 Layering Diagram 20 Designing for Change 21 Encapsulate Modules 21 Delegation of Tasks 22 Driver Interface: Open, Close, Read, Write, IOCTL 23 Adapter Pattern 25 Creating Interfaces 27 Example: A Logging Interface 27 A Sandbox to Play In 34 Back to the Drawing Board 38 Further Reading 39 iii

3. Getting Your Hands on the Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Hardware/Software Integration 41 Ideal Project Flow 42 Hardware Design 43 Board Bring-Up 45 Reading a Datasheet 46 Datasheet Sections You Need When Things Go Wrong 48 Datasheet Sections for Software Developers 50 Evaluating Components Using the Datasheet 53 Your Processor Is a Language 56 Reading a Schematic 58 Practice Reading a Schematic: Arduino! 62 Keep Your Board Safe 64 Creating Your Own Debugging Toolbox 65 Digital Multimeter 66 Oscilloscopes and Logic Analyzers 67 Setting Up a Scope 67 Testing the Hardware (and Software) 70 Building Tests 71 Flash Test Example 72 Command and Response 76 Command Pattern 79 Dealing with Errors 81 Consistent Methodology 81 Error Checking Flow 82 Error-Handling Library 83 Debugging Timing Errors 84 Further Reading 84 4. Inputs, Outputs, and Timers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Handling Registers 87 Binary and Hexadecimal Math 87 Bitwise Operations 89 Test, Set, Clear, and Toggle 91 Toggling an Output 92 Setting the Pin to Be an Output 92 Turning On the LED 94 Blinking the LED 95 Troubleshooting 95 Separating the Hardware from the Action 96 Board-Specific Header File 97 iv | Table of Contents

I/O-Handling Code 98 Main Loop 99 Facade Pattern 99 The Input in I/O 100 Momentary Button Press 103 Interrupt on a Button Press 104 Configuring the Interrupt 104 Debouncing Switches 105 Runtime Uncertainty 108 Increasing Code Flexibility 108 Dependency Injection 109 Using a Timer 111 Timer Pieces 111 Doing the Math 114 More Math: Difficult Goal Frequency 117 A Long Wait Between Timer Ticks 119 Using a Timer 119 Using Pulse-Width Modulation 119 Shipping the Product 122 Further Reading 123 5. Interrupts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 A Chicken Presses a Button 125 An IRQ Happens 127 Nonmaskable Interrupts 128 Interrupt Priority 128 Nested Interrupts 128 Save the Context 130 Retrieve the ISR from the Vector Table 132 Initializing the Vector Table 132 Looking Up the ISR 133 Call the ISR 135 Multiple Sources for One Interrupt 137 Disabling Interrupts 138 Critical Sections 138 Restore the Context 139 Configuring Interrupts 140 When and When Not to Use Interrupts 142 How to Avoid Using Interrupts 142 Polling 143 System Tick 143 Table of Contents | v

Time-Based Events 145 A Very Small Scheduler 146 Further Reading 148 6. Managing the Flow of Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Scheduling and Operating System Basics 151 Tasks 151 Communication Between Tasks 152 Avoiding Race Conditions 154 Priority Inversion 154 State Machines 156 State Machine Example: Stoplight Controller 156 State-Centric State Machine 157 State-Centric State Machine with Hidden Transitions 158 Event-Centric State Machine 159 State Pattern 160 Table-Driven State Machine 161 Choosing a State Machine Implementation 163 Watchdog 164 Main Loops 166 Polling and Waiting 166 Timer Interrupt 168 Interrupts Do Everything 169 Interrupts Cause Events 171 Very Small Scheduler 173 Active Objects 174 Further Reading 177 7. Communicating with Peripherals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Serial Communication 181 TTL Serial 184 RS-232 Serial 185 SPI 187 I2C and TWI 189 1-Wire 191 Parallel 191 Dual and Quad SPI 192 USB 193 Considering Other Protocols 193 Communications in Practice 195 External ADC Example: Data Ready with SPI 196 vi | Table of Contents

Use a FIFO If Available 197 Direct Memory Access (DMA) Is Faster 199 External ADC Example: SPI and DMA 200 Circular Buffers 203 Further Reading 209 8. Putting Together a System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Key Matrices 211 Segmented Displays 213 Pixel Displays 215 Display Assets 215 Changeable Data? Flyweight and Factory Patterns 218 External Flash Memory 220 Display Assets 221 Emulated EEPROMs and KV Stores 223 Little File Systems 224 Data Storage 225 Analog Signals 227 Digital Sensors 229 Data Handling 231 Changing Algorithms: Strategy 232 Algorithm Stages: Pipelines and Filters 233 Calculating Needs: Speeds and Feeds 236 Data Bandwidth 236 Memory Throughput and Buffering 238 Further Reading 239 9. Getting into Trouble. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Fighting with the Compiler Optimizations 244 Impossible Bugs 246 Reproduce the Bug 246 Explain the Bug 247 Creating Chaos and Hard Faults 248 Dividing by Zero 248 Talking to Things That Aren’t There 249 Running Undefined Instructions 250 Incorrect Memory Access (Unaligned Access) 251 Returning a Pointer to Stack Memory 252 Stack Overflows and Buffer Overflows 253 Debugging Hard Faults 254 Processor Registers: What Went Wrong? 255 Table of Contents | vii

Creating a Core Dump 256 Using the Core Dump 259 Merely Very Difficult Bugs 260 Consequences of Being Clever 261 Further Reading 262 10. Building Connected Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Connecting Remotely 263 Directly: Ethernet and WiFi 265 Through a Gateway 266 Via a Mesh 266 Robust Communication 268 Version! 269 Checksums, CRCs, Hashes 269 Encryption and Authentication 270 Risk Analysis 271 Updating Code 272 Firmware Update Security 275 Multiple Pieces of Code 277 Fallback Lifeboat 278 Staged Rollout 279 Managing Large Systems 280 Manufacturing 282 Further Reading 282 11. Doing More with Less. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Need More Code Space 286 Reading a Map File (Part 1) 286 Process of Elimination 290 Libraries 291 Functions Versus Macros: Which Are Smaller? 292 Constants and Strings 294 Need More RAM 295 Remove malloc 295 Reading a Map File (Part 2) 296 Registers and Local Variables 298 Function Chains 300 Pros and Cons of Globals: RAM Versus Stack 302 Clever Memory Overlays 302 Need More Speed 303 Profiling 304 viii | Table of Contents

Optimizing for Processor Cycles 308 Summary 318 Further Reading 320 12. Math. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Identifying Fast and Slow Operations 324 Taking an Average 325 Different Averages: Cumulative and Median 327 Using an Existing Algorithm 329 Designing and Modifying Algorithms 332 Factor Polynomials 332 Taylor Series 333 Dividing by a Constant 335 Scaling the Input 336 Lookup Tables 338 Fake Floating-Point Numbers 345 Rational Numbers 346 Precision 347 Addition (and Subtraction) 348 Multiplication (and Division) 349 Machine Learning 351 Look Up the Answer! 352 Further Reading 352 13. Reducing Power Consumption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Understanding Power Consumption 356 Measuring Power Consumption 357 Designing for Lower Power Consumption 360 Turn Off the Light When You Leave the Room 361 Turn Off Peripherals 362 Turn Off Unused I/O Devices 362 Turn Off Processor Subsystems 363 Slow Down to Conserve Energy 363 Putting the Processor to Sleep 364 Interrupt-Based Code Flow Model 366 A Closer Look at the Main Loop 367 Processor Watchdog 369 Avoid Frequent Wake-Ups 369 Chained Processors 370 Further Reading 370 Table of Contents | ix

14. Motors and Movement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 Creating Movement 373 Position Encoding 375 Driving a Simple DC Motor with PWM 376 Motor Control 379 PID Control 379 Motion Profiles 382 Ten Things I Hate About Motors 384 Further Reading 387 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 x | Table of Contents

1 Erich Gamma, et al., Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley). Preface I love embedded systems. The first time a motor turned because I told it to, I was hooked. I quickly moved away from pure software and into a field where I can touch the world. Just as I was leaving software, the seminal work was done on design pat‐ terns.1 My team went through the book, discussing the patterns and where we’d con‐ sider using them. As I got more into embedded systems, I found compilers that couldn’t handle C++ inheritance, processors with absurdly small amounts of memory in which to imple‐ ment the patterns, and a whole new set of problems where design patterns didn’t seem applicable. But I never forgot the idea that there are patterns to the way we do engineering. By learning to recognize the patterns, we can use the robust solutions over and over. Much of this book looks at standard patterns and offers some new ones for embedded system development. I’ve also filled in a number of chapters with other useful information not found in most books. About This Book After seeing embedded systems in medical devices, race cars, airplanes, and children’s toys, I’ve found a lot of commonalities. There are things I wish I knew then on how to go about designing and implementing software for an embedded system. This book contains some of what I’ve learned. It is a book about successful software design in resource-constrained environments. It is also a book about understanding what interviewers look for when you apply for an embedded systems job. Each section ends with an interview question. These are generally not language-specific; instead, they attempt to infer how you think. The most useful interview questions don’t have a single correct answer. Instead of trying to document all the paths, the notes after each question provide hints about what an xi

interviewer might look for in your response. You’ll have to get the job (and the answers) on your own merits. One note, though: my embedded systems don’t have operating systems (OS). The software runs on the bare metal. When the software says “turn that light on,” it says it to the processor without an intermediary. This isn’t a book about working with an embedded OS. But the concepts translate to processors running OSs, so if you stick around, you may learn about the undersides of OSs too. Working without one helps you really appreciate what an OS does. This book describes the archetypes and principles that are commonly used in creating embedded system software. I don’t cover any particular platform, processor, compiler, or language, because if you get a good foundation from this book, specifics can come later. Who This Book Is For I wrote this for some folks I’ve worked with in the past. Sarah was a junior software engineer who joined my embedded systems team. She was bright and interested but didn’t know how to handle hardware. Josh was an experienced electromechanical engineer who needed to write software. He could power through some code but got stuck on designing the system, debugging memory issues, and reusing code. Usually we only learn software or hardware in school; we don’t learn how to make them work together. My goal is to cantilever off the knowledge you have to fill the gaps. About the Author In the field of embedded systems, I have worked on DNA scanners, inertial measure‐ ment units for airplanes and race cars, toys for preschoolers, a gunshot location sys‐ tem for catching criminals, and assorted medical, scientific, and consumer devices. I have specialized in signal processing, hardware integration, complex system design, and performance. Having been through FAA and FDA certification processes, I understand the importance of producing high-quality designs and how they lead to high-quality implementations. I’ve spent several years in management roles, but I enjoy hands-on engineering and the thrill of delivering excellent products. I’m happy to say that leaving management has not decreased my opportunities to provide leadership and mentoring. xii | Preface

After the first edition of this book, I started the Embedded.fm podcast to talk about embedded systems with other people. Through hundreds of episodes, I’ve learned how other engineers solve problems, about new technologies being developed, and other career paths. Organization of This Book I read nonfiction for amusement. I read a lot more fiction than nonfiction, but still, I like any good book. I wrote this book to be read almost as a story, from cover to cover. The information is technical (extremely so in spots), but the presentation is casual. You don’t need to program along with it to get the material (though trying out the examples and applying the recommendations to your code will give you a deeper understanding). This isn’t intended to be a technical manual where you can skip into the middle and read only what you want. I mean, you can do that, but you’ll miss a lot of information with the search-and-destroy method. You’ll also miss the jokes, which is what I really would feel bad about. I hope that you go through the book in order. Then, when you are hip-deep in alligators and need to implement a function fast, pick up the book, flip to the right chapter, and, like a wizard, whip up a command table or fixed-point implementation of variance. Or you can skip around, reading about solutions to your crisis of the week. I under‐ stand. Sometimes you just have to solve the problem. If that is the case, I hope you find the chapter interesting enough to come back when you are done fighting that fire. The order of chapters is: Chapter 1, “Introduction” This chapter describes what an embedded system is and how development is dif‐ ferent from traditional software. Chapter 2, “Creating a System Architecture” Whether you are trying to understand a system or creating one from scratch, there are tools to help. Chapter 3, “Getting Your Hands on the Hardware” Hardware/software integration during board bring-up can be scary, but there are some ways to make it smoother. Chapter 4, “Inputs, Outputs, and Timers” The embedded systems version of “Hello World” is making an LED blink. It can be more complex than you might expect. Preface | xiii

Chapter 5, “Interrupts” Interrupts are one of the most confusing topics in embedded systems: code that gets called asynchronously on events that happen inside the processor. A chicken is used to make this easier. Chapter 6, “Managing the Flow of Activity” This chapter describes methods for setting up the main loop of your system, where to use interrupts (and how not to), and how to make a state machine. Chapter 7, “Communicating with Peripherals” Different serial communication methods rule embedded systems: UART, SPI, I2C, USB, and so on. While you can look up the details for each, this chapter looks at what makes them different from each other and how to make them work more efficiently. Chapter 8, “Putting Together a System” Common peripherals such as LCDs, ADCs, flash memory, and digital sensors have common implementation needs such as buffer handling, bandwidth requirements, and pipelines. Chapter 9, “Getting into Trouble” Debugging is a skill every developer needs. Figuring out how to cause problems will teach you how to solve bugs, stack problems, hard faults, and cleverness. Chapter 10, “Building Connected Devices” Whether you have consumer IoT devices or industrial networked systems, man‐ aging many devices means dealing with firmware updates, security, and monitor‐ ing health. Chapter 11, “Doing More with Less” Optimization is not for the faint of heart. This chapter shows methods for reduc‐ ing consumption of RAM, code space, and processor cycles. Chapter 12, “Math” Most embedded systems need to do some form of analysis. Understanding how mathematical operations and floating points work (and don’t work) will make your system faster and more robust. Chapter 13, “Reducing Power Consumption” From reducing processor cycles to system architecture suggestions, this chapter will help you if your system runs on batteries. Chapter 14, “Motors and Movement” This chapter is a basic introduction to motors and movement. (Or possibly the introduction to an entirely new book.) xiv | Preface

The information is presented in the order that I want my engineers to start thinking about these things. It may seem odd that architecture is first, considering that most people don’t get to it until later in their career. But I want folks to think about how their code fits in the system long before I want them to worry about optimization. Terminology A microcontroller is a processor with onboard goodies like RAM, code space (usually flash), and various peripheral interfaces (such as I/O lines). Your code runs on a pro‐ cessor, or central processing unit (CPU). A microprocessor is a small processor, but the definition of “small” varies. A DSP (digital signal processor) is a specialized form of microcontroller that focuses on signal processing, usually sampling analog signals and doing something interest‐ ing with the result. Usually a DSP is also a microcontroller, but it has special tweaks to make it perform math operations faster (in particular, multiplication and addition). As I wrote this book, I wanted to use the correct terminology so you’d get used to it. However, with so many names for the piece of the system that is running your code, I didn’t want to add confusion by changing the name. So, I stick with the term processor to represent whatever it is you’re using to implement your system. Most of the mate‐ rial is applicable to whatever you actually have. Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program ele‐ ments such as variable or function names, databases, data types, environment variables, statements, and keywords. This element signifies a tip or suggestion. This element signifies a general note. Preface | xv

This element indicates a warning or caution. Using Code Examples This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. This book has a GitHub repository for code, tools, and pointers to more information. We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Making Embedded Systems by Elecia White (O’Reilly). Copyright 2024 Elecia White, 978-1-098-15154-6.” If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. O’Reilly Online Learning For more than 40 years, O’Reilly Media has provided technol‐ ogy and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com. xvi | Preface

How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-889-8969 (in the United States or Canada) 707-827-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://www.oreilly.com/about/contact.html We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/making-embedded-systems-2. For news and information about our books and courses, visit https://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media. Watch us on YouTube: https://youtube.com/oreillymedia. Acknowledgments This book didn’t happen in a vacuum. It started with a colleague who said, “Hey, do you know a book I can give to one of my junior engineers?” From that planted seed came months of writing; I learned to really appreciate understanding (and encourag‐ ing) friends. Then there were the engineers who gave their time to look at the techni‐ cal material (any remaining issues are my fault, not theirs, of course). Finally, O’Reilly provided tremendous support through the whole process. Thanking each person as they properly deserve would take pages and pages, so I will just go through them all in one breath, in no particular order: Phillip King, Ken Brown, Jerry Ryle, Matthew Hughes, Eric Angell, Scott Fitzgerald, John Catsoulis, Robert P. J. Day, Rebecca Demarest, Jen Costillo, Phillip Johnston, Rene Xoese Kwasi Novor, and Chris Svec. These folks made a difference in the flavor of this book. There are additional thank-yous spread throughout the book, where I got help from a particular person in a particular area, so you may see these names again (or a few dif‐ ferent ones). Finally, authors always give gushing thanks to their spouses; it is a cliché. However, having written a book, I see why. Christopher White, my favorite drummer, physicist, and embedded systems engineer, thank you most of all. For everything. Preface | xvii