A New Perspective on Teaching Embedded Systems Design - Embedded.com

A New Perspective on Teaching Embedded Systems Design

A little over a year ago, after having been an embedded systems designer and a manager of embedded developers for the last twenty years, I realized that what I wanted to do was what I had trained to do originally: teach engineering.

Since what I knew best was embedded systems design, I decided to develop classes around that discipline. I started to surf the Web, looking at what other faculties were doing around the country and around the world. I also collected some of the books that have been written by people in the field with whom we're all familiar. However, I kept coming back to a conversation I had with a manager at an HP division who was responsible for the development tools used by his R&D lab. He told me that he really needed someone to teach his new hires how to design an embedded system – not the electrical engineering or computer science stuff that they've been taught in their traditional classes, but the stuff that we've learned through hard knocks, folklore, over beers, and attending various Embedded Systems Conference meetings over the years.

With his words in mind, I decided to create a course for the University of Washington, Bothell, that would teach what it means to design an embedded system. I want to tell you about the course I developed.

You've probably seen PowerPoint slides showing the embedded design process (Figure 1). Most sales presentations include one. Almost every booth at ESC sells a product intended to shrink the development cycle. I decided that I was going to teach engineers how to do it. Thus, my course was not going to be about writing software, ISRs, or microprocessor interfacing. It was going to be about the embedded design process itself.

I should also mention that the University of Washington is on the quarter system. A typical class is 5 credit hours and each class lasts 10 weeks. Students attend two 2-hour classes per week. The course is taught at the junior/senior level. The prerequisites are pretty typical. The students have had several higher-level programming classes and my class in computer architecture and assembly language programming to give them a taste of what's under the hood. Perhaps most significantly, their background is programming. They have never taken any type of a traditional EE course that introduces hardware parameters or issues. Finally, I use David Simon's book, An Embedded Software Primer, An Embedded Software Primer as the course text.

I start the class by giving them their first hardware assignment, which is due in about two weeks. I also give them a number of articles to read that I've culled from the trade press. The homework assignment is to choose the proper microprocessor or microcontroller to use to build an embedded system that I specify. Sometimes it's a telecomm switch, sometimes it's an industrial robot, and sometimes it's something else. They are asked to choose their processor from a perspective that includes such issues as development tool availability, RTOS availability, legacy code, economics and time to market.

Figure 1: The embedded design lifecycle

For many students, the existence of any microprocessor besides the Pentium, or Athlon comes as quite a surprise. In my architecture class we work with 68000 assembly language and use the 68000 Instruction Set Simulator developed by Professor Alan Clements' group at the University of Teeside in the United Kingdom. However, the students never really consider a 68000, or 683XX processor because the simulator runs under Windows on their PC.

“Why teach the 68K?” you might ask. It's true that the 68000 is a venerable old ISA, but it's also a wonderful assembly language instruction set. Graduates from our program still write back to say they include it on their resumes and perspective employers take note of this.

The lectures then follow the embedded design lifecycle as shown in Figure 1. We next cover HW/SW partitioning issues, which naturally leads us to discussions about systems-on-silicon. We then move on to RTOSes, interrupts and other software design issues. A big part of this discussion centers about the relationship between C, C++ and assembly language. We discuss what happens from the instant that RESET is released until the program enters main(). We also spend a good deal of time discussing software performance issues and some of the other aspects of embedded C programming that we, as veteran developers, take for granted, but are largely mysterious to a student.Dan Saks' column in Embedded Systems Programming is a particularly useful resource. On the midterm exam I ask them a trick question: how would they would go about debugging an embedded system if the target system didn't support a printf()? They're also required to write a paper about a particular aspect of embedded software development.

The exam question (which doesn't get graded) leads to the second part of the class, which presents the tools of the trade. They learn how to use logic analyzers, emulators, and JTAG and BDM devices. The lecture part of the course ends with units on software reliability and performance testing. We discuss how it's done, why it's done, and the difficulties in actually doing it.

The students also participate in an embedded system laboratory designed to reflect the way the real world works. In the real world, software developers get hardware “thrown over the wall” by the hardware designers. The software team is given a specification, which may or may not be accurate, and are then tasked with making it work. The lab class works the same way.

Four companies deserve recognition for their contribution to the lab. Agilent Technologies donated HP16500 Logic Analyzers. Motorola donated ColdFIRE evaluation boards. Metrowerks donated the CodeWarrior tool chain for the 68K and ColdFIRE processors, and Applied Microsystems donated PC board design assistance by building the experimental boards I designed for the class.

Our lab has seven experimental stations on which students work in teams of two. Each station is equipped with a PC running Windows 2000, CodeWarrior, an HP16500 logic analyzer, and a Motorola MF5206eLITE evaluation board. The evaluation board connects to the PC through a BDM “wiggler” and also to a transition board that I designed. The transition board contains isolation buffers, headers for the HP logic analyzer and another set of ribbon cable connectors to carry the bus signals from the ColdFIRE processor to the experimental boards.

Each experiment teaches students a different aspect of embedded systems design. They learn how to configure the registers of the ColdFIRE chip , how to write ISRs , how to build an executable image, and more importantly, how to debug a program that's running in real time. One of the experiments employs a timer that generates spurious interrupts. The only way to locate the problem is with the logic analyzer.

I hope this brief description gives you some of the flavor of this course. Yes, I include many of the traditional aspects of a college curriculum. However, I think the strength of this program is that these students will go on the embedded job market with knowledge of “the big picture.” If they choose to speak up at a design review and question the wisdom of their company's “architectural guru,” so much the better.

Where do we go from here? Our goal at University of Washington is to develop an embedded systems track for our students interested in the field. In the greater Puget Sound area there are over 500 companies involved in software development. If you subtract from this group the dot com companies (who are going under at an alarming rate) there is still a large and growing demand for software engineers with embedded design skills. The embedded systems track will add a full credit lab course, which will replace the one that is an appendage to the embedded class, and add an advanced topics course as the capstone class.

Arnie Berger, PhD

Arnie Berger teaches in the Computing and Software Systems Department of the University of Washington-Bothell. Prior to leaving industry for academia, he was the Director of R&D at Applied Microsystems Corporation and held development and management positions at Hewlett-Packard and Advanced Micro Devices Corp. He received his BS and PhD degrees from Cornell University.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.