Question

I’m currently in the process of writing a state machine in C for a microcontroller (a TI MSP430). Now, I don’t have any problems with writing the code and implementing my design, but I am wondering how to prove the state machine logic without having to use the actual hardware (which, of course, isn’t yet available).

Using debugging features, I can simulate interrupts (although I haven’t yet tried to do this, I’m just assuming it will be okay – it’s documented after all) and I have defined and reserved a specific area of memory for holding TEST data, which using debugging macros, I can access at runtime outside of the application in a Python script. In other words, I have some test foundations in place. However, the focus of my question is this:

“How best do I force a certain state machine flow for decisions that require hardware input, e.g., for when an input pin is high or low”. For example, “if some pin is high, follow this path, otherwise follow this path”.

Again, using debugging macros, I can write to registers outside of the application (for example, to light an LED), but I can’t (understandably) write to the read-only registers used for input, and so forcing a state machine flow in the way described above is proving taxing.

I had thought of using #ifdefs, where if I wanted to test flow I could use an output pin and check this value instead of the input pin that would ultimately be used. However, this will no doubt pepper my codebase with test-only code, which feels like the wrong approach to take. Does anyone have any advice on a good way of achieving this level of testing? I’m aware that I could probably just use a simulator, but I want to use real hardware wherever possible (albeit an evaluation board at this stage).

Answer 1

Sounds like you need abstraction.

Instead of, in the “application” code (the state machine) hard-coding input reading using e.g. GPIO register reads, encapsulate those reads into functions that do the check and return the value. Inside the function, you can put #ifdef:ed code that reads from your TEST memory area instead, and thus simulates a response from the GPIO pin that isn’t there.

This should really be possible even if you’re aiming for high performance, it’s not a lot of overhead and if you work at it, you should be able to inline the functions.