He makes the point that business logic must be decoupled from technological implementation dependencies very nicely. This wisdom is nothing new but still you don’t see it used very often in the real world (sadly).
My conclusions from this reading are basically:
firmware should be designed with a systems software aspect in mind (not application software)
decouple any business logic from implementation technology (okay, this is an obvious one)
I think especially the first point is one I’ll be able to apply to my prototype scope firmware.
After watching the rant from Dave Jones (from the EEVblog) in his car expressing his opinion on DIY micro controller-based oscilloscopes one might think there is no merit to building such a device. Well, in my opinion there is! Okay, Dave also made this point clear: it is okay to build one for getting your feet wet in the electronics and embedded systems domain. Which is exactly what I am doing.
To further address the criticism of Dave by saying that those DIY scopes usually do not have any thought put into the analog front-end (AFE) or the trigger section. In general I’d approve his observations.
So why is the lzoDSO not going to be a simple DIY scope? Because we actually want to delve down into the dirty details of constructing an AFE and a trigger section that act just like the ones an electrical engineer would expect from a typical digital storage oscilloscope.
Even though these are two of the paramount parts of an oscilloscope, first we will bring our prototype to a state where it can be helpful in evaluation the design of an AFE and a trigger section.
UPDATE: As Dave suggested I started asking around for someone who might pass me his old oscilloscope. If you have one you want to pass on to someone who will gain from even an old analog or digital device: please contact me (see contact) and maybe I can compensate you in one way or the other. Anyways, don’t think this will stop me from continuing to work on the lzoDSO.
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.