Modernizing the microcontroller laboratory with low-cost and open-source tools

Abstract

Instructors in the area of embedded systems face an ongoing struggle to incorporate current design and development techniques into their laboratory exercises. In addition to the difficulty of keeping pace with technological advances in the field, a significant investment is often made in the design tools and development boards with the expectation that these costs will be amortized over five years or more. Fortunately, a number of microcontroller manufacturers have adopted the IEEE 1149.1 Standard Test Access Port, more commonly known as a JTAG interface, to facilitate programming and debugging their processors. Software development tools have also begun to converge into a collection of open-source point tools, such as a compiler and assembler, that are managed by an open-source integrated development environment. As a result, instructors can easily provide a sophisticated development environment for embedded systems using tools and techniques very similar to those used in industry, supporting a variety of microcontrollers for less than the cost of a typical textbook. We have used such a development environment in a microcontroller systems design course for second-year students in Electrical Engineering and Computer Engineering, using ARM Cortex-M3 microcontrollers. Our students are able to program the microcontrollers in both C and assembly language, or a combination of the two. We use the GNU debugger, gdb, with a commercial high-speed USB-to-JTAG interface and a low-cost development board. Students performed all of the essential development tasks, writing their programs, compiling them, and debugging their code, from within the Eclipse integrated development environment. We found an important pedagogical benefit accrued from using this tightly integrated development environment, in that students were able to learn and practice more sophisticated debugging techniques. They are generally accustomed to programming on a conventional computer where the interaction between the software and hardware is just an abstract notion. When programming embedded systems, this interaction often leads to programming errors and the students' previously learned debugging techniques are of little help. The instructor may suggest that the student insert instructions to light an LED at certain points in the program, or add print statements to send messages to a terminal. Unfortunately, this is a tedious method that forces the student to modify and recompile their program repeatedly and may introduce its own errors. In some cases, the student may be able to use a software simulation of the microcontroller, but these simulations have a limited ability to simulate hardware beyond the microcontroller itself. In our microcontroller laboratory, students use graphical tools to add breakpoints or single step through their code, either by C program line or assembly instruction. The contents of all processor registers, C variables, and specified memory addresses are automatically updated and can be displayed in a number of useful formats. As a result, students clearly see the connection between the C program, the compiled assembly version of the same program, and their interaction with the processor and other hardware resources. © 2012 American Society for Engineering Education.