So, I am currently researching ways of establishing a workflow for developing my hardware sequencer firmware. As someone who largely did web programming in rails during the last few years, I try to follow a few best practices, such as test-first, using automated tests and so on. Turns out that this is not too usual in the embedded world. Writing unit tests for largely procedural code is not really easy and using ASM for performance reasons doesn’t improve the situation. The situation usually is this: Your code for the Microprocessor is largely untested, simply because there are no clear, good interfaces to test against. There might be exceptions (such as general purpose conversion procedures) but most of the code blocks will involve some form of hardware trickery that cannot be tested in isolation. Ergo: Finding ways to Unit-Test my firmware code will be hard to impossible in most cases.
There’s this one, very well defined interface, though, that just comes naturally with a microprocessor: The actual output pins. Now, having to create a hardware test harness for this kind of testing would involve a lot of additional hardware tweaking, building a test system, most certainly involving another microprocessor, instantly creating a very beautiful hen and egg problem.
So that’s why people write simulators. The only problem I see so far: Maybe I’m not looking hard enough but I can’t find a good way to connect to a tool like simulavr and doing the kind of tests I have in mind. It is more thought of as a way to debug your software using gdb or Insight and less of a way to actually to testing in an automated way (But I’ll have to double check on that: Documentation on simulavr is not exactly spectacular…)
So yesterday night I had a very crazy idea: Why not trying to implement the AVR instruction core in ruby. This doesn’t need to run in real-realtime: It only needs to be cycle-precise in a sense that I could say things like “pull pin 5 low, wait 5 cycles, see if the button input did have any effect”. I could imagine doing very low level, almost Unit-Test like things like doing assertions on looking up values in memory, but also very high level things like writing a simple emulation of an LCD display and beeing able to bind that simulation to a few pins and then checking the output result.
I mean, how hard can this be? The instruction set is not that complicated (it is RISC after all), the timing is simple and complex interfaces like i2c, SPI, UARTS, PWM-Outputs etc. could probably be faked away to reduce the complexity of the emulator.
