Tools to help real-time embedded programmers learn their trade

Over at The Engineer the debate about "should everyone be a programmer?" rages on. I thought hard about this today in the context of our own work, and concluded that a large part of the difficulty and the skill of programming comes from the disconnect between the text of the program and the behaviour of that program. Just as the text of a recipe isn't the same as cooking the meal, reading program source code requires some imagination to think about what the program will cause the computer to do. This is where good documentation, function names and variable names and well-designed APIs bear fruit, helping the programmer to quickly build a mental model of the computer's behaviour.

One of the benefits of analysis tools like RapiTime is that they intrinsically relate the static program text to the dynamic behaviour of the program. The on-target instrumentation captures a trace of execution history during actual test execution, and the entries in the trace correspond to specific positions in the source code. We track execution context - the complete call stack to reach the subprogram - to distinguish different execution paths that lead to the same code. With Rewind View we tie this all together by showing the trace position and source code position along with the execution stack, and allowing the user to step forwards and backwards to animate the static view into specific instances of the dynamic behaviour. This allows the user to try things out and get immediate feedback on what’s happening, which is useful both for learning and for diagnostics.

Our upcoming product plans include a more advanced trace visualisation offering. In this view, the trace is indexed not by trace position as in Rewind view, but by the passage of time. Things that take longer look longer. Things that interrupt or are called explicitly are shown taking over execution and then handing it back. We can compare different instances of the same function execution and visualise their differences. A graphical visualisation also gives the user a visual pattern with which to spot desired, expected and unexpected patterns of behaviour.

Perhaps in the future we will be able to peer directly into the black box of the processor and fully experience what's happening, nanosecond by nanosecond. Until then, automated instrumentation provides a valuable way to relate the actual behaviour to the pages of program source code on the screen. Whether you’re just starting out in programming or you’re a seasoned professional, such insight is fundamental to the creation of safe and reliable software.