Don’t take this one too seriously. Still trying to drain the swamp with dragons and crocodiles up to my elbows. We do test our code! We recommend you avoid code walkthroughs with dragons, or at least make them cut their toe nails if approaching the source code from opposite sides of the table — take a look at what we mean in the picture to the right.
I have often developed code from scratch, forever conscious that in the long term somebody else would need to maintain it. Either this was a project for a customer to commercialise or as a subcontractor. I have personally never been in a “code walk through” exercise, and don’t think they work due to the strange personalities required for software development. Pretty confident of their skills and in a hurry to get to the deadline, there is no time to engage in looking at code that was already “tested”.
Take a look at the modern Blogs and comments that degrade into diatrabe and flaming, or your last meeting where people either limit comments to avoid career damaging moves but never solve a problem, or move so far over the edge that little can be rescued. Code walkthroughs are even more delicate, so for our code, you can conduct your own walkthroughs and highlight where changes should be made. We comment extensively, so reviews should be possible without the original developer present.
We write small pieces of code at a time and test with a source level debugger. For “real-time” code, this does not work. Neither for multithreaded Linux code, as the debuggers are too stupid to be clairvoyant and know which thread you are going to want to attach to. For real-time, as you halt a section, the rest of the world flies by, and in some cases, the processor clock interrupt is disabled via the JTAG pod by the host debugger.
Tracing was proposed for PowerPC work and FPGA based cores, however, trace probes are expensive for very short frames. We write values into arrays in memory that can be read out later. For small micro-controllers, even 128 kBytes of RAM is not much when supporting an Ethernet and CAN stack. For multi-core, one core can be dedicated to debug and scheduling.
We had hoped that the Xilinx ZYNQ FPGA ARM cores could be accessed for tracing via the fabric, or trace into on-board memory that can be accessed like standard memory (much like the Atmel AVR32). A testbed is an elusive target, but unfortunately required to make any meaningful WCET measurements or multi-core work. It unfortunately involves custom design which tends to cost more than initial estimates — often by a factor greater than 2!
Embedded code takes longer to write than typical desktop applications. Much of this time is taken to debug the target as once deployed, there is nobody out there to press a reset button on a malloc() error. We are happy to discuss your testing and code coverage requirements.
© 2011—2014 — Second Valley Software Pty Ltd. All Rights Reserved