After preparing a somewhat more modest presentation of what is already existing from the projects hardware and software (we now call it the prototype), we have finally taken the old “legacy” (no tests) firmware sources and made them work (without having to change anything) on the ATmega644 micro controller board we use with the prototype setup.
Still, there is so much missing but before adding more functionality to the firmware we will try to replace part by part with code that is developed in a “test first” fashion to give us a stable base to work on. But before that can happen will need to refactor some sections of the sources in order to make them testable.
Recently I have been working on my oscilloscope project. Documenting ideas, digging out requirements and restructuring the whole projects documentation wiki. While doing so I realized that the page was totally confusing to new visitors since it does not say that there is no finished scope yet (even though there is a picture of one). What one can see on the pictures is actually a prototype. Until now we did not explicitly say so. This is NOT the final thing.
To address that issue we added a Status section to the start page of the wiki that clarifies the projects state.
Now the interesting part: We created a new page for the prototype which is linked on the wikis start page and moved existing files related to the components of the prototype from /trunk to /branches/prototype-a.
Next step will be to take the legacy firmware we have and adjusted it to make it run on the prototype hardware. When the firmware is ported (basically adjust pin mappings, enable/disable functionality) we will use is as the starting point to get the code incrementally refactored until we replaced everything with test-driven code.
Found a nice article at embedded.com on how mocking can help build more robust and clear code. The article talks about development using C/C++ and the Unity unit testing framework which I have been using for quiet a while (thanks to the book “Test-Driven Development for Embedded C” by James Grenning).
Thursday this week I received my copy of “Test-Driven Development for Embedded C” by James W. Grenning. This was just the book I have been looking for months. I had the problem of developing a micro controller firmware in C but without tests. The reasons I had not started the project in a “test first” fashion were too many. Questions like “how do I test code that needs the hardware to run” as well as the limitations of only using free and open source software were and still are barriers I hope this book will help me overcome.