Instead of moving data around through functions calls -- which are (relatively) easy to trace -- globals are a kind of wormhole from one part of the application to the next. A wormhole where anything can jump in and change the behavior of the application.
Over the years I've worked in and with many different firmware organizations. In my experience most people are really trying to do their best but I see many struggling with the same, common problems of organizational maturity.
When an organization is mature it makes disciplined use of best practices and tools to regularly and continuously deliver high quality firmware.
When an organization is immature, things are done in an ad hoc (often reactionary) way. Successful results are not easily repeatable and it is often the responsibility of just one or two individuals to try to hold it all together.
How do you know when code is good or bad? Or complicated or simple? Chances are you know it when you see it, but that isn’t very quantifiable.
I find that some simple software metrics can help with this. In particular, metrics can help identify the most complicated areas of the code. This is useful in a few different situations.
Before I started working with Jenkins, I had heard about it — and I knew that people used it to do something useful. However, I didn't really understand what Jenkins does or how it works.
Also, there is quite a bit of Jenkins documentation around but I've found that a lot of is out-of-date and didn't apply to me and my needs for embedded software development.
In this article I'll explain a bit about what Jenkins does, how it works and why you might want to think about using it — particularly for your embedded software projects.
When building embedded systems, there are typically at least a few specialized tools required. This includes things like the build tool, cross-compiler, unit test tools or documentation generators.
Getting all of these things set up on your machine can be tedious. And then when it's time to bring someone else on to the project, setting up the build environment just takes extra time.
I've written before about the how to configure Ceedling to run unit tests with an existing project. But after you have your unit test tools set up, it can still be difficult to figure out how to start writing tests. Code that hasn't been designed to be unit tested can be especially difficult. Here a few tips to help you out.
Assert statements are a great tool for programming defensively. This is especially true in embedded systems where we don't typically have a lot of user interface to help our users figure out an error. Often it's better to crash or reset the application programmatically than risk executing the code in and undefined state. But how do you write unit tests for code that can assert?
Including mocks in your tests means that those tests know a lot about the internal implementation of the unit under test. Make a change in the interface of any mocked module, and you not only drive changes in every caller of that interface, you create a cascading series of changes in the tests for each of those callers as well.
Because tests that rely on mocks are prone to breakage, or brittle, they're an active disincentive for making changes to existing code. You're forced to either update the tests with every change you make, allow the tests to break and lose the benefits of unit testing, or just avoid making changes to the code.
It's super useful to write and test embedded software... but hardware interfaces can be tough.
How do we write code that needs to access hardware, without it?
For most of my time as an embedded software developer, I almost exclusively wrote code that was going to be run on some microcontroller. I'd fire up the IDE, crank out some code, download (this often took a couple minutes) an run. Then I'd somehow try to figure out if what I had written was correct.
Unit testing is great for verifying the behavior of individual modules, but how do you put those modules together in a way that makes things testable?
One of the most useful ways I've found to do this is to think about the system in terms of events.
This is the second of a three video series to show you how to quickly get started with Ceedling, by test driving a simple "FizzBuzz" example.
In this video we test drive a simple FizzBuzz example in C -- writing the tests as we go -- and using Ceedling to run the tests.
This is the first of a three video series to show how to quickly get started with Ceedling, by test driving a simple "FizzBuzz" example.
In this video we introduce our example problem, create Ceedling project, create a source code module (easily using Ceedling!) and look at how to run the tests.
Have you tried to use Ceedling recently, but got this error when you tried to run rake?
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
Do your embedded applications ever save any data to flash memory (aka EEPROM)? This where you typically store non-volatile information that needs to preserved if the device is powered down.
This sort of thing is tough to test in the traditional way -- by loading code onto the target and running it -- because it's hard to set and _re-set_ the data in flash for testing. It can also be harder to inspect the data when it's in flash memory.
I don't know about you, but a very natural way for me to think about designing embedded software is from the "outside in". I've been thinking about this a bit recently, and I'm not so sure that's the best approach.
So you write embedded software in C and you think that unit testing might help you do it better. You already know about creating well-defined software modules and how this makes it easier to write unit tests. But what else can you do to make these modules easier to test? What are some more coding patterns that make unit testing easier?
So you write embedded software in C and you've read about unit testing. You think unit tests will help you write better software, but how do you actually write code that's testable? What are some coding patterns that make unit testing easier?
You want to try unit testing your embedded software but there's a problem -- you've got an existing project and a whole lot of code already written. Maybe it's even embedded legacy code.
If you want to do embedded test-driven development (TDD), running your automated unit tests on the target is too slow. When you're test-driving, you're running the tests very frequently. You will not want to wait for the tests to download to the target. It will disrupt your flow and you'll get more easily distracted.
I've created a plug-in for Ceedling which lets you use the Fake Function Framework (instead of CMock) to automatically create the mock interfaces used in your unit tests. You can find the plug-in (along with complete instructions for how to use it) in the GitHub repository.
Do you write embedded software? Looking for an introduction to unit testing?
I've written a bit of an introduction to unit testing, especially for embedded systems developers.
Catch is a unit testing framework that has some interesting (better!) ways to write tests for C and C++.
Instead of naming your tests with function calls, you can write your tests as a nested series of Given-When-Then statements.
Did you know you have options when it comes to creating mocks for your C-language unit tests?
I've been spending a lot of time working with CMock -- since it's used by Ceedling -- but I've just been checking out FFF (the "fake function framework"). It's well done and I think it deserves a closer look.
How can you unit test your embedded software? What about your hardware dependencies?
The secret is mocking.
We can mock the interfaces to our hardware so that we don't need the actual hardware to test.
The first principle behind the Agile Manifesto is:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
It's the highest priority! This has got to be really important, but why? What good is delivering software that can't do everything the customer wants? Well...
If you're on board with unit testing, but not quite sure about test-driven development, I want to share my experience for why I think writing the tests first is the way to go.