Introduction
The Celtic Engineer is a weekly newsletter produced by Celtic Engineering Solutions. We hope you enjoy it. If you have any suggestions for topics, would like to give feedback or want your email added to the distribution list please send an email to [email protected].
Round and round we go…
Does it ever feel like you are going in circles? If you write embedded firmware, then the statement is closer to the truth than not. This week I want to talk about firmware, how is it different than software, and its role design.
To start off let’s talk about the difference between hardware and software. And I think this goes to the question of what is an embedded system. In the past, it was pretty easy to discern the difference. A coffee maker with an 8-bit microprocessor was an embedded system while your desktop was not. Today the Telephone we all carry around with us is a powerful computer. But is it an embedded system? As technology expands, it is becoming harder to answer that question. And I am not going to give you my opinion, although I would love to hear your opinion on the matter.
In today’s topic, I want to discuss a simple microcontroller with firmware written in a higher-level language like C or Python. Imagine an 8-16-32 bit mcu on a PCB. The code that is written to run on that device is firmware. Software runs on a computer and can be easily updated as needed. Firmware runs on an embedded system and usually, though not always, needs special equipment to update it. It is denoted as firm because it is more difficult to change than soft. You may not like that definition. I often differentiate the two by saying if the code is talking to an operating system it is software but if it is running the show it is firmware. Again, you may not like that definition either.
What-ch-ya doin’ down there?
In any event, we are talking about the simple case of writing code on a chip on a pcb. The code can be configured in many ways. For example, the code may be required to execute one single set of instructions each time the device is powered up. Or it might be based on a state machine where it executes code based, in part, on past events. More likely there is what is known as a main loop. This loop is code that is executed again and again. It may be executed thousands of times a second. And most of the time it does nothing! That is not strictly true. In the main loop, it is checking a series of conditions to see if anything has changed. It then executes specific code based on those changes.
Think of a receptionist who is required to sit at a desk. He must answer the phone, deal with people who walk in the front door, answer emails, make travel plans, etc. The main loop of an embedded program monitors inputs of the mcu. It checks to see if the user has sent a request, checks I2C, SPI and one-wire peripherals. It responds to interrupts. It may check a digital input. It does tasks based on timers running in the background. When it gets to the bottom of its list, it goes back to the top and starts again. That is why it is called the main loop.
Simple stuff
You might get the idea that firmware is really simple. At a very basic level it is simple, much like nuts and bolt and such are simple, but put 30,000 of them together and call it a helicopter and it’s not so simple anymore. Each line of code does a simple task but as a system it can do incredibly powerful and complex things. I was once told that the real money is in the algorithm. An algorithm is way of doing something. It may be executed in code by an mcu but it is an idea that exists separate from the code that expresses it.
Will this ever really work?
Once you realize how complex firmware can be, and then look at the complexity of the hardware it is interacting with, you might get the feeling that this system may never work. I am sure uncountable engineers and managers have asked themselves this very question. I have also sat in meetings where the firmware folks sat on one side of the room while the hardware folks sat on the other and we pointed fingers at each other for an hour.
If that sounds familiar you are not alone. It is one of the main reasons why firmware engineers learn about hardware and hardware engineers learn about writing code. The reality is, to make a system work you either need to have the hardware and firmware people sitting next to each other as they develop the code or you need someone who can do both. I don’t think you can effectively do it any other way. You simply need the ability to run experiments. You try something, grab a scope or multimeter and see if it did what you expected. If you are so specialized that you cannot cross the firmware-hardware boundary then you are impeding the process of system development. That is not to say that the two disciples must be interchangeable, but someone who can straddle the line can decide if the code is the problem or if the hardware is the problem and get to a solution fast.
All work and no fun…
Face it, we all work very hard at what we do. Each person in the team (from the janitor, through the engineers and up the management chain to the president of a company) performs a vital role. To be there day after day providing high quality work requires preparation, a good night sleep, exercise and every once in a while, a vacation. To that end, Celtic Engineering Solutions will be closed next week and no newsletter will be written. I hope you all have a great week and I look forward to the following week jumping back in and writing about another aspect of engineering.
Final thoughts
This newsletter is sponsored by Celtic Engineering Solutions LLC, a design engineering firm based out of West Jordan, Utah, which can be found on the web at: www.celticengineeringsolutions.com. You can find the newsletter on the company blog, LinkedIn or by subscribing. Send your emails to The Celtic Engineer at: [email protected].
