It’s official! My latest book Embedded Software Design has been released in paperback and electronically! In an earlier post, Book: Embedded Software Design, I provided a little summary about the book and the chapter break down. In this post, I want to tell you a few options on how you can read it, and share a few thoughts about what I think is interesting about it.
Where to Read Embedded Software Design
There are a couple of ways that you can read Embedded Software Design. First, if your company has access to the O’Reilly membership, you can simply login and search for Beningo. You’ll see the books I’ve published so far, and Embedded Software Design will be one of them. You can just download the book and then read it at your own leisure.
Alternatively, you can pick up the book in either paperback or electronic format at Amazon.
A Bonus for Reading the Book
On January 25th, 2023, I am going to host a webinar on Embedded Software Design. We’ll discuss the book, and I’ll leave time at the end to answer questions and give some guidance on potential next steps.
A Sneak Peak
Chapter 13 – Configurable Firmware Techniques
By the age of 40, I had the opportunity to review and write code for over 150 firmware projects. One thing that I’ve noticed about firmware projects is that developers rarely write their code in a configurable manner, even if it is warranted. Don’t get me wrong; I’ve seen a lot of progress towards layering architectures, managing coupling, cohesion, and trying to maximize reuse. Unfortunately, however, I’ve seen a lot to be desired regarding configuration.
I’ve seen many projects with similar elements and behaviors yet entirely written from scratch for each project. The use of configurations could simplify so many embedded projects, yet many developers are stuck recreating the wheel repeatedly. The projects I see that use configurable firmware techniques often leverage copy and paste and the core mechanism to prepare configuration files. Obviously, this is not very desirable since copy and paste due to a developer not updating a line of code. (Interruptions in the office, a phone call, or just the mind drifting can cause a slip up).
This chapter will explore configurable firmware techniques I’ve been using in my code for over a decade. I’ve blogged or spoken about some of these techniques, but this chapter will go further behind the curtain and demonstrate how you can write configurable firmware that is also autogenerated. I’ve used these techniques to write code that is not just configurable but also created at an accelerated rate. Due to the maturity of my scripts and techniques, they don’t easily fit into this chapter, so I’ve streamlined them to give you the core idea, the technique you can use for your firmware.
You are going to learn in this chapter how to write code that is configurable through configuration tables. These tables allow you to write reusable, scalable, and configurable code for many applications. Those tables can also be generated using configuration files and scripts resulting in your application’s C modules. Let’s get started!
If you are writing firmware and embedded software, I think that you will find the content of Embedded Software Design interesting. There was much more I would have liked to include in the book, but as is it is nearly 500 pages in length.
My hope is that those of you who take the time to read it will learn a few new techniques, be inspired to change how you write your embedded software, and will transform the companies you work for. Modernization can be a big challenge, and the book doesn’t cover how to go through that process, but it gives a lot of hints and ideas about what modern embedded software design and development should look like.
This looks like an excellent book. Re: the idea of configurations in firmware, years ago I was using function pointer tables that would be indexed by configuration parameters. Or even to implement complex State machines. Nowadays uml generates perfect State machine code and most people should look into using those.
Thanks for the comment.
I definitely agree that people should be leveraging tools like UML to do as much as possible for them. Unfortunately, the low-cost tools often generate code that is not easily read or maintained. Things will continue to improve though. It’s far better than it was just a decade ago.