When TDDing embedded systems it becomes very handy a tool that helps not only to automate the process, but also to mock the hardware. One can find lots of TDD frameworks, but what makes Ceedling awesome is the fact that it looks and writes the mocks in an automated fashion.
However, I have one complain: Why such a great tool lacks of good documentation? The Ceedling creators just say “look at the documentation”, and it has been very hard to find a good tutorial or so. And the forum is far to be helpful. So, based in what I found, and with a lot of trials and errors, I was able to integrate this tool with a project I’m working on right now. You might want to take a look to this site which is a good start point. By the way, I bought the on-line book that these guys sell, and it worths nothing. But if you are planning to buy a book for TDDing embedded systems, then I’ll strongly recommend you this one: Test Driven Development for Embedded C. It worths every penny.
What you’ll find easily is how to download and install Ceedling, so I’ll skip those steps, and I’ll focus in tweking in for our own purposes instead. The blog’s title says “… and some thoughts”, so here are my thoughts regards TDD and Ceedling:
- TDD tests modules, no applications. When I started TDDing I wanted to test my whole applications, a clear symptom that I had missundertood what TDD is. That’s way I couldn’t figure out how to integrate TDD in embedded systems. Now I know that I must split my application into submodules, and apply TDD to each one of these, whether they are related to the hardware or not.
- Mocking helps us to pick the best programming approach when writing our applications: Top-down or Down-top. In the former we start from the big picture, and then we walk down one abstraction level each step. In the later we start from the hardware and walk up one step abstraction level, until we reach the big picture.
- When writing embedded applications we use a compiler for our specific hardware: ARM Cortex, ARM7TDMI, PowerPC, and so on. For speeding our efforts it’s better off to use a cross-compiler, like the GNU-GCC. The question here is: How we can test our modules/application in the PC environment? The most obvious answer is to use an emulator/simulator for that specific processor. And what if we don’t have one? Another approach is to compile and run the modules/tests/application on the PC environment. In order for this idea to work as expected is that our modules must be loosely coupled from the hardware (and from the other modules as well), and from time to time, to run the modules/tests/application in the real hardware. However, sooner or later, it will be mandatory to start programming the hardware, and it is right here where Mocking tools are very handy.
In the next delivery I’ll show you how to integrate the Ceedling tool to our programming workspace (mostly for Cortex-M0-M3 processors, GCC- based toolchains, and Eclipse environment). This is not a difficult task, but is very tricky, indeed. Meanwhile your comments are appreciated.