Feedback Driven Development

Introduction

               Over the years since the inception of computers, many different software development strategies have been theorized and put into practice. Although many different names for these strategies have been coined, they basically boil down into three camps. Agile development is a term used to describe iterative software development. Iterative development breaks the up the development cycle into sprints that usually last 1-4 weeks. After each sprint, the development strategy is revaluated and reformed, making the development process agile in that the plan is subject to change. The opposing camp uses a strategy called the waterfall model, which involves carefully planning out the software before it is written and then executed. Recently though, a new strategy has emerged which is becoming more and more popular, called Test Driven Development. Test Driven Development involves writing tests before the actual code is written, then the code is written to pass the tests. Although this strategy is cumbersome, it is very effective in reducing bugs, which can decrease development time. All of these strategies are proven effective for software engineering on computers with operating systems, however, embedded firmware development presents a number of challenges which make these strategies difficult to implement and developers often revert back to the classic “build and fix” model, whether they intended to or not.

               The biggest challenge one faces when developing embedded systems is that there is no graphical screen or console. When developing an application for a computer, a software developer gets instant feedback on whether or not their program is working correctly every time they execute the program, because the program manifests itself on the screen. A software developer can test their program simply by interacting with it and seeing if it works. However, with an embedded system, an embedded firmware developer only usually has a serial terminal. When designing a serial debug terminal to “see” into the microcontroller, firmware developers have had two options. They can simply spew all the debug information out of a serial terminal in a disorganized manner, or they can create a serial command line interface. The more complex an embedded system becomes, the more difficult it is to implement either of these strategies to gain visibility into the microcontroller. Command line interfaces are notoriously difficult to program and spewing all the information out to the screen can get extremely disorganized and confusing.

               Test Driven Development has taken hold of the software development world and is generally considered the best development strategy, because every function and discrete operation of a program is thoroughly tested as it is being developed, greatly reducing the time it takes to test a device and increasing the reliability of the program. While that sounds great in theory, it is often extremely difficult to implement in practice on embedded systems for many reasons. The first and foremost is that microcontrollers have complex peripherals and hardware that are very difficult to model in a test driven environment. Emulating a hardware device and writing a test for it can often be more difficult than writing the program itself. Furthermore, as embedded systems become complex and these peripherals and hardware are interconnected, it becomes nearly impossible to write a test that considers all of the permutations of inputs and outputs. In addition, Test Driven Development does not lend itself to good architecture that is easily updateable and repeatable.

               The...