There are a lot of books available to tell you all about the theoretical side of designing and building embedded systems, but not so many that tackle the nitty-gritty details involved in developing embedded systems that actually work and keep on working, until now…
When I was a bright-eyed, bushy-tailed young lad poised to spend the next four years of my life slogging away to earn my hard-fought BSc in what they used to call Control Engineering — which boasted a core of math accompanied by electronics, mechanics, and fluidics/hydraulics (“One Engineer to rule them all,” as J. R. R. Tolkien might have written, had he not been waffling on about Middle Earth) — there were two main options open to me.
The first option was to pursue a more academic path, focusing on the theory but largely neglecting the practical side of things. To be honest, I’d had theory up to my ears the previous year after foolishly enrolling in an electronics course based on advice from the career counsellor at my high school.
CC: Is there anything you like to do?
ME: I like building electronic gizmos that make annoying noises.
CC: Is there anything you want to do?
ME: I’d like to work on rockets and/or robots.
CC: Sign up for a BSc in Electronics at the university… NEXT!
Unfortunately, this degree turned out to be almost totally focused on theory. I spent more time than a young man should calculating esoteric equations that promised to reveal strange truths regarding the angular momentum of electrons. Sad to relate, the only thing these equations really revealed was that I had no interest whatsoever in knowing the angular momentum of electrons, even though I’m obliged to carry so many of the little scamps around with me wherever I go.
After a year of this, I prostrated myself on the floor at the feet of my course advisor (I have no idea why he insisted we all greet him in this manner) and asked if this were all life had to offer. When I explained that I actually wanted to use electronics to build things like spaceships and killer robots, he informed me that the Control Engineering course was the way to go.
Happily, this new course also involved the second option, which combined classroom-based education with practical work experience. This is called a co-op course in the USA, but we called it a “sandwich course” in the UK. Actually, it was more of a Dagwood sandwich course, because it involved multiple layers of practical work sandwiched between layers of theoretical study.
In fact, there were two different types of sandwich course – a “thin sandwich” (six weeks in university followed by six weeks out in the real world, and then keep on repeating for the next four years) and a “thick sandwich” (two six-month periods in industry during the course of the four-year degree).
I should, perhaps, also point out that this was nothing like the way things are in the USA where your goal is to get a bunch of credits and you can largely pace yourself. In the UK at that time (I don’t know how they do it now), everyone went into the course at the same time and stuck together like a bunch of grapes through every twist and turn over the next four years. The entire course was totally orchestrated — if you learned how to manipulate matrices in math class in the morning, you could bet your little cotton socks you’d be using the little rascals (the matrices, not your little cotton socks) to solve circuit calculations in the electronics class in the afternoon.
My first six-month stint in industry was spent taking an apprenticeship course at a Rolls Royce aerospace factory. This was, itself, a four-year course that had been boiled down to six months for us students, and it covered the hands-on-use of mills, drills, lathes, grinders (of all shapes and sizes), welding (oxyacetylene, electric arc, argon arc), and lots of other cool stuff. My second outing was to the research and development facility for a glass company. As part of this, I ended up co-supervising the installation of the instrumentation and control room in a glass factory that was in the process of being refurbished. I say “co-supervising,” but after the first week my boss disappeared on vacation and left me in charge. All I can say is “I saw things you people wouldn’t believe” (to paraphrase Roy Batty’s epic “Tears in Rain” monologue) and “That’s all I have to say about that” (to channel Forrest Gump).
The end result is that this sandwich course made me the man I am today, but that’s really not their fault (they tried their best), and I hold no one to blame.
Moving on… there’s a world of difference between making a one-off device or system versus taking the little rapscallion into production. When I was a young lad, my parents paid for subscriptions to Practical Electronics and Practical Wireless magazines for me (here’s a link to the May 1973 issue of Practical Wireless, which hit the streets on the month I celebrated my 16th birthday). Many of the projects in this magazine were contributed by readers who created the original using components from their treasure chests of bits and pieces. As a result, the magazine was obliged to include a special section to help readers track down obscure or hard-to-find parts. Much the same thing applies to designing an embedded system — you don’t just select the first part that comes along and that looks “good enough”; instead, you check a bunch of things, including that this part isn’t poised to become discontinued and ensuring that you will have a batting chance to be able to source enough for the entire run (always assuming you aren’t hit by a worldwide pandemic that disrupts your supply chains, of course).
I’m also thinking of myriad Kickstarter projects that succeed beyond their founders’ wildest dreams with regard to funding, and then crash-and-burn beyond their wildest nightmares when it comes to producing the artifact in question in large quantities.
All of this leads me to a forthcoming book written by my chum, Adam Taylor, and his chums, Dan Binnun and Saket Srivastava — A Hands-On Guide to Designing Embedded Systems — which is scheduled to appear on the market at the end of October 2021, and which is available for pre-order here. Yes, I know it’s not cheap at $149, which is certainly out of the reach of my pocket, but — when you come to think about it — this is a negligible amount when compared to the cost of an embedded system design that is so awful it fails to see the light of day.
This is a book that truly does take you through the nitty-gritty aspects of the hardware portion of the design (we’ll talk about the software side in a moment). In addition to covering all the things you’d expect, the book drills down into things like defining and capturing the requirements, architectural design, engineering budgets, interface control documents, verification plans, and engineering governance.
With regard to hardware design considerations, the book covers such things as the hardware architecture, component selection (including a whole section on why and how to derate the components), system design, system integrity in all its forms, and test (and test and more test). Since Adam is one of the few people I know to successfully (and intentionally) have his FPGA-based designs launched into space, there’s a huge amount of material on the topic of reliability, including how to perform worst-case analysis and how to evaluate the reliability of the system.
Now, this is where things start to get interesting. As part of all this, the authors take us on the journey of an imaginary team of engineers at a make-believe company called SensorsThink as they develop a new embedded systems platform. The thing that differentiates this tome from others of its ilk is that Adam, Dan, and Saket actually designed and built the platform they describe in the book. In the not-so-distant future, this board will be available for purchase to complement the book and to provide a platform to develop the software side of things.
The SensorsThink board (Image source: Adam Taylor)
Powered by a Xilinx Zynq 7020 SoC FPGA (an FPGA with a dual core 32-bit ARM Cortex-A9 processing system running up to 766 MHz), this board includes a 3-axis accelerometer, vibration sensor, magnetometer, temperature sensor, humidity sensor, and a FLIR thermal sensor. Connectivity options include 1G Ethernet, Wi-Fi, Bluetooth, USB host, and USB UART for debugging.
The chaps were kind enough to send me a board to play with. Below we see it sitting on my desk surrounded by a trio of admiring fans.
The SensorsThink board on my desk (Image source: Max Maxfield)
Just a few minutes ago as I pen these words, I had a Zoom call with Adam where he walked me through the process of powering-up the board (by default, it powers up with a Linux operating system that includes a Python interpreter) and using a terminal window on my PC to set things running, connect to the Adafruit cloud, and start uploading temperature readings from my office.
The board design itself is open source. Once the book launches, there will be an associated website from whence readers will be able to download all of the design files, including the schematic and PCB layout for use with Altium 365.
This site is also where the software aspects of the system will be covered. As I just noted, the board comes with the Linux OS by default, but the authors are going to show us how to use different builders and customize the OS to suit our specific requirements. As opposed to Linux, they are also going to show us how to load different real-time operating system (RTOS) products, including FreeRTOS, from different vendors. In the meantime, Adam has a host of blogs he’s written on Smart Sensor IoT, many of which already feature this board.
Where things start to get really exciting is that Adam, Dan, and Saket ended up taking their make-believe SensorsThink company from the book and registering it as a real corporate entity, thereby providing them with a vehicle to develop more real-world products in the future.
I was just struck by a funny thought. Wouldn’t it be weird if SensorsThink took off, eventually becoming a multinational company? Even weirder, you and I could end up working there together one day. You may laugh, but “stranger things happen at sea,” as my dear old granddad used to say, and he should know because he served in the British Royal Navy, man and boy (see The Times They Are a-Changin’). So, over to you — do you have any thoughts you’d care to share on anything you’ve seen here?
One thought on “A Hands-On Guide to Designing Embedded Systems”
Ha, I too was born in 1957 and my career councillor gave the same advice and, like you, I hated all that theory; I wanted to make things.
I hope CCs today look deeper into matching the candidate with the course.