Will work on the timer driver code (legacy and fresh one) to allow selection of the actual hardware timer to use (the on-chip ones that are part of the ATmega series micro controllers).
Yeah! We have finally managed to fix some stupid things, related the the firmware used for our lzoDSO scope. There where files missing (which had been referenced by the Makefile but where outside of the projects repository) and loads of files in either the wrong place or simply cruft.
The files have now been added (which should allow anyone to build the firmware) and things have been cleaned up slightly. There is still much work, so be sure you will find spots in the source that have a smell. I have also documented the fuse-bits that are configured in the micro controller used.
Ah .. note, after having the missing files in the project, these “sub-projects” have their own dependency which is CppUTest in that case (this is a dependency to be proud of I think). So make sure you have CppUTest on your machine and your users environment set up with the corresponding variables (see the Software page in the lzoDSO wiki for details on how to setup the build environment).
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.
Enough for today…maybe
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.