Preface:I love embedded systems. The first time a motor turned because I told it, 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 patterns. I love embedded systems. The first time I made a motor turn with my commands, I was completely fascinated. I quickly transitioned from the field of pure software to one that allowed me to engage with the real world. Just as I was about to leave the software domain, a seminal work on design patterns was completed. My team went through the book, discussing the patterns and where we’d consider 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 implement the patterns, and a whole new set of problems where design patterns didn’t seem applicable.Our team carefully studied that book, discussing various patterns and the scenarios in which we could consider applying them.As I delved deeper into the field of embedded systems, I discovered that some compilers could not handle C++’s inheritance mechanism, and some processors had ridiculously small memory, making it impossible to implement these design patterns. I also encountered a series of new problems where design patterns seemed inapplicable.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. So 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.But I have never forgotten that there are patterns in the way we engage in engineering.By learning to recognize these patterns, we can repeatedly apply these reliable solutions. Therefore, much of the content in this book explores standard patterns and provides some new patterns for embedded system development.Additionally, I have supplemented several chapters with many practical insights that are not found in most books. About This Book:After seeing embedded systems in medical devices, race cars, airplanes, children’s toys, and gunshot location systems, I’ve found a lot of commonalities. There are a lot of 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 good software design in resource-constrained environments.After encountering embedded systems in medical devices, race cars, airplanes, children’s toys, and gunshot location systems, I found many commonalities. There are many things I wish I had known earlier about how to design and implement software for an embedded system. This book contains some of what I have learned; it is a book about excellent 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 divine how you think. Good interview questions don’t have a single correct answer. Instead of trying to document all paths, the notes after each question provide hints about what an interviewer might look for in your response. You’ll have to get the job (and the answers) on your own merits.This book also explores what interviewers value when you apply for a job related to embedded systems. Each chapter ends with an interview question. These questions are generally not specific to any programming language, but rather seek to explore your thought process. Good interview questions often do not have a single correct answer. The notes following each question do not list all possible answers but instead hint at what the interviewer might hope to see in your response. Ultimately, whether you get the job (and provide ideal answers) depends on your own abilities.One note, though: my embedded systems don’t have operating systems. Their software runs on the bare metal. When the software says “turn that light on,” it says it to the process without an intermediary. This isn’t a book about an embedded operating system (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.However, one point needs clarification: the embedded systems I deal with do not have operating systems. Their software runs on “bare metal“. When the software issues the command “turn on the light,” it sends it directly to the processor without any intermediary. Therefore, this book is not about embedded operating systems (OS). However, the concepts discussed are also applicable to processors running operating systems, so if you can read on, you might also learn about the underlying mechanisms of operating systems. Working in an environment without an operating system allows you to truly understand the role of an operating system.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.This book elaborates on the typical patterns and fundamental principles commonly used in developing embedded system software. I will not cover any specific platform, processor, compiler, or programming language, because if you can establish a solid foundation from this book, those specific details can be learned later.
References:
[1]. “Making Embedded Systems” by Elecia White. Southeast University Press.
Click the following business card to follow this public account:：