Earlier this year, I saw an excellent article by Jacob Beningo on EDN that provided a list of software tips for hardware engineers. It started by making the point – which those of us at Critical Link, and our customers, certainly understand – that those who design embedded systems need to understand not “just” the hardware end of things, but also how the software will work with the hardware.
As engineers, we tend to sort ourselves out – we’re hardware folks, or software folks – but in the real world, as the article points out, we are typically called upon to wear multiple hats.
That doesn’t mean that we have to become masters of every technical domain. That’s just not possible, especially in this day and age. There’s just too much to “know”, and it all changes so fast.
Still, most of us can’t go through our professional lives mono-focused on just one aspect of technology, and Jacob’s list provides some good guidelines for us hardware folks.
Here’s what’s on his list, along with a thumbnail description of his point.
- Flowchart First, Implement Second. In other words, don’t just start coding. Think things through first. The point Jason makes is that you naturally do this as a “hardware guy.” You should also do it when you put the software hat on.
- Use State Machines to Control Program Flow. Again, this is an aide to thinking things through. In this case, thinking through all the states and transitions that your code needs to cover. Interestingly, this is a variation on a theme that my colleague Tom Catalino posted on a few weeks back, when he wrote about state machine diagramming.
- Avoid Using Global Variables. This is a change in thinking from the old days when the use of globals was widespread (and recommended). With object-oriented programming, however, best practice calls for defining variables “in the smallest possible scope and encapsulated to prevent other functions from misusing or corrupting the variables.” (Think globally, code locally.)
- Take Advantage of Modularity. This approach lets you build up function libraries that can be reused, and is also helpful when it comes to maintaining and upgrading your applications. (It may take a little longer at first, but it’s good for keeping costs down in the long run!)
- Keep Interrupt Service Routines Simple. As Jacob points out, even with today’s fast processors, the overhead involved with interrupts should be kept to a minimum to that you’re not taking anything away from what the primary code is trying to accomplish. Set a flag and get out as quick as you can, and let a regular thread do the actual work.
- Use Processor Example Code to Experiment with Peripherals. Take advantage of the example code that the chip manufacturers provide. This isn’t code you can just drop into your app, but using it may help you avoid some dead ends.
- Limit Function Complexity. The more complex the tasks are, the harder it’s going to be to maintain the code. Jacob suggests using cyclomatic complexity to help you measure this. (You’ll probably have to Google that one!)
- Use a Source Code Library and Commit Frequently. This may seem like one more pain in the neck step to worry about, but version control is critical in software development. The ability to go back in and check out earlier code that works is really priceless. This can be a lifesaver!
- Document the Code Thoroughly. This is another one of those pain in the neck steps, but unless you have a perfect memory for what was going through your mind when you were doing your coding and you’re going to be the only person who ever has to upgrade and maintain it, documentation is essential. When I was young, I could look back at undocumented code I wrote and it was like I just wrote it. Nowadays, I know those comments are for ME!!
- Use an Agile Development Process. In software development, that means focusing on the highest priority tasks first, and having an iterative development process. This lets you adapt more quickly when requirements change. (Not that THAT ever happens…).
There’s a final point on Jacob’s list, which recommends that you keep on top of the latest tools and techniques. Good advice whether you’re developing hardware, software, or both.
The full article is definitely worth reading. Here’s the link.