This past summer I had a wonderful time down in Dallas, Texas with Maxim Integrated as an intern in the Microcontrollers & Security Group. If you know Maxim, you may think primarily of analog solutions to engineering problems, but the Dallas office is actually the heart of their digital group. Besides just analog and mixed signal ICs, Maxim also offers a variety of Cortex-M series ARM microcontrollers, and my primary job function over the summer was testing and verifying the quality of the SDK provided gratis along with their hardware offerings.
Whereas when using more lightweight micros such as Atmel/Microchip’s AVR architecture machines, it is not unusual for vendors of ARM chips to also provide some low-level drivers for their peripherals, to allow applications engineers to avoid rewriting the wheel every time the core is switched out from under them. But many applications engineers out in the field (at least from my experience) seem to hold this idea that vendor code is always uselessly buggy and broken. This summer I spent the majority of three months writing test code to validate the functionality and robustness of Maxim’s SDK for their ARM micros, and I can personally say that this idea that vendor code is useless is just not true. The abstractions provided by the SDK (which you can acquire for Windows or Mac) is a solid codebase which provides a nice layer of abstraction over configuration and control registers. As opposed to more lightweight micros such as the AVR series,
Software testing and code quality first became an interest of mine after taking CS 362, Software Engineering II, here at Oregon State. That class is primarily focused with the testing and debug/validation phase of the software enginering lifecycle, although it was primarily applicable to desktop or server applications more than anything else. To that end I cracked open a book this term, Test Driven Development for Embedded C, to try and learn how to apply TDD and other mindful software engineering concepts to my usual workload of programming embedded systems.
At the end of the quarter, I created a presentation to discuss my experience with trying to apply TDD practices to ECE 473, Microcontroller Systems Design, here at OSU. The class is notoriously difficult - I can already remember Roger Traylor, the instructor, telling us not to be up until 3 A.M. the day before a lab assignment was due and not two weeks later I found myself living the exact scenario he had described. Still, I was able to learn quite a lot this quarter in both general embedded software design and by attempting to create code that was not only functionally robust, but modular enough that it could be easily testable.
Unfortunately, the code repository for this is private (don’t want to leak solutions to the lab which is 80% of the course’s grade!) and the recording of the talk was cut short (the camera ran out of memory), but the slides are freely available for public viewing here.