Proceedings

2005 Workshop on Embedded

Systems Education

WESE2005

Editors

Paul Caspi
Jeff Jackson

Jersey City, NJ

September 22, 2005

 Organizers’ Message

We are pleased to present this first workshop on embedded system education associated with the
2005 EMSOFT embedded software conference. This is one of the first workshops specifically
devoted to systems and software and we believe this is an important field that deserves to be
addressed. First it is a very strategic domain from an economic point of view. Some statistics
show that a huge proportion of microprocessor production (98% according to some sources) is
used in embedded system applications. Second the field is fragmented into many application
domains, e.g. aerospace, automotive, railways, telecommunications, consumer electronics, which
all have their own design methods and philosophy. Therefore, it is urgent that educators meet
together and discuss what and how to teach in order to get both usefully trained students and
researchers able to bridge the methodological gaps that exist between this large variety of
application fields.

It is in this spirit that we organized the workshop. Two invited speakers from the University of
California, Berkeley and the Royal Technology Institute of Stockholm will present some of their
most advanced experiences in embedded system and software education. Multiple sessions
focusing on embedded systems curricula and content; teaching experiences; and labs and
platforms used in embedded systems education will be conducted during the workshop. We can
reasonably expect the sessions to give matter to lively, animated and enriching discussions. We
also anticipate that the panel discussion that will conclude the workshop will allow us to delve
deeper into the subject and raise useful conclusions.

We feel this first workshop is a great success. However, there exist many venues for improving
cooperation among interested parties and facilitating greater multidisciplinary interactions. There
are many things that remain to be done on the subject and there is room for significant
improvements that will be the task of future editions of the workshop and our successors in their
organization.

Paul Caspi
Jeff Jackson

ii
 2005 Workshop on Embedded Systems Education

September 22nd, 2005, Jersey City, New Jersey, USA

(a satellite event of EMSOFT 2005)

Program
9:00 Opening

9:15 Invited Session

x Alberto San Giovanni-Vincentelli: Embedded System Education: A New Paradigm for

Engineering Schools?

10:00 Coffee Break

10:30 Curricula and Contents

x Suehee Pak, Eunha Rho, Juno Chang and Moon Hae Kim: Demand-Driven
Curriculum for Embedded System Software in Korea
x Masaki Yamamoto, Hiroyuki Tomiyama, Hiroaki Takada, Kiyoshi Agusa, Kenji
Mase, Nobuo Kawaguchi, Shinya Honda and Nobuyuki Kaneko: NEXCESS: Nagoya
University Extension Courses for Embedded Software Specialists
x Peter Marwedel: Towards laying common grounds for embedded system design
education
x Jogesh K. Muppala: Experience with an Embedded Systems Software Course

12:30 Lunch

14:00 Invited session

x Martin Grimheden and Martin Torngren: How should embedded systems be taught?
Experiences and snapshots from Swedish higher engineering education

14:45 Teaching Experiences

x Bettina Weiss, Günther Gridling and Markus Proske: A Case Study in Efficient
Microcontroller Education
x Voin Legourski, Christian Trödhandl and Bettina Weiss: A System for Automatic
Testing of Embedded Software in Undergraduate Study Exercises

15:45 Coffee Break

16:00 Labs and Platforms

iii
 x Stephen A. Edwards: Experiences Teaching an FPGA-based Embedded Systems Class
x Kenneth G. Ricks, David J. Jackson and William A. Stapleton: An Evaluation of the
VME Architecture for Use in Embedded Systems Education
x Falk Salewski, Dirk Wilking and Stefan Kowalewski: Diverse Hardware Platforms in
Embedded Systems Lab Courses: A Way to Teach The Differences

17:30 Panel: Embedded Systems Education: Future Directions, Initiatives, and Cooperation

iv
 Table of Contents

Organizers’ Message..................................................................................................................... ii
Program ........................................................................................................................................ iii

Embedded System Education: A New Paradigm for Engineering Schools?...................................1

Alberto Luigi Sangiovanni-Vincentelli and Alessandro Pinto, University of California at
Berkeley

Demand-Driven Curriculum for Embedded System Software in Korea .......................................11

Suehee Pak, Dongduk Women’s University; Eunha Rho, Sungkonghoe University; Juno
Chang, Sangmyung University; and Moon Hae Kim, Konkuk University

NEXCESS: Nagoya University Extension Courses for Embedded Software Specialists .............16
Masaki Yamamoto, Hiroyuki Tomiyama, Hiroaki Takada, Kiyoshi Agusa,
Kenji Mase, Nobuo Kawaguchi, Shinya Honda and Nobuyuki Kaneko, Nagoya
University

Towards Laying Common Grounds for Embedded System Design Education ............................21
Peter Marwedel, University of Dortmund

Experience with an Embedded Systems Software Course ............................................................25

Jogesh K. Muppala, The Hong Kong University of Science and Technology

How Should Embedded Systems be Taught? Experiences and Snapshots From

Swedish Higher Engineering Education ...............................................................................30
Martin Grimheden and Martin Törngren, Royal Institute of Technology

A Case Study in Efficient Microcontroller Education...................................................................36

Bettina Weiss, G¨unther Gridling, and Markus Proske, Vienna University of Technology

A System for Automatic Testing of Embedded Software in Undergraduate Study Exercises......44

Voin Legourski, Christian Trodhandl, and Bettina Weiss, Vienna University of Technology

Experiences Teaching an FPGA-based Embedded Systems Class................................................52

Stephen A. Edwards, Columbia University

An Evaluation of the VME Architecture for Use in Embedded Systems Education.....................59

Kenneth G. Ricks, David J. Jackson, and William A. Stapleton, The University of Alabama

Diverse Hardware Platforms in Embedded Systems Lab Courses: A Way to ..............................66

Teach the Differences
Falk Salewski, Dirk Wilking, and Stefan Kowalewski, Aachen University

v
Embedded System Education: A New Paradigm for
Engineering Schools?
Alberto Luigi Sangiovanni-Vincentelli and Alessandro Pinto
University of California at Berkeley
alberto,[email protected]

Abstract— Embedded systems are emerging as an essential industry. The automotive emphasis of our design methodology
component of modern electronic products. Embedded system work dates back to 1988 when a joint program on for-
design problems are posing challenges that involve entirely new mal approaches to embedded controller design with Magneti
skills for engineers. These skills are related to the combination
of traditionally disjoint engineering disciplines. There is a shared Marelli for their Formula one robotized gear shift for Ferrari
concern that today’s educational systems are not providing the started. In the automotive domain, there has also been strong
appropriate foundations for embedded systems. We believe a new interdepartmental interaction between mechanical engineering
education paradigm is needed. and electrical engineering/computer science.
We will argue this point using the example of an emerging In US Universities, bottom-up aggregation of interests and
curriculum on embedded systems at the University of California
at Berkeley. This curriculum is the result of a distillation approaches to education is more common than top-down
process of more than ten years of intense research work. We planning. Hence, education initiatives in novel areas almost
will present the considerations that are driving the curriculum always start with advanced graduate course offerings to mi-
development and we review our undergraduate and graduate grate towards coordinated graduate programs and eventually
program. In particular, we describe in detail a graduate class into undergraduate courses. Thus, it is no wonder that course
(EECS249: Design of Embedded Systems: Modeling, Validation
and Synthesis) that has been taught for six years. A common offering in Berkeley on embedded systems has been strong for
feature of our education agenda is the search for fundamentals years in the advanced course series (the EE and CS 290 series)
of embedded system science rather than embedded system design that are related to faculty research activities. One such course
techniques, an approach that today is rather unique. has migrated to a regular offering in the graduate program
Index Terms— Embedded System Design, Education. (EECS249: Embedded System Design: Modeling, Analysis and
Synthesis), the main topic of this paper.
The guiding principle in our teaching and research agenda
I. I NTRODUCTION related to embedded systems is to bring closer together system
Embedded systems have been a strong research area for theory and computer science. The two fields have drifted apart
the University of California at Berkeley. We will briefly for years while we believe that the core of embedded systems
review this intense research activity as a preamble to present intended as an engineering discipline lies in the marriage of
the Berkeley effort in embedded system education that is the two approaches. While computer science traditionally deals
intimately related to the research program. with abstractions where the physical world has been carefully
The research activities on embedded systems at Berkeley and artfully hidden to facilitate the development of application
can be cast in a matrix organization where vertical research software, system theory deals with the physical foundations of
areas cover application domains such as automotive, avionics, engineering where quantities such as time, power and size play
energy, industrial control, and horizontal areas cover enabling a fundamental role in the models upon which this theory is
technologies such as Integrated Circuits, Sensors, Wireless based. The issue then is how to harmonize the physical view
Networks, Operating Systems, Embedded Software, Auto- of systems with the abstractions that have been so useful in
matic Control, Design Methodologies and Tools. The impor- developing the CS intellectual agenda. We argue that a novel
tant aspect of our approach is that the enabling technologies system theory is needed that at the same time is computational
are explicitly linked to the vertical application areas and are and physical. The basis of this theory cannot be but a set of
geared towards the embedded system domain. novel abstractions that partially expose the physical reality to
At Berkeley, we have traditionally based our research pro- the higher levels and methods to manipulate the abstractions
grams on a strong interaction with industry and collaboration and link them in a coherent whole. The research community
among faculty in different disciplines; embedded system re- is indeed developing some of the necessary results to build
search is no exception. this novel system theory and we believe it is time to inject
Among embedded system application domains, automotive these findings in the teaching infrastructure so that students
has been an area of interest for many years. The PATH can be exposed to this new way of thinking that should
project [41] of CALTRANS (California Transportation Depart- advance the state of embedded system design to a point
ment) has been a test bed to develop new concepts in control of where reliable and secure distributed systems can be designed
distributed systems, modeling, tools and methodologies with quickly, inexpensively and with no errors.
a strong experimental part and an intense interaction with The paper presents the guiding principles we have followed
1
in our education effort and the set of courses offered that components including reconfigurable and programmable parts
have direct relevance to the field of embedded system design. is the result of architectural space exploration where cost
We list only the courses whose embedded system content functions and constraints guide the search.
is explicitly addressed. Otherwise, we may end up with a From this brief overview, it should be clear that our
comprehensive list of all courses offered in engineering (except motivation is to bring out the fundamental issues and the
maybe a few) as today electronic system design is almost formalization that enables verification and synthesis at a level
a synonym with embedded system design. In particular, we that would not be possible otherwise. This particular aspect
present first (Section 2) the graduate program: we zoom in should be seen as the quest for a new system science that
on EECS249 and then we briefly review a set of advanced serves as a framework to teach design that transcends the
topical courses on embedded systems. In Section 3, we present traditional discipline boundaries.
an overview of our undergraduate program centered on a Given the large scope of the course, it has a heavy load; four
sophomore core course 1 (EECS20N [30], [32]) that has contact hours and two lab hours per week. The contact hours
been now offered over the past five years. This course for are broken into traditional lectures and discussion of papers
EE and CS students addresses mathematical modeling of presented by the students. The verification of the learning
signals and systems from a computational perspective. This process is left to weekly homework that are a mix of exercises
reflects an effort of Berkeley faculty to set new foundations and of theory, and to a final project that is fairly advanced,
for the education in electrical engineering that is based on so much so that often the project reports see the light in the
fundamentals rather than application domains. In this section, community as conference or journal papers.
we also offer a view on our programs for the near future to The contents and the organization of the class has been the
address specifically embedded systems at junior and senior result of a number of advanced courses in hybrid systems and
level. In Section 4, we offer concluding remarks that could system level design that date back to 1991, when the first such
be of use for setting up a graduate or advanced undergraduate class was taught.
class in embedded system design in other institutions.
A. Organization of the class
II. T HE G RADUATE P ROGRAM PART 1:
EECS249 D ESIGN OF E MBEDDED S YSTEMS : M ODELS , The basic tenet of the methodology that forms the skeleton
VALIDATION AND S YNTHESIS of the class is orthogonalization of concerns, and, in par-
ticular, separation of function and architecture, computation
This course [15] is part of the “regular” graduate program in and communication. This methodology called platform-based
EECS. It is taken by first year graduate students as well as by design is presented as a paradigm that incorporates these prin-
senior graduate students in EECS and other departments such ciples and spans the entire design process, from system-level
as Mechanical Engineering, Nuclear Engineering and Civil specification to detailed implementation. We place particular
Engineering. emphasis on the analysis and optimization of the highest levels
The idea of the course is to emphasize the commonality of abstraction of the design where all the important algorithmic
among the variety of application fields and to use a design and architectural decisions are taken.
methodology as the unified framework where the topics of the The course has four main parts that are summarized in
course are embedded. In this way, the variety of the advanced table I.
courses offered in our curriculum benefits from the foundations
Introduction and Methodology. After a presentation of the
laid out by EECS249. The course is rather unique as it aims at
motivation for the class extracted from a variety of examples
bringing together the behavioral aspects of embedded system
in different industrial domains, we introduce the methodology
design with implementation within a rigorous as possible
followed (Platform-based Design [45]) and examples of its
mathematical framework. Behavior capture, verification and
applications. We present many examples of embedded sys-
transformation are taught using the concepts pioneered by
tems: cars, airplanes, smart buildings, elevators, and sensor
Edward Lee associated to models of computation. The im-
networks. In the introductory lecture, we highlight common-
plementation design is seen as a companion to the behavioral
alities among all the examples that we present to set the stage
design as opposed to a more traditional academic view where
for the philosophy of the course aimed at defining the common
implementation follows in a top-down fashion behavioral
methods that can be used across different application domains;
design. We adopt the view presented in [45] [46] to provide
the course is intended to solve “the embedded system design
the intellectual background. In this methodology, the design
problem” rather than particular instances of it.
proceeds by refinement steps where the mapping of behavior
An entire lecture is devoted to an overview of the platform-
into “architecture” is the step to move to the next level of
based design principle. The method is justified by illustrating
abstraction. Using this view, embedded software design is the
how it can be used to solve, or at least, to formalize, design
process of mapping a particular behavior on a computing plat-
problems that are common to the entire class of embedded
form. By the same token, the choice of a particular distributed
systems.
architecture due to geographical distribution or to performance
Function. The notion of behavior is analyzed and the role of
optimization is handled in a unified way. The choice of
non-determinism in specification is explained. We present the
1 A core course is a required course for the educational programs offered basic models of computation that are needed to represent the
by the Department behavior of most designs: Finite-State Machines, Synchronous
2
Languages, Data Flow Networks, Petri Nets, Discrete Event In this way, events in the functional netlist trigger events in the
Systems and Hybrid Systems. For each model we present the architecture netlist via the mapping netlist. We show how the
computation, communication and coordination semantics with mechanism can be exploited to change the mapping of function
a particular emphasis on the properties that are guaranteed and to architecture elements in a straightforward manner that
verifiable. We outline the use of unified frameworks to com- does not require re-writing of the architectural and functional
pare the different models of computation and we present the description. We present the scheduling problem as an essential
Tagged-Signal Model (TSM) [31] and agent algebras [40] as part of the allocation of functionality to shared resources.
unifying theories to allow the composition of different models In this respect, we review the fundamental results of the
of computation to describe a complete system. We introduce scheduling literature.
here the Ptolemy [44] and Metropolis [3] environments for Then, we show how mapped functions can be simulated
analysis and simulation of heterogeneous specifications. and how the performance of the mapping can be extracted.
We then ventured in the presentation of the model of At this point, we introduce the notion of quantity managers
computation used in Metropolis: the Metropolis Meta Model as tools that compute quantities such as power and time
(MMM). The MMM can be considered an abstract semantics used by architectural components when executing the part
since it can accommodate a variety of models of computation of the functionality mapped onto them. Finally, we present
that are obtained by refinement of this model. We presented mechanisms to feed quantity managers information about the
the additional constructs that are used in Metropolis to capture basic execution “costs” (e.g., power and time) and we show
the specification of a design in a declarative style (a unique examples drawn from Xilinx programmable platforms [49] and
feature of Metropolis): the Language of Constraints (LOC) and from other platforms such as the Intel MXP5800.
a more conventional language for logical constraint specifica- Synthesis and Verification. We review the notions of ver-
tion, LTL [43]. We also presented the Ptolemy actor-oriented ification and synthesis and present how verification is not
semantics and showed how this is another style for abstract a synonym of simulation but contains static analysis tools
semantics. as well as formal verification. In particular, we discuss the
Architecture and Mapping We then introduce the notion notion of successive refinement as the process used in the PBD
of architecture as a set of components (interconnections methodology to go from specification to final implementation.
for communication and building blocks that are capable of We demonstrate the use of the MMM to keep in the same
carrying out computation) that are providing services to the environment both the more abstract and the more concrete
behavior that we wish to implement. Optimal architecture representation to simplify the use of refinement verification
choice is presented as the selection of a particular set of techniques. We also show the simulation approach followed
computational blocks in a library of available components, in the Metropolis environment to reduce or even eliminate the
and of their interconnection. The evaluation of the quality overhead that comes with the flexibility of maintaining both
of a selected architecture is based on a mapping process of architecture and functionality present as separate entities of
behavior to the computation blocks, including programmable the design.
components. The mapping process should be accompanied by Then, we focus on the methods available in literature for
an estimate of the performance of the design once mapped onto software estimation, an important component of any verifica-
the architecture. Communication representation is illustrated. tion methodology that mixes hardware and software imple-
The representation of architectures in the Metropolis and mentations. The approach by Malik [34] is first introduced
Mescal [38] environments are presented. for static analysis of programs based on pipeline and cache
We emphasize the communication aspect as one of the modeling and integer linear programming followed by the
most important in architecture development. We introduce abstract interpretation work of Wilhelm that yielded the well-
communication-based design as a design paradigm where known analysis program AbsInt [21].
computation is abstracted away and communication becomes We then move to the software synthesis problem and
the main objective of the design process. We present a formal we present the model-based design approach where code
definition of the communication problem using the tagged is automatically generated from mathematical models. After
signal model framework that explains the communication reviewing shortly Real Time Workshop of MathWorks, we
phenomena as a restriction of the behaviors of the connected discuss a different way of generating code from models that
processes. We show a practical example of an architecture follows the same paradigm used in hardware synthesis of
platform like Xilinx VirtexII Pro as a heterogeneous platform optimizing the original description (software representation)
that can be used for fast prototyping. before mapping it onto a given execution platform. In this
Mapping functions to architectures is possibly the most case, we show that we have a “technology independent” phase
relevant aspect of the Platform based design methodology followed by technology mapping. We show how Esterel [5]
taught in this class. The power of the MMM is evident here is compiled using this idea and using FSM optimization
where the use of the same modeling constructs for function and techniques based on MIS [7] originally developed at Berkeley
architecture allows a particularly efficient way of performing for logic synthesis to generate implementation code. We then
mapping and analyzing the quality of the result. present another method to optimize the original description
By using the MMM notion of events, we show how the based on the Ordered Binary Decision Diagram [8] represen-
function netlist can be placed in correspondence with the ar- tation of programs. We show how to use the variable ordering
chitecture netlist by introducing the so-called mapping netlist. methods developed to manipulate OBDDs in logic synthesis
3
to generate efficient programs from Co-Design Finite State the development of algorithms for verification and synthesis.
Machines [20]. The case studies were mainly developed by students coming
We also present evaluation techniques to compute the time from departments other than EECS that are interested in
taken by synthesized programs to execute on a given plat- studying how the methodology can be applied to solve specific
form that are used to guide the optimization search. These design problems. Given the short available time, it is not
techniques are shown to be accurate when the software is possible in general for students to develop and show the
automatically synthesized. We then move to the problem of effectiveness of a complete design methodology for a specific
optimizing code for data flow dominated applications with application domain. This is the reason why this kind of
limited data dependent control. We show also how operating projects are rarely taken even though a couple were chosen
system features such as hardware-software communication and had worthwhile results. Projects that were developed in
mechanisms and scheduling policies can be synthesized from the past years include Time-Based Communication Refinement
requirements [2], [23] and we point to the evolution of for CFSMs, Heterochronous dataflow domain in Ptolemy II,
implementation platforms that can make the optimized “com- Hardware extension to ECL and Extending CFSMs to allow
pilation” problem increasingly difficult. multirate operations.
Finally we present two industrial tools for automatic code Few projects were given on architecture. This situation
generation: the real-time workshop (RTW) [36] by Mathworks reflects the status of our research in the field that only recently
and Targetlink [14] by dSPACE. has taken an important turn determined by the extensive
The last few lectures of the course are dedicated to placing introduction of the use of the MMM and of the characterization
the material presented in perspective. An application such as work carried out in conjunction with the Xilinx project. We
automotive control is used to show the complete flow from expect that more projects on this subject will be proposed in
modeling the functionality with hybrid systems to mapping the future particularly in the area of syntax and semantics of
onto execution platforms that are modified according to the languages for architectural description and automatic verifica-
results of the analysis. We had in mind to use Metropolis tion and refinement tools for architectures.
and x-Giotto as well as the Xilinx back-end to demonstrate a A successful project was about a complete methodology
complete design flow in action, but the parallel development for embedded software design and system integration of a
of the tools needed did not provide us in time with the flow rotorcraft UAV [26] whose results were published both as a
as we hoped to. conference and as invited paper in the Proceedings of the
Another application space that we explored is wireless IEEE. This project was carried out by three students and
sensor networks where our view of design leads naturally to two mentors coming from different knowledge domain. In the
the definition of layers of abstraction that identify clearly the area of wireless sensor networks, a group of students applied
need of a “middleware” that can capture well the performance the methodology for studying an ad-hoc sleeping disciplines
of a particular physical implementation of the network to offer for nodes [29]. This application domain is very relevant not
the application programmer an abstraction that enables re- only for its distributed nature but also for the severe energy
use across different implementations with appropriate abstract consumption constraints on each node.
analysis of the effects of the physical network on the applica- Two other projects that had success to the point of being
tion program. published in primary conferences were related to chip architec-
After the end of the course, the projects that are used to tures. One was about the synthesis of on-chip communication
evaluate the students are presented in front of the entire class architectures [42] and automatic hardware/software partition-
to open a wide range discussion among students, teaching ing for reconfigurable platforms [4].
assistant, mentors and faculty on the results and the ideas on Projects in less obvious application domains have also been
how to improve the course. offered. In particular, two years ago a project on the design
of a real-time eye detection system was assigned to two
students [50]..
B. Projects
The course is graded on the basis of a set of homework
and on a final project. After the first week of class, a list of III. T HE G RADUATE P ROGRAM PART 2:
A DVANCED G RADUATE C OURSES
project proposals is given to the students. We rely on a group
of highly qualified mentors form industry and academia that Advanced courses are an important feature of the Berkeley
help the students in reviewing previous work and conducting graduate program. These courses reflect very recent advances
the research to complete their projects on time. We push in the state of the art of a particular knowledge domain. They
students to start as early as possible and we motivate them are topical courses; their content changes from year to year
by mentioning the possibility of submitting for publication for and can be taken by students multiple times. In general, they
the best reports. are taken by PhD students who are interested in research
Following the course organization, projects are divided in topics in the area covered by the course. Regular graduate
the ones that are related to functional description, architectural courses are often derived from the advanced series after the
description, mapping, case studies and design methodologies. content has jelled and there is enough interest in the student
The choices of students are often concentrated on the population. Since embedded systems are so important in our
definition of formal models for describing a function and on research agenda, there are several advanced courses that have a
4
 Course Section Lectures Discussions Labs
Introduction Definition of embedded systems, “The tides of EDA” Introduction to the Metropolis
examples of applications, chal- Meta-Model language
lenges, future applications
Function Finite State Machines, Co-design StateCharts, Data flow with firings, Introduction to PtolemyII, Build-
finite state machines, Kahn process Desynchronization ing a model of computation in
networks and data flow, Tagged Metropolis, Esterel.
Signal Model, Agent Algebras,
Petri nets, Synchronous languages
and desynchronization
Architecture Performances, Architecture Formal modeling of processors, Modeling architectures in Metropo-
modeling, Modeling Concurrency: Rate monotonic hyperbolic bound, lis, Xilinx, PSoC.
Scheduling, Interconnection Interface synthesis.
architectures, Reconfigurable
platforms, Programmable
platforms, Fault tolerant
architectures.
Mapping Mapping specification, Design Ex- Synthesis of software from CFSMs Virtual Component Co-design,
ploration, Software estimation and specification Mathworks RTW, dSpace Target
synthesis, Static analysis, Quasi Link
static scheduling.

TABLE I
C LASS S YLLABUS

direct relationship with the topics of this paper. These courses The schedule of the class starts with an introduction to the
are labeled EE290 and CS294 followed by a letter indicating emerging computing platforms composed of a large number
the area these courses belong to. of simple nodes communicating on wireless channels. Habitat
In Figure 1, we show a the backbone of a graduate program monitoring applications are taken as representative of embed-
in embedded systems that traverses the courses presented in ded networks of nodes that can sense and communicate. The
this paper. A well thought out course program in embedded design of the embedded network is driven by the application
systems should include domain-specific courses that provide that sets the requirements to satisfy. After the introduction,
the reference framework for the students to be productive in one week is dedicated to the presentation of several platforms
the outside world. and operating systems that are currently available.
The following four weeks of the class give an overview
of all the proposed protocols for wireless sensor networks:
&6 &6Z

$SSOLFDWLRQV
network discovery, topology information, aggregation, broad-
cast and routing. The design of all these protocols takes into
account the constraints imposed by the application. The class
((2 (($
5HDO7LPH6:
3DUDOOHO5HFRQILJXUDEOHSODWIRUPV
puts a lot of emphasis on power consumption since nodes
cannot be replaced.
The second part of the class gives directions for the imple-
6HPHVWHUV

((1
mentation and deployment of these networks. Two weeks are
$GYDQFHGWRSLFV
devoted to the problems arising from the distributed nature of
the applications. In particular, distributed storage of informa-
((

(PEHGGHG6\VWHP6FLHQFH
tion and distributed control are presented as important research
areas. Finally, privacy is considered as a potential problem
since embedded networks have the capability of monitoring
Fig. 1. A graduate program in embedded systems
every objects in the environment in which they are embedded.
Students in the class are divided in groups and each of them
A. Computer Science Courses works on a project. Possible topics range from programming
The Computer Science Division of our Department offers models and simulations of large scale networks to new proto-
a graduate level class on embedded network and mobile cols for routing and localization. In Fall 2003, a considerable
computing platforms. The course is “CS294-1”. As is always number of projects investigated the problem of programming
the case for advanced graduate classes that belong either to the the network starting form the description of the application.
EE290 series or the CS294 series, its content changes every 2) Mobile Computing and Wireless Networking: The level
semester. of abstraction of the networks considered in this class is much
In the last five years, this course has always been centered higher than the one considered in the previous section. The
around applications that are embedded in the environment with focus in on new trends in mobile computing and integration
which they interact. of heterogeneous networks [12].
1) Deeply Embedded Network Systems: This advanced The class presents challenges in mobile computing where
class focuses on ubiquitous computing [11]. The course is the end user is a person that uses a device to be constantly
based on the experience of researchers form different univer- connected to the rest of the world. The requirements on
sities on wireless sensor networks. the protocol implementation are derived by looking at the
5
issues that mobility brings up: routing, network registration lable Data Flow, multidimensional and heterochronous data
and security. Some protocols to solve all this problems are flow and boolean data flow.
presented. The last part of the class introduces continuous time models
A network node is an hand-held device that presents severe and hybrid systems. The emphasis is on the semantics and
limitations in power consumption. This problem, which is the techniques that are used to solve systems of differential
presented as an important constraints, presents some common- equations. In particular, problems like event detection and
ality with wireless sensor networks of the deeply embedded Zeno behaviors for hybrid systems are considered and the
networks class but it is not the only one. Connectivity and impact on the simulation engine are explained.
distributed information storage are also investigated and some 2) EE290O: Embedded Software Engineering: While the
solutions are presented. previous class explores the models that should be used in de-
Finally, some common platforms for this kind of systems veloping embedded software, this class focuses on a particular
like WLAN, UMTS, GSM and GPRS are presented. design flow. The class presents a model of computation, the
Giotto model [24], and explains why it is suitable for a class
of embedded software [18]. The class is divided in three parts:
B. Advanced Electrical Engineering Courses
RTOS Concepts. A real time operating system is characterized
The electrical engineering division of the EECS Department by the services that it provides: environment communication
offers advanced courses that are focused on formal models for services, event triggering services, software communication
system level design and embedded software. Two classes are services and software scheduling. Tasks and threads are de-
particularly relevant to our discussion on embedded systems. fined and a model for them is explained. A simple example
1) EE290N: Concurrent models of computation for embed- of an RTOS is given. In their first homework, students have
ded software: This advanced class focuses on concurrent mod- to implement an RTOS on the LEGO brick. The students now
els of computation for embedded software development [17]. have a feeling of the RTOS abstraction level and the problems
It can be seen as the extension to and deep analysis of the in modeling software at this level. The E-machine [25] is then
first five weeks of EECS249. It has been taught four different described and its properties are formally explained: semantics
times with contents that are converging to a unified view so of the E-machine, portability and predictability, deterministic
that there is a plan of making it a regular graduate course. behavior and logical execution time.
Abstract semantics, concrete semantics and implementation RTOS Scheduling. Some classic scheduling algorithms are
of some of the most commonly used models are presented. presented. First, a task is modeled with execution time and
Besides homework assignments, students are required to work deadline and the concept of preemption is explained. Then,
on a project. early deadline first and rate monotonic scheduling are ex-
The first two lectures present the main differences between plained. The last part of this section is devoted to schedu-
embedded software and software for standard applications. In lability tests like rate monotonic analysis (RTA) and model
particular, threads are formally defined and their limitations based schedulability analysis (where tasks and schedulers are
are underlined with a particular emphasis on the problems modeled as timed automata).
that arise when using this technique for developing concurrent RT Communication. The last part of the class deals with real
programs. Then, languages for particular applications, like time communication. Messages are modeled with deadline and
NesC [22] and Lustre [10], are taken as representative of worst case latency. Two protocols are presented in details:
domain specific models for embedded software. Controller Area Network (CAN) and Time Triggered Protocol
Then Process Networks (PN) are introduced and an abstract (TTP) [28]. The problem of fault tolerance is introduced and
semantics based on PN is presented together with the notion of the solution proposed by the TTP protocol is explained.
partial ordering and prefix ordering on sequences of events. In 3) EE290a: Concurrent System Architectures for Appli-
this abstract settings, properties like monotonicity, continuity cations and Implementations: This experimental class was
and determinacy of a process are described as properties of the offered in the Spring 2002. The focus of the class is on
input-output function on streams that characterize a process. models for concurrent applications, heterogeneous platforms
The fixed point semantics is also introduced when multiple and the mapping of the former to the latter [16]. This course
processes are connected together and loops are present in can be considered as a follow-on to EECS249 with respect to
the corresponding functional graph. A concrete semantics Architecture and Mapping.
is then presented and finally the concrete implementation The first part of the class introduces the content of the course
of PN semantics, following the Kahn-McQueen execution by giving examples of applications and platforms. Several
semantics, is shown by using PtolemyII as a platform for models of computation like finite state machines, process
implementing and composing models of computation. The networks, data flow, synchronous/reactive, communicating se-
problem of bounded execution (an execution that used a quential processes and co-design finite state machines are
bounded amount of memory) is introduced and simulation introduced emphasizing the fact that each model is particularly
techniques are presented. suitable for a specific application domain. The Click [47]
After Process Networks, synchronous languages are intro- model of computation is explained for modeling the processing
duced together with the notion of complete partial orders of streams of packets in routers.
and the least fixed point semantics of synchronous programs. The first example presented in the class is MPEG decoding
Dataflow models are extensively discussed: statically schedu- together with an entire flow from specification (using a flavor
6
of Kahn process networks called YAPI [13]) to implemen- B. Civil and Mechanical Engineering 290I: “Civil Systems,
tation. This example shows how the requirements of an Control and Information Management”
application condition the selection of a model of computation The possibility of sensing the environment and communi-
and the underling implementation platform. Several platforms cating over a dense network of tiny objects is of much interest
are then presented: the Nexperia [39] platform by Philips for the civil engineering community. This course starts with
for multimedia application and the Ixp1200 [27] platform by an introductory lecture that motivates the use of embedded
Intel for network processing. For each platform, examples of networks with several applications: automatic control of the
what kind of application they target are given together with BART (Bay Area Rapid Transportation) system, earthquakes
performances result. monitoring and mesh stable formation flight of unmanned air
The Giotto model of computation and the E-Machine are vehicles.
presented and an example of the software running on an The emphasis of the class is on the formal specification
autonomous helicopter is shown. Another example show the of complex networked systems. The Teja [48] environment
implementation of an IP router on a VirtexII Pro FPGA and is used as example of formal language to specify systems of
the implication of using a multi-threaded implementation. The users and resources. Syntax and semantics of the language are
SCORE (Stream Computations Organized for Reconfigurable explained in the class and students are trained in using the
Execution) [9] project is also presented. In this project both environment with labs and homework.
function and architecture are described using Kahn process
networks and the challenge is to find a schedule of processes V. T HE U NDERGRADUATE P ROGRAM
for bounded execution. The architecture is composed of a
Our approach to embedded systems has been to marry the
set of processors that communicate over a shared network.
physical and the computational world to teach students how to
Buffers are allocated on memory segments. The last lectures
reason critically about modeling and abstractions. Tradition-
give an overview of multiprocessors platforms like RAW and
ally undergraduate EE courses have focused on continuous
IWarp [6] and other programmable platforms like PSOC by
time and detailed modeling of the physical phenomena using
Cypress and the Extensa Processor.
partial and ordinary differential equations, while undergraduate
CS courses have focused on discrete representations and
IV. T HE G RADUATE P ROGRAM PART 3: computational abstractions. We noted that students then were
C IVIL AND M ECHANICAL E NGINEERING “boxed” in this dichotomy and had problems linking the two
worlds. The intellectual agenda was to teach students how
These two Departments have traditionally been interested to reason about the meaning of mathematical models, their
in embedded applications. They have some graduate courses limitations and power. EECS20N (Structure and Interpretation
where embedded topics are featured. of Signals and Systems) was born with this idea in mind.
EECS 20N together with EECS 40 (Introduction to Micro-
electronic Circuits), CS 61A (The Structure and Interpretation
A. Mechanical Engineering 230: “Real Time Software for of Computer Programs), CS 61B (Data Structures), and CS
Mechanical System Control” 61C (Machine Structures) are mandatory courses for any
The Mechanical Engineering Department offers a class that Berkeley undergraduate EECS student. In addition to having
teaches students how to control mechanical systems using an important role in the general undergraduate education,
embedded software. It is a lab oriented class in the sense that EECS20N (see [30], [32]) is also at the root of a system
students are taught how to implement a controller in Java on science program whose structure is shown in Figure 2. In this
an embedded processor. diagram, EE149, Hybrid and Embedded Systems, is an upper-
Even if methodology is not really the focus of this class, division class that is under design and will provide the ideal
controlling a mechanical system implies understanding the follow-on to EECS20N in a curriculum that focuses on the
continuous dynamics governing it and the constraints that are foundations of embedded systems.
imposed on the reaction time of the software controller. The
class gives an overview of the real time control problems. A. EECS20N: Structure and interpretation of signals and
Students are exposed to Java as a technology that allow the systems
development of real time systems and how complicated control a) Motivation and History: EECS20N [19] is a course
algorithms can be implemented on an embedded processor. that electrical engineering and computer science students take
This part takes one third of the entire class. This technology in their second year at Berkeley. Traditionally, our undergradu-
is applied to the control of motors. ates were exposed to a rigorous approach to systems in classes
Students learn real time programming through a set of labs. offered in the junior and senior year dealing with circuit theory,
The first two labs are meant to teach students how to write communication systems and control. The contents of the
a control algorithm for an embedded processor. The third courses were thought in terms of the application domain and
lab show how the software world interfaces with a physical exposed a certain degree of duplication, as ordinary differential
component like a motor. In the following lab sessions, students equations and transforms such as Laplace and Fourier were
are guided in implementing a feedback control algorithm for common tools. In addition, the modeling techniques used
a motor. were essentially continuous time ignoring for a large part the
7
 FRUUHVSRQGLQJJUDGXDWHFODVVHV
and examines the waveform in both the time and frequency






    domain. Systems are described as functions that map functions
(signals) into functions (signals). Again, the focus is not on
how the function is defined, but rather on what is the domain
 

0(   

25 and range. Block diagrams are defined as a visual syntax for
composing functions.
+\EULG  &RPSXWHU )HHGEDFN 'LJLWDO 0HGLD  6WRFKDVWLF
V\VWHPV
2SWLPL]DWLRQ The connection between imperative and declarative descrip-
HPEHGGHG QHWZRUNV FRQWURO FRPP '63
V\VWHPV
tion is fundamental to set the framework for making the intel-
lectual connection between the labs and the lecture material.
The, finite state machines are introduced and analyzed. Non-

determinism and equivalence in state machines is explained.
Equivalence is based on the notion of simulation, so simulation
relations and bisimulation are defined for both deterministic
Fig. 2. Pre-requisite Structure for Undergraduate Program in Systems and nondeterministic machines. These are used to explain that
two state machines may be equivalent even if they have a
discrete world. From conversations among the system faculty,
different number of states, and that one state machine may
the idea of revamping substantially the foundations of systems
be an abstraction of another, in that it has all input/output
and signals emerged to provide a strong basis for embedded
behaviors of the other (and then some). Composition of finite
system design.
state machines and the feedback loop connection is introduced.
Traditional courses such as circuit theory (and the resulting
The most useful concept to help subsequent material is that
emphasis on linear time-invariant systems) were no longer
feedback loops with delays are always well formed.
deemed core courses and a unified approach to the basics of
The last part applies the theory to real examples that depend
signals and systems took form as the seed for launching an
on the interests and expertise of the instructor, but we have
initiative to bring our students to appreciate the mathematical
specifically covered vehicle automation, with emphasis on
underpinnings of embedded system analysis including continu-
feedback control systems for automated highways. The use
ous and discrete abstractions and models. In particular, Edward
of discrete magnets in the road and sensors on the vehicles
Lee and Pravin Varaija embarked in 1999 for the journey that
provides a superb illustration of the risks of aliasing.
eventually led to EECS20N. They wrote a book [33], built
c) The Lab: A major objective of the course is to
a course on the fundamentals needed to understand signals
introduce applications early, well before the students have built
and systems, and adopted tools such as Matlab [37] to lower
up enough theory to fully analyze the applications. This helps
the barrier to abstract reasoning using extensively visualization
to motivate the students to learn the theory. In the Lab, we
of system behavior. The description of their approach can be
emphasize the use of software to perform operations that could
found in two papers [30], [32] from which this section is taken.
not possibly be done by hand, operations on real signals such
b) The Program of the Course: The themes of the course
as sounds and images.
are:
While the mathematical treatment that dominates in the
• The connection between imperative (computational) and lecture and textbook is declarative, the labs focus on an
declarative (mathematical) descriptions of signals and imperative style, where signals and systems are constructed
systems. procedurally. Matlab and Simulink [37] are chosen as the
• The use of sets and functions as a universal language for basis for these exercises because they are widely used by
declarative descriptions of signals and systems. practitioners in the field, and because they are capable of
• State machines and frequency domain analysis as com- realizing interesting systems.
plementary tools for designing and analyzing signals and There are 11 lab exercises, each designed to be completed in
systems. one week. The exercises include: Arrays and Sound, Images,
• Early and frequent discussion of applications. State Machines, Control Systems, Difference and Differential
State machines were the means to introduce EE students to Equations, Spectrum, Comb Filters, Modulation and Demodu-
reason about digital abstractions, frequency domain analysis lation, Sampling and Aliasing. Two of the weeks are quite in-
to introduce CS students to reason about the continuous time teresting (State Machines and Control Systems) from the point
world. The use of applications is essential to keep the students of view of embedded systems and models of computation. The
interested and motivated in absorbing a material that otherwise third lab uses Matlab as a low-level programming language
may be too arid and abstract at an early stage of engineering to construct state machines according to a systematic design
education. pattern that will allow for easy composition. The theme of the
The introduction to the course motivates forthcoming ma- lab is establishing the correspondence between pictorial rep-
terial by illustrating how signals can be modeled abstractly resentations of finite automata, mathematical functions giving
as functions on sets. The emphasis is on characterizing the the state update, and software realizations. The main project
domain and the range, not on characterizing the function itself. in this lab exercise is to construct a virtual pet. This problem
The startup sequence of a voiceband data modem is used as is inspired by the Tamagotchi virtual pet made by Bandai in
an illustration, with a supporting applet that plays the very Japan. Tamagotchi pets were popular in the late 1990s, and had
familiar sound of the startup handshake of V32.bis modem, behavior considerably more complex than that described in
8
this exercise. The students design an open-loop controller that its cost, weight, size and power consumption. The course
keeps the virtual pet alive. This illustrates that systematically will present methods to capture implementation platforms
constructed state machines can be easily composed. and to map functionality to platforms.
In the Control System lab, students modify the pet so that • Applications will be emphasized as drivers and as test
its behavior is nondeterministic. They are asked to construct a cases for the methods presented in the class. In particular,
state machine that can be composed in a feedback arrangement during the course, students will be asked to develop com-
such that it keeps the cat alive. pletely an embedded system in a particular application
domain using the methods taught. This design work will
be carried out in teams whose participants will have
B. Discussion and future directions
enough diversity as to cover all aspects of embedded
EECS20N has reached a degree of maturity that will allow system design.
it to be taught by any faculty in the Department given the Since many of these topics are covered in EECS249, the
large amount of teaching material available. During the first graduate class, we will borrow heavily from that experience
years, the course was not among the favorites of the students while the material of EECS249 will evolve towards more
given its generality and mathematical rigor. However, the advanced topics.
fine-tuning of labs and lectures and of their interrelation has
had a positive effect on the overall understanding of the
VI. C ONCLUSIONS
material and the students now express their satisfaction with
this approach. Having laid out the foundation of the work, We outlined the embedded system education program at
we are now considering extending the present offering in the the University of California at Berkeley. We stressed the
upper division. The EE149 class in gestation will emphasize importance of foundations in education as opposed to techni-
three main aspects: calities. Embedded systems are important enough to warrant
• The idea of introducing signals and systems as described
a careful analysis of the mathematical bases upon which we
can build a solid discipline that marries rigour with practical
here with the operational and the denotational view can
be traced to the research work that led to the development relevance. Given the present role of embedded systems in our
of the Lee-Sangiovanni-Vincentelli (LSV) tagged signal research agenda and the traditional approach to education in
the leading US Universities, the first courses to be developed
model [31], a denotational framework to compare models
of computation. While the concept of time is not as are advanced graduate courses. The natural evolution is to
solidify the teaching material to a point where regular graduate
abstract as in the LSV model, the course does present the
classes can be taught and finally move the contents to the
denotational view of systems along similar lines. EE149
will focus on the semantics of embedded systems and undergraduate curriculum while the graduate courses adjust
continuously to the advances in the field brought about by
introduce a consistent family of models of computation
with the relative applications, strengths and weaknesses. research. The flexibility of the US system allows to change
• Using Matlab and Simulink as a virtual prototyping
fairly easily the curriculum and to strive for relevance to the
ever changing society and cultural landscape.
method and being exposed to both the digital and the
analog abstraction, the students have an early exposure While we believe that our program has achieved a set of
to hybrid systems [35] as an important domain for important goals, we do realize that much remains to do. At
the undergraduate level, we are planning to introduce an upper
embedded systems where a physical plant described in
the continuous-time domain is controlled by a digital division class on hybrid and embedded software systems.
controller. We will devote a substantial portion of the At the graduate level, we are considering the addition of
regular courses on theoretical foundations focusing on function
course to the discussion of the properties of hybrid
models as paradigms for the future of large scale system description and manipulation as well as one on reconfigurable
and programmable architectural platforms to follow the basic
monitoring and control.
• A substantial problem is the way in which Simulink
graduate course (EECS249) on embedded systems. We also
combines discrete and continuous-time models. Simulink believe that embedded system courses should be considered
foundational courses for the entire college of engineering and
essentially embeds the discrete in the continuous do-
main, i.e., the numerical integration techniques determine we are working with our Dean and Department Chairpersons
the time advancement for both continuous and discrete to address this issue.
The views presented here are for a large part shared with
models. Thus de facto Simulink implements a single
model of computation: the synchronous reactive model the Artist [1] Network of Excellence Education Team whose
where logical time is determined by the integration al- agenda is described in another paper of this special issue.
gorithm. This may make Simulink non ideal for teach-
ing embedded systems where heterogeneous models of VII. ACKNOWLEDGEMENTS
computation play a fundamental role. We will add to We wish to acknowledge the long-time collaboration with
the Matlab/simulink environment, Ptolemy II as a design Edward Lee, Tom Henzinger, Richard Newton, Jan Rabaey,
capture and verification tool to obviate this problem. Shankar Sastry and Pravin Varaija in the research and teaching
• Implementation platforms are important as they deter- agenda on embedded systems at Berkeley. The help and
mine the real-time properties of the system as well as support of the Metropolis group is gratefully acknowledged.
9
Important impacts on our approach come from interactions [24] T. A. Henzinger, B. Horowitz, and C. M. Kirsch, “Giotto: A time-
with Albert Benveniste, Gerard Berry, Paul Caspi, Hugo triggered language for embedded programming,” Proceedings of the
IEEE, vol. 91, pp. 84–99, 2003.
DeMan, Luciano Lavagno, Joseph Sifakis and the ARTIST [25] T. A. Henzinger and C. M. Kirsch, “The embedded machine: Predictable,
European Network of Excellence team, Alberto Ferrari and his portable real-time code,” in Proceedings of the International Conference
colleagues of PARADES, and last but not least our industrial on Programming Language Design and Implementation. ACM Press,
2002, pp. pp. 315–326.
associates too numerous to be mentioned. Funding for this [26] B. Horowitz, J. Liebman, C. Ma, J. Koo, T. A. Henzinger,
work came from CHESS NSF ITR, and the GSRC. Work A. Sangiovanni-Vincentelli, and S. Sastry, “Embedded software design
(partially) done in the framework of the HYCON Network and system integration for rotorcraft uav using platforms,” in Proceed-
ings of the 15th IFAC World Congress on Automatic Control. Elsevier,,
of Excellence, contract number FP6-IST-511368. 2002.
[27] IXP1200, “
http://www.intel.com/design/network/products/npfamily/ixp1200.htm.”
R EFERENCES [28] H. Kopetz and G. Grunsteidl, “Ttp-a protocol for fault-tolerant real-time
systems,” Computer, vol. 27, no. 1, pp. 14–23, 1994.
[1] Artist, “http://www.artist-embedded.org/overview/.” [29] F. Koushanfar, A. Davare, D. T. Nguyen, M. Potkonjak, and
[2] F. Balarin et al., Polis: A Design Environment for Control-Dominated A. Sangiovanni-Vincentelli, “Distributed localized algorithms and pro-
Embedded Systems. Kluwer, 1997. tocols for power minimization in networked embedded systems,” in
[3] F. Balarin, Y. Watanabe, H. Hsieh, L. Lavagno, C. Passerone, and ACM/IEEE International Symposium On Low Power Electronics and
A. Sangiovanni-Vincentelli, “Metropolis: An integrated electronic sys- Design, 2003.
tem design environment,” IEEE Computer, Apr 2003. [30] E. A. Lee, “Designing a relevant lab for introductory signals and
[4] M. Baleani, F. Gennari, Y. Jiang, Y. Patel, R. K. Brayton, and systems,” Proc. of the First Signal Processing Education Workshop,
A. Sangiovanni-Vincentelli, “Hw/sw partitioning and code generation 2000.
of embedded control applications on a reconfigurable architecture [31] E. A. Lee and A. L. Sangiovanni-Vincentelli, “A framework for com-
platform,” in Proceedings of the 10th International Symposium on paring models of computation,” IEEE Trans. Comput.-Aided Design
Hardware/Software Codesign (CODES), Estes Park, Colorado, USA, Integrated Circuits, vol. 17, no. 12, pp. 1217–1229, Dec. 1998.
May 2002. [32] E. A. Lee and P. Varaiya, “Introducing signals and systems – the berkeley
[5] G. Berry and G. Gonthier, “The esterel synchronous programming approach,” Proc. of the First Signal Processing Education Workshop,
language: Design, semantics, implementation,” Science of Computer 2000.
Programming, vol. 19, no. 2, pp. 87–152, 1992. [33] ——, “Structure and interpretation of signals and systems,” 2003.
[6] S. Borkar, R. Cohn, G. Cox, S. Gleason, and T. Gross, “Warp: an in- [34] Y.-T. S. Li and S. Malik, “Performance analysis of embedded software
tegrated solution of high-speed parallel computing,” in Supercomputing using implicit path enumeration,” in Workshop on Languages, Compilers
’88: Proceedings of the 1988 ACM/IEEE conference on Supercomputing. and Tools for Real-Time Systems, 1995, pp. 88–98.
IEEE Computer Society Press, 1988, pp. 330–339. [35] J. Lygeros, C. Tomlin, and S. Sastry, “Controllers for reachability
[7] R. K. Brayton, R. Rudell, A. Sangiovanni-Vincentelli, and A. R. specifications for hybrid systems,” in Automatica, Special Issue on
Wang, “Mis: A multiple-level logic optimization system,” IEEE Trans. Hybrid Systems.
Comput.-Aided Design Integrated Circuits, vol. 6, no. 6, pp. 1062–1081, [36] Mathworks, “http://www.mathworks.com/products/rtw/.”
Nov. 1987. [37] Matlab, “http://www.mathworks.com/.”
[8] R. E. Bryant, “Graph-based algorithms for Boolean function [38] Mescal, “http://embedded.eecs.berkeley.edu/mescal.”
manipulation,” vol. C-35, no. 8, pp. 677–691, Aug. 1986. [Online]. [39] Nexperia, “http://www.semiconductors.philips.com/products/nexperia/.”
Available: mentok.cse.psu.edu/bryant86graphbased.html [40] R. Passerone, “Semantic foundations for heterogeneous systems,” Ph.D.
dissertation, University of California, Berkeley, 2004.
[9] E. Caspi, M. Chu, R. Huang, J. Yeh, J. Wawrzynek, and A. DeHon,
[41] PATH, “http://www.path.berkeley.edu/.”
“Stream computations organized for reconfigurable execution (score),”
[42] A. Pinto, L. Carloni, and A. Sangiovanni-Vincentelli, “Constraint-driven
in FPL ’00: Proceedings of the The Roadmap to Reconfigurable Com-
communication synthesis,” in Proceedings of the Design Automation
puting, 10th International Workshop on Field-Programmable Logic and
Conference 2002 (DAC’02), June 2002.
Applications. Springer-Verlag, 2000, pp. 605–614.
[43] A. Pnueli, “The temporal logic of programs,” in Proceedings of the 18th
[10] P. Caspi, D. Pilaud, N. Halbwachs, and J. A. Plaice, “Lustre: a declar-
IEEE Symposium on the Foundations of Computer Science (FOCS-77),
ative language for real-time programming,” in POPL ’87: Proceedings
IEEE. Providence, Rhode Island: IEEE Computer Society Press, Oct.
of the 14th ACM SIGACT-SIGPLAN symposium on Principles of pro-
31–Nov. 2 1977, pp. 46–57.
gramming languages. ACM Press, 1987, pp. 178–188.
[44] PtolemyII, “http://ptolemy.eecs.berkeley.edu.”
[11] CS294, “http://www.cs.berkeley.edu/˜ culler/cs294-f03/.”
[45] A. Sangiovanni-Vincentelli, “Defining platform-based design,”
[12] CS294w, “http://www.cs.berkeley.edu/˜ adj/cs294-1.f00/.” EEDesign of EETimes, February 2002.
[13] E. A. de Kock, G. Essink, W. J. M. Smits, P. van der Wolf, J.-Y. Brunel, [46] A. Sangiovanni-Vincentelli, L. Carloni, F. D. Bernardinis, and M. Sgroi,
W. M. Kruijtzer, P. Lieverse, and K. A. Vissers, “Yapi: Application “Benefits and challenges for platform-based design,” in Proceedings of
modeling for signal processing systems,” Proceedings of the Design the 41st annual conference on Design automation. ACM Press, 2004,
Automation Conference, June 2000. pp. 409–414.
[14] dSpace, “http://www.dspaceinc.com/ww/en/inc/products/sw/targetli.htm.” [47] N. Shah, W. Plishker, and K. Keutzer, NP-Click: A Programming Model
[15] EE249, “http://www-cad.eecs.berkeley.edu/˜ polis/class.” for the Intel IXP1200, 1st ed. Elsevier, 2004, vol. 2, ch. 9, pp. 181–201.
[16] EE290A, “ [48] Teja, “http://www.teja.com/.”
http://www-cad.eecs.berkeley.edu/respep/research/classes/ee290a/fall02/.” [49] Xilinx, “http://www.xilinx.com.”
[17] EE290N, “http://embedded.eecs.berkeley.edu/concurrency/.” [50] L. Zimet, S. Kao, A. Amir, and A. Sangiovanni-Vincentelli, “An embed-
[18] EE290O, “http://www.cs.uni-salzburg.at/˜ ck/teaching/eecs290o-spring- ded system for an eye detection sensor,” in Computer Vision and Image
2002.” Understanding: Special Issue on Eye Detection and Tracking, 2004.
[19] EECS20N, “http://ptolemy.eecs.berkeley.edu/eecs20/index.html.”
[20] F. B. et. al., “Synthesis of software programs for embedded control ap-
plication,” IEEE Transactions on Computer-Aided Design of Integrated
Circuits and Systems, June 1999.
[21] C. Ferdinand and R. Wilhelm, “On predicting data cache behavior for
real-time systems,” in Proceedings of the ACM SIGPLAN Workshop on
Languages, Compilers, and Tools for Embedded Systems. Springer-
Verlag, 1998, pp. 16–30.
[22] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler,
“The nesc language: A holistic approach to networked embedded
systems,” SIGPLAN Not., vol. 38, no. 5, pp. 1–11, 2003.
[23] Giotto, “http://embedded.eecs.berkeley.edu/giotto/.”

10
 Demand-Driven Curriculum for
Embedded System Software in Korea
Suehee Pak Eunha Rho Juno Chang
Dongduk Women’s University Sungkonghoe University Sangmyung University
23-1 Hawolgok-dong, Sungbuk-gu 1-1 Hang-dong, Kuro-gu 7 Hongji-dong, Jongno-gu
Seoul 136-714, Korea Seoul 152-716, Korea Seoul 110-743, Korea

Moon Hae Kim

Konkuk University
1 Hwayang-dong, Gwangjin-gu
Seoul 143-701, Korea
[email protected]

workers as one of the major policy measures by applying

ABSTRACT the SCM (Supply Chain Management) model to human
This paper describes how Korean Government has resource development [2].
designed and driven the innovation of undergraduate The basic concept of SCM is to optimize whole supply
curriculums to meet increasing industrial demand for networks to maximize total profit. Applying this concept to
quality IT experts in the computer-software field. The human resource development denotes that we have
computer-software field has been categorized into five recognized a series of educational process and career path
specialized areas, tracks. The embedded system software as a huge supply network so that optimization would be
area is one among them. Educational contents (including deployed into all of human resource development processes.
track curriculums, detailed syllabuses, and class materials)
have been designed and constructed for the tracks. First, a To reflect intensive and extensive technological changes
curriculum development methodology is described, which and industrial needs from academia, a study is necessary to
is used to develop curriculums in the computer-software solve and act as an antidote against the imbalance problem
field. Next, artifacts for the embedded software system between the skill factors demanded by industry and the
track produced in the process are described. By applying curriculums of universities. As a sub-project for the SCM
iterative and incremental principles of the methodology, all project, Korean Government launched a challenging
artifacts will be continuously updated and constantly project where curriculums and courses are designed and
upgraded as related technologies progress rapidly. constructed, based on their own estimated demand for IT
manpower.
Keywords According to IT industry, to solve the skill mismatch, the
track, curriculum, industry demand, demand-driven course, computer-software field needs to be subdivided into more
detailed syllabus, class material, course development specialized areas. For each specialized area, track in the
project, educational contents are to be properly constructed
1. INTRODUCTION and customized to the corresponding IT sector. The
Despite the excessive supply of IT manpower in the market, practical purpose of this project lies in producing students
many companies in Korea still find difficulty in recruiting as IT experts equipped with specialized skills. As the first
manpower of quality satisfying their needs. This is so stage to innovate academic curriculum, computer-software
called ‘skill mismatch’ phenomenon, where maturity levels field is categorized into five specialized tracks.
of skills of graduates from academic institutions are
lagging far behind the required level in the spot industrial With five tracks to pursue as majors in computer-software
sectors. Therefore, the cooperation between universities field, four demand-driven courses for each track are
and IT industry in producing IT manpower of quality is designed and their detailed syllabuses and course materials
urgently called for to create the effective labor pool of are constructed.
supply and finally balance its supply and demand. In the following section, a methodology is suggested to
To facilitate the cooperation, Korean Government has been develop demand-driven curriculums. In the next sections,
focusing on the training program of demand-driven IT the major artifacts of demand-driven curriculum

11
development for the embedded system software track are ›Œ™ˆ›–•GX
›Œ™ˆ›–•GY
described, which is followed by concluding remarks. ›Œ™ˆ›–•GZ

yŒ˜œ™Œ”Œ•›Gh•ˆ“ ššG—ˆšŒ kŒšŽ•G—ˆšŒ
2. METHODOLOGY FOR CURRICULUM Æ {™ˆŠ’ Æ {™ˆŠ’Gjœ™™Šœ“œ”
DEVELOPMENT
2.1 Curriculum Development as a Process of z›ˆ™›•ŽG—–•›G–™GˆG
—™–‘ŒŠ›
Change and Evolvement
Academic curriculums are to change and evolve over a
period of time. Curriculum development as a process of
change and evolvement is somewhat similar to software
development.
Spiral model, originally proposed by Boehm [1], is an
yŒˆ“¡ˆ›–•G—ˆšŒ p”—“Œ”Œ•›ˆ›–•G—ˆšŒ
evolutionary software process model that combines the
Æ mŒŒ‹‰ˆŠ’G™–”GG Æ kŒ›ˆ“Œ‹Gz ““ˆ‰œš
iterative and incremental nature of prototyping with the œ•Œ™š›ŒšGˆ•‹G•‹œš›™Œš Æ j“ˆššGtˆ›Œ™ˆ“
structural aspects of the linear sequential model.
Figure 1. Spiral model for curriculum development
Applying concepts and basic principles of the spiral model,
Curriculum Spiral model for demand-driven curriculum
development is derived and proposed. In the process, a 2.2 Human Infrastructure
curriculum is developed in a series of incremental releases. The human infrastructure for curriculum development is
That is, a whole development process is divided into classified in Figure 2.
several, time-boxed small-scaled projects. This small-
scaled project is called iteration stage and an iteration stage As a coordinator, Comprehensive Manager coordinates all
is again subdivided into four activities, called phases. phases of a small-scaled project, that is, an iteration stage.
Figure 1 depicts the curriculum spiral model that performs Comprehensive Manager plans overall process, collects
3 iteration stages, each of which contains four phases, and ideas, suggestions, and information from the rest of the
shows artifacts in each phase. In the rest of this section, participants and finalizes track decision, curriculum design
each phase is described in terms of its activities and and course materials. Comprehensive Manager identifies
artifacts. and organizes human infrastructure, assigns their roles and
coordinates their communications and finally resolves their
In the first phase in an iteration stage, Requirement conflicts.
Analysis phase, tracks are identified and selected by
analyzing industrial demands and requirements, and also by As a basic participant, Course Developer develops all
collecting feedbacks from universities involved in the artifacts from phases. Two or more Course Developers are
previous iteration stage. Partitioning tracks is to vertically assigned to each and every track. Course Developer
decompose a certain generalized field. A track should be a constructs track curriculum and makes class materials.
highly cohesive subfield of computer-software field. Track Expert, another participant, consists of Academic
In the Design phase, a curriculum is designed and Track Expert and Industrial Track Expert for each track.
developed for each track. Several industrial demand-driven Track Expert is involved in the process of constructing
courses are included in each curriculum. A track artifacts. Course Developer works in close cooperation
curriculum includes track goals, a course tree, and with Track Expert.
preliminary design for demand-driven courses. A course Consultant, as one of the stakeholders, consists of General
tree includes demand-driven courses, prerequisite courses, Consultant and Track Consultant. Track Consultant
basic computer science courses, and their associations. consists of Academic Track Consultant and Industrial
In the Implementation phase, a detailed syllabus and class Track Consultant. Consultant reviews and monitors all
materials are constructed for each demand-driven course. artifacts constructed by Course Developer. Lecturer,
another stakeholder, lectures using artifacts constructed by
In the Realization phase, semester classes are lectured, Course Developer.
based on the track curriculum, detailed syllabus, and class
materials. As input to the requirement analysis phase of the
next iteration stage, all feedbacks from the involved
universities and industries are collected.

12
 j––™‹•ˆ›–™
j–”—™ŒŒ•šŒG T System Integration (SI)
tˆ•ˆŽŒ™
T Embedded System Software (EM)
iˆšŠG T Multimedia and Game Software (MM)
j–œ™šŒGkŒŒ“–—Œ™
—ˆ™›Š—ˆ•›š hŠˆ‹Œ”ŠG{™ˆŠ’GlŸ—Œ™›
T Business Information Technology (BI)
{™ˆŠ’GlŸ—Œ™›
p•‹œš›™ˆ“G{™ˆŠ’GlŸ—Œ™›
In the software development (SD) track, the goal is to
educate skilled manpower with expertise in software
hŠˆ‹Œ”ŠG{™ˆŠ’Gj–•šœ“›ˆ•› development. It is recommended not to deal with
j–•šœ“›ˆ•› fragmentary skills and detailed application skills,
z›ˆ’Œ–“‹Œ™
p•‹œš›™ˆ“G{™ˆŠ’Gj–•šœ“›ˆ•› considering the limited time horizon of 4-year university
education. Instead, the curriculum focuses on training the
sŒŠ›œ™Œ™
nŒ•Œ™ˆ“Gj–•šœ“›ˆ•› ability of problem solving and that of self-adapting to rapid
changes in the practical IT field.
Figure 2. Human infrastructure for curriculum
development The goal of the system integration (SI) track is to train
manpower with practical knowledge required in system
3. TRACK: VERTICAL DECOMPOSITION development companies which make general business
applications. In order to produce students who understand
OF COMPUTER-SOFTWARE FIELD the whole process of system development, the curriculum
3.1 Necessity for Specialized Field Tracks is designed to focus on up-to-date technologies such as
software modeling, software development process, and
Applying industrial demands into academia, it should be web service computing.
considered what educational unit would be a suitable one
for bearing the task. From the educational perspective, In the embedded system software (EM) track, students are
decision for the choice of an appropriate educational unit is trained to have an understanding of various aspects of
one of the most important underlying factors to be embedded systems. The curriculum contains the
considered. An undergraduate curriculum, especially for establishment of system development environment,
science and engineering majors, should be the proper hardware control programming and application
combination of mathematics, understanding of principles, programming in embedded systems. Electronic engineering
practices, application, and skills for tools [3]. is merged into software engineering from the viewpoint of
software field.
Demand-driven curriculum needs to be balanced with five
factors mentioned above, and categorized for more The goal of the multimedia and game software (MM) track
specialized area by possible career pursuits of students. is to educate both multimedia software and game software
developers. Students are trained to have basic abilities to
The concept of track is introduced, which has a demand- have considerably high productivity in a short period of
driven curriculum for a specialized area while satisfying time after graduation. Multimedia software courses focus
the guideline of ABET, ACM, and IEEE/CS. ABET has on understanding of the overall multimedia area, including
‘program’ as a unit of accreditation. ABET guideline moving picture processing and animation, and achieving
indicates that each program should have its own objective, the ability of integrating and applying various digital media.
so track would have the objective of ‘satisfying demands Game software courses deal with the concept and
from specific IT area’. In this paper, a track can be technology of computer game production, and train
considered to be a proper educational unit (for students to have the ability to collaborate in practical game
undergraduate) composed of major issues reflecting production.
industrial needs.
In the business information technology (BI) track, the goal
3.2 Five Tracks and Ongoing Changes is to train IT consultants and IT business managers who
Selecting tracks is based on the work in [5], which have the ability to apply and manage rapidly changing
suggested several specialized tracks in the field. In order to information technologies of management. The curriculum
identify tracks, needs from IT industry experts are carefully basically intends for students of computer-software
examined. Requirements of universities are also considered. departments. It integrates courses for overall knowledge of
As a result, the computer-software field is divided into five management and courses for information technologies,
specialized tracks as follows: such as computers and communication.
T Software Development (SD) Some of the tracks mentioned above are closely related,
and some of them cover quite big areas. The number and

13
goals of tracks will be continuously updated and constantly Table 2. Track preference in each technology (%)
upgraded as IT technologies progress rapidly. Tracks can Track
be added, deleted or even merged. For example, Technology SI SD EM MM BI Etc.

information security track can be newly added on the track System 31.03 34.48 11.81 2.59 15.00 5.43
Application package 33.33 35.16 10.91 4.62 12.47 4.25
list. S/W
Embedded 13.00 22.42 41.65 6.73 14.35 1.85
Development tool 27.40 34.73 15.00 7.77 13.15 2.37
Subtotal 29.12 33.42 15.57 5.01 13.48 3.88
3.3 Demand Survey of the Five Tracks SI 34.48 26.51 8.49 6.51 17.73 6.40
Computer-related
Surveys on industrial preferences for the five tracks have service DB 18.57 25.00 6.43 8.57 34.29 7.14
been conducted [4]. About 2,000 Korean companies are Information security 21.11 51.11 14.44 2.22 7.78 3.33
Subtotal 32.21 28.58 8.87 6.27 17.99 6.18
surveyed (about 1,000 IT companies and about 1,000 non- Game 7.50 16.25 7.19 59.69 6.25 3.75
IT companies). Image · animation 22.00 16.00 2.00 17.00 10.00 33.00
Digital contents
Contents solution 29.32 23.41 13.41 13.86 15.45 5.45
The result shows demand preferences for human resources Other contents 22.86 30.00 7.50 11.43 18.57 9.64
in each track. Out of five tracks, SD and SI stand out in Subtotal 20.96 22.37 9.21 26.40 13.16 8.42
Information and Communication business 31.42 24.06 14.16 5.81 17.26 7.29
demand pressure from the industry. Table 1 shows communication
service Broadcasting service 26.58 24.74 11.32 7.11 22.11 8.16
preferences for the tracks in each IT profession. Table 2 Subtotal 30.28 24.22 13.49 6.11 18.40 7.49
shows preferences of the tracks in each technology. Communication equipment 18.53 32.06 20.88 3.24 13.24 12.06
Information and Communication terminal 13.54 35.83 26.46 7.92 8.33 7.92
communication Information equipment 25.12 28.98 17.20 5.42 18.81 5.55
equipment
Table 1. Track preference in each profession (%) Broadcasting equipment 17.27 20.91 48.18 0.45 11.36 1.82
Parts 23.95 28.42 18.29 3.29 16.97 9.08
Track Subtotal 21.74 29.68 21.53 4.69 15.58 7.24
SI SD EM MM BI Etc. Educational
Education 7.33 9.83 26.50 35.00 19.00 2.33
Profession service
IT consultant 28.67 25.98 13.47 6.94 18.94 6.01 Total 27.02 29.18 15.19 7.56 15.45 5.95
Project manager 25.79 27.34 13.13 7.83 15.38 10.53
System engineer
25.16 31.68 18.64 4.42 13.34 6.76
(analysis/design)
DB design · administrator 27.72 28.04 11.08 6.49 17.42 9.26
The first group consists of demand-driven courses, the
Computer information
20.01 41.05 14.93 6.36 13.00 4.66
skills of which are analyzed as demanded by IT industry.
SI/SW security engineer
development
and design
Network design ·
22.19 17.58 23.51 7.49 20.86 8.37 The second group consists of direct prerequisites of
administrator
Web engineer (development · demand-driven courses.
27.34 28.09 12.64 10.03 17.11 4.80
construction)
General S/W developer and
28.33 32.22 14.94 4.75 15.78 3.96
The third group consists of common fundamental courses,
programmer
System S/W developer and
which are classical computer science courses. These
19.98 26.48 33.63 6.06 11.39 2.47
programmer courses are included in all track curriculums in common.
Web planner and designer 25.69 28.45 9.28 11.66 17.01 7.91
Game / animation / graphic
planner
0.91 22.71 8.29 54.76 13.10 0.23 The basic notation to represent designed courses and their
Digital contents Game / animation / graphic
4.83 8.86 10.41 54.83 15.82 5.25 associations are shown in Figure 3. Course tree for the
developer
Virtual reality / animation /
19.67 26.46 6.71 29.16 3.80 14.21
embedded system software track is shown in Figure 4.
graphic designer
Web master 26.48 26.79 7.54 5.15 23.12 10.92
System
System administrator 30.54 23.54 7.35 11.50 18.58 8.48
operation and
Computer technology
administration
support technician
24.35 24.03 19.20 6.43 21.88 4.11 j–””–•Gœ•‹ˆ”Œ•›ˆ“GŠ–œ™šŒš
Education IT education 16.76 16.94 18.31 28.65 12.46 6.87
Business IT technology business 23.52 27.63 14.83 5.16 20.12 8.74 w™Œ™Œ˜œš›ŒG–G‹Œ”ˆ•‹G–™Œ•›Œ‹GŠ–œ™šŒš
Total 27.02 29.18 15.19 7.56 15.45 5.95 kŒ”ˆ•‹G–™Œ•›Œ‹GŠ–œ™šŒš

΁ΣΖΣΖ΢ΦΚΤΚΥΖ͑ΣΖΝΒΥΚΠΟΤΙΚΡ

4. CURRICULUM: HORIZONTAL Figure 3. Notation of three kinds of course grouping

DECOMPOSITION FOR TRACKS
4.2 Demand-Driven Courses
4.1 Track Curriculum Outline A track curriculum includes four demand-driven courses.
Track curriculums are designed and constructed, with the The courses are designed and constructed to reflect the
main focus on the specialized skills demanded by IT demands of IT industry. They are targeted to senior year
industry. A track curriculum includes a course tree. and designed to have the specialized skills that turned out
Courses in the tree are grouped into three types. to be demanded from the buyers, IT industry. Table 3
shows the mapping between these courses and the
specialized skills for the embedded system software track.

14
j–”—œ›Œ™ j–”—œ›Œ™ wŽ””•Ž
p•›™–‹UG›– s•œŸ l”‰Œ‹‹Œ‹ l”‰Œ‹‹Œ‹ Using the artifacts from this work,
l”‰Œ‹‹Œ‹ z š›Œ” z š›Œ” z š›Œ”
wŽ””•ŽGp wŽ””•ŽGpp tŒ›–‹–“–Ž 
z š›Œ”š wŽ””•Ž z–›žˆ™ŒGp z–›žˆ™ŒGpp
the governmental SCM project
started in the beginning of 2004.
p•›™–‹UG›– l”‰Œ‹‹Œ‹ l”‰Œ‹‹Œ‹ Korean Government selected 39
kˆ›ˆ tŠ™–T
j–”—œ›Œ™ kˆ›ˆ‰ˆšŒ z š›Œ” h——“Šˆ›–• universities (19 for the embedded
z›™œŠ›œ™Œš —™–ŠŒšš–™
zŠŒ•ŠŒ oˆ™‹žˆ™Œ z–›žˆ™Œ
system software track) from all over
uŒ›ž–™’•Ž the country. Each university in the
kšŠ™Œ›Œ
h“Ž–™›”š ˆ•‹Gkˆ›ˆ program selected one track and
tˆ›U
j–””U
adopted the suggested track
kŽ›ˆ“
j–”—œ›Œ™ z š›Œ”
curriculum. At the point of yielding
z š›Œ” students equipped with specialized
h™Š›ŒŠ›œ™Œ wŽ””•Ž
kŒšŽ•
skills and expertise, meaningful
j–”—œ›Œ™ z–›žˆ™Œ v—Œ™ˆ›•Ž feedbacks will be obtained to
zŒŠœ™›  l•Ž•ŒŒ™•Ž z š›Œ”š improve the curriculums. The
feedbacks are expected from the
parties involved.
Figure 4. Course Tree for the embedded system software track
As the Curriculum Spiral model
Table 3. Specialized skills of demand-driven courses for explicitly suggests, curriculum
the embedded system software track development procedures will be iteratively and
incrementally performed in order to promote the
Demand-Driven Specialized Skills curriculum. First of all, changes are expected and inevitable
Courses in tracks. Proper classification and restructuring of tracks in
Startup code Development, computer-software field will lay the groundwork for
Memory/Clock/IO Control, Linux developing a full-fledged demand-driven curriculum.
Embedded System
System Programming, Device
Software I Secondly, track curriculums, detailed syllabuses, and class
Driver Development, and Assembly
Language Programming͑ materials need to be maintained and elaborated according
VHDL, Combinational/Sequential to feedbacks stemming from the universities and IT
Embedded System industry.
Circuit Design, Timing Analysis and
Hardware
Design, and System H/W Design
RTOS concept, RTOS based Finally, demand-driven courses need to be continuously
Embedded System updated and constantly upgraded as IT technologies
Programming, and
Software II progress rapidly.
DMA/Timer/Interrupt Programming
Embedded Embedded Network Programming, Acknowledgements: Thanks to Korean Ministry of
Application TCP/IP, Client-server Programming, Information and Communication, and Institute of
Software and GUI programming Information Technology Assessment for the support in
development of demand-driven curriculums in the
computer-software field.
5. CONCLUSION AND FUTURE WORKS
IT education in academia has not properly accommodated 6. REFERENCES
[1] Boehm, B. A Spiral Model for Software Development and
the changing industrial demands. This paper presents
Enhancement, IEEE Computer, vol. 21, no. 5, May 1998, pp.
research results to solve the imbalance between the skill 61-72.
factors demanded by industry and the curriculum of
[2] Lee, J., Om, K., Chang, J., and Pang, S. Innovation of IT
universities.
human resource development in Korea. 14th International
As a curriculum development methodology, Curriculum Vocational Education & Training Association Conference,
Spiral model has been suggested and applied. August 2004.
[3] Meyer, B. Software Engineering in the Academy. IEEE
As the first artifact of this work, five specialized areas in
Computer, May 2001, pp. 28-35.
the computer-software field, called tracks, have been
identified to reflect the demand from IT industry. The goal [4] Demand Survey of Specialized Skills. Institute of
Information Technology Assessment, March 2004. (in
for each track has been established along with the demand-
Korean)
driven courses, which are major artifacts of the curriculum
development process. Detailed syllabus and class materials [5] Research on Computer/Software Training in Higher
have been designed and constructed as well. Education. Korea IT Industry Promotion Agency, November
2001. (in Korean)

15
 NEXCESS: Nagoya University Extension
Courses for Embedded Software Specialists
Masaki Yamamoto, Hiroyuki Tomiyama, Hiroaki Takada , Kiyoshi Agusa ,
Kenji Mase, Nobuo Kawaguchi, Shinya Honda and Nobuyuki Kaneko


Government
Abstract— In October 2004, Nagoya University has started an * Ministry of Education, Culture, Sports,
extension program on embedded software, called NEXCESS Science and Technology
(Nagoya university EXtension Courses for Embedded Software
Specialists). NEXCESS aims at education of engineers in industry, Grant
and is financially supported by the government. This paper
describes the organization and course design of NEXCESS. Also, NEXCESS
our experience of the first half year is reported. * Other Universities
Nagoya University Lecturers
* Non-Profit Making Organizations
* Information Technology Center
Index Terms—Education, Embedded, Software - NPO TOPPERS Project
* Graduate School of Information Science
- NPO SESSAME

Advisory Committee
I. INTRODUCTION
Students Advisors Lecturers

D ue to the ever increasing demand for the development of

embedded software, it is an urgent issue to increase the
number of embedded software engineers as well as to improve
Companies

their skills. Since embedded software is usually developed Fig. 1.  Organization of NEXCESS
under very limited hardware resources, specialized skills are
program on embedded software, called NEXCESS (Nagoya
required for the embedded software engineers. The complexity
university EXtension Courses for Embedded Software
of embedded software has been growing, while the
Specialists) [1]. NEXCESS is targeted towards embedded
time-to-market pressure has been strengthened. Needless to say,
software engineers in industry. We have designed eight courses
the reliability or quality must not be compromised.
on embedded software and developed teaching materials for the
In Japan and many other countries, however, few
courses.
universities provide sufficient classes on embedded software
This paper presents an outline of NEXCESS and also reports
development. Students graduate from their universities without
our experiences from October 2004 to March 2005.
acquiring enough skills on embedded software even if they
The rest of this paper is organized as follows. Section 2
major in computer science or electronic engineering. In most
described the organization of NEXCESS. Section 3 presents
companies, on the other hand, OJT (on-the-job training) is only
how we have designed the courses. Section 4 reports our
the method for training unskilled freshmen. The OJT is seldom
experience of the first six months.
systematic, so they can hardly acquire wide knowledge.
In October 2004, Nagoya University has started an extension
II. ORGANIZATION
NEXCESS is supported by Ministry of Education, Culture, Sports, Science
and Technology, Japan. The organization of NEXCESS is depicted in Fig. 1.
Masaki Yamamoto is with Information Technology Center, Nagoya
NEXCESS is composed of one center and one graduate school
University, Japan (e-mail: yamamoto@ itc.nagoya-u.ac.jp).
Hiroyuki Tomiyama is with Graduate School of Information Science, at Nagoya University. At present, eight faculty members (three
Nagoya University, Japan (e-mail: [email protected]). full professors, two associate professors, one senior researcher,
Hiroaki Takada is with Graduate School of Information Science, Nagoya one young post-doctoral researcher and one doctoral
University, Japan (e-mail: [email protected]).
Kiyoshi Agusa is with Graduate School of Information Science, Nagoya researcher) and one research assistant are involved in
University, Japan (e-mail: [email protected]). NEXCESS. In addition, there is an advisory committee with 11
Kenji Mase is with Information Technology Center, Nagoya University, members invited from industry. The advisory members are
Japan (e-mail: [email protected]).
Nobuo Kawaguchi is with Information Technology Center, Nagoya
typically senior managers in their companies.
University, Japan (e-mail: [email protected]). The faculty members in Nagoya University offer most of the
Shinya Honda is with Information Technology Center, Nagoya University, courses. However, some courses are partially supported by
Japan (e-mail: [email protected]).
Nobuyuki Kaneko is with Information Technology Center, Nagoya
engineers in industry, professors of the other universities and
University, Japan (e-mail: [email protected]). members of Specified Nonprofit Corporations (NPOs).

16
 assume that the career path is decided at the advanced level. Fig.
2 illustrates the relationship between the levels of technical
skill and the career paths.
B. Designing Overall Courses
In many company, an engineer at introductory level works
for the programming and testing process. We planed the
introductory engineer must study structure programming,
embedded C programming and testing. These skill are useful in
the programming and testing process.
In many company, an engineer at intermediate level works
for design and requirement process with his subordinate. We
planed the intermediate engineer must study the structure
design, requirements analysis and project management.
And In many company, an engineer at advances level works
for the special technical field. We planed the advanced
Fig.2. echnical levels and career paths engineer must study real-time OS, C-based hardware design
and other special technologies.
Specifically, NPO TOPPERS Project [2] and NPO SESSAME In 2004, eight courses have been developed. The courses are
[3] are primary contributors to NEXCESS. classified based on the levels of technical skills as follows.
NEXCESS is financially supported by the Japanese (1) Introductory class (one course):
government. An approximate total of 300 million yen is granted ̌Fundamentals of the embedded software development
for five years from 2004 to 2009. technology”
(2) Intermediate class ( two courses)
01: “Design methodology and management of embedded
III. DESIGNING EDUCATIONAL COURSES
software”
A. Classification of Technical Skills and Careers 02: “Software design technology with a real-time OS”
(3) Advanced class (five courses)
When we designed extension courses, we first classified
01: “Internal structure of a real-time OS”
technical skills as follows.
02: “C-based embedded hardware design”
(1) Introductory Level
03: “System control middleware and application”
An engineer at this level can accomplish his/her duties under
04: “Software engineering for embedded systems”
directions by his/her superior. Typically, engineers with an
05: “Ubiquitous interface and embedded software
experience of less than five years fall into this level.
programming for image processing”
(2) Intermediate Level
As mentioned in Section II, five professors and thee
An engineer at this level can promote his/her projects by
researchers at Nagoya University are involved in NEXCESS.
his/her own judgment. Typically, engineers with an experience
Each of the professors is responsible to one advanced course,
of five to ten years fall into this level.
while three researchers are primarily in charge of introductory
(3) Advanced Level
and intermediate courses. Additionally, external lecturers from
An engineer at this level can lead his/her company. Typically,
other universities, NPOs and companies are invited whenever
engineers with an experience of more than ten years fall into
necessary.
this level.
Terms of the courses are designed to be short so that
Here, the number of years of experience is not an absolute
engineers in industry can attend the NEXCESS courses without
criterion but just a rough one. It may vary depending on
largely sacrificing their job. Introductory and intermediate
companies and individuals.
courses are four days long, advanced-01 is three days, and the
We also classified career paths for engineers as follows.
other advanced courses are two days.
(1) Administrative Managers
The eight courses are independent of each other. A student
Some engineers will become administrative manager who
does not have to attend all the courses. One can take one or
promote their company’s business through managing their
more courses which he/she needs.
teams.
(2) Technical Specialists
Some other engineers will become technical specialists who C. Designing Individual Courses
promote their company’s business through developing leading It is widely recognized that project-style education is very
technology. effective. However, it generally takes a long time (typically
An advanced-level engineer understands his/her ability as an more than two weeks) and it is not easy to complete a realistic
administrative manager and as a technical specialist. Thus, we project within a few days. However, more than two weeks are

17
 㪐㪇 㪏㪊
㪏㪇
㪎㪇 㪍㪎

㪍㪇
㪌㪈 㪌㪉
㪌㪇 㪋㪋
㪊㪐 㪋㪈㪅㪌
㪋㪇
㪊㪇 㪊㪇㪅㪋
㪊㪇 㪉㪍
㪉㪉 㪉㪉
㪉㪇
㪈㪇
㪇

㪉
㪈

㪋
㪉

㪌
㫆㪈

㪺㪼
㪉

㪼㪇
㪇

㪼㪇

㪼㪇

㪼㪇

㪼㪇
㫀㪸㫋
㫉

㪼㪇
㪥㫆

㫋㫆

㪸㫅
㩷㪥

㫀㪸㫋

㫅㪺
㫀㪸㫋

㫅㪺

㫅㪺

㫅㪺

㫅㪺
㪼㪻
㪺
㫐㩷

㪻㫍
㫉㫐

㪻㫌

㫍㪸

㫍㪸

㫍㪸
㫆㫉

㪼㪻

㫍㪸

㫍㪸
㪼㪻

㫉㫄
㫋㫆

㩷㪸
㫋㫉㫆
㪺㫋

㪸㪻
㪸㪻

㪸㪻

㪸㪻

㪸㪻
㫄

㫋㪼
㫌㪺

㫆㪽
㪻㫌

㪼㫉
㪼㫉
㩷㪠㫅

㩷㪠㫅

㪼㩷
㫆㪻

㫋
㪠㫅㫋
㫉㫆

㪸㪾
㪠㫅
㫆㪽

㫆㪽
㫋㫉

㪠㫅㫋

㪼㩷

㪸㫉
㪼㩷
㪠㫅

㪸㪾

㪸㪾

㪸㫍
㪸㫉

㪸㫉
㪸㫍

㪸㫍
Fig.4㩷 Number of applicants
Fig.3. programming with a microcontroller board so the number of persons who have completed their course was
214 in total.
hardly acceptable for industry. Therefore, we have prepared a For a project with microcontroller boards, we have prepared
set of small workshop for most of the NEXCESS courses so one board for each learner. In addition to lecturers, four
that it does not take a long time to complete each workshop, but teaching assistants (TAs) assisted the projects on the average.
still one can experience key points in embedded system design. All the TAs are graduate students in Nagoya University.
A few workshops are team-based, while the other workshops Through the courses, we requested the learners to answer a
are done individually. Several workshops use microcontroller detailed questionnaire via the Web site. We found that a
boards for programming and some other workshops are web-based questionnaire is more effective than a paper-based
discussion-based requirement analysis and code review. one. A large number of detailed comments were given by the
For example at the introductory course the small workshop is learners.
making TMER. The TMER notices of termination at preset All the courses were recorded with a digital video camera
time. This TMER has two SWs and two LEDs. First SW is for which was synchronized with the presentation slides. After the
TMER start and second SW is for finish time length. The courses, we have created e-learning contents so that the
TMER program is only 500 lines C programming. And the learners can review them at home or office through the Internet.
student can learn how to initial a microprocessor, how to use The e-learning contents were provided to the learners for two
microprocessor timer, how to get a switch, how to turn on a months after the course.
LED, how to build program and how to write flash ROM.
B. The Number of Applicants
We have also developed textbooks for the courses. The
textbooks are based on presentation slides. Each textbook The number of applicants for each course is shown in Fig.4.
consists of 196 to 652 pages. The average numbers of applicants for the introductory,
intermediate and advanced courses were 67, 41.5 and 30.4,
respectively. Thus, applicants tend to decrease as the technical
IV. EXPERIENCE AND ANALYSIS level rises. This tendency is very natural since the scope of the
course inevitably narrow as its technical level arises.
As mentioned above, NEXCESS is a five-year project
Applicants for the second round of the introductory course
(exactly, four years and a half). This section describes and
were largely decreased. This is mainly because the interval
analyzes our experience of the first half-year.
between the two practices of the introductory course was close.
A. Practice The number of applicants for advanced-01 was much larger
We held nine courses from November 2004 to March 2005. than that for the other advanced courses. As described in
We held the introductory course two times. Each of the Section 3, advanced-01 is a course on RTOS internals. Thus, it
intermediate and advanced courses was held once. The courses is revealed that skilled embedded software engineers have a
were carried out weekdays from 9:30 to 17:00. Each day was strong interest in RTOSs.
composed of four time periods each of which is 90 minutes C. Ages of Applicants
long.
The average ages of applicants for the introductory,
The capacity of the introductory and intermediate classes is
intermediate and advanced courses were 28.5, 32 and 35.2,
30 persons, while that of advanced classes is 20.
respectively. If we assume that they join their company at 24
Applications to the NEXCESS courses were received
years old, the numbers of years of experience are 4.5, 8 and
through the Web site. We have received a total of 369
11.2. These numbers are very close to our assumptions shown
applications.
in Section 3.1.
Since the applications largely exceeded our capacity, we
have selected 227 persons. Out of them, 13 persons cancelled,

18
 㪈㪇㪇㩼 㪌

㪏㪇㩼 㪋㪅㪌

㪍㪇㩼 㪋

㪊㪅㪌
㪋㪇㩼
㪊
㪉㪇㩼

㪌
㪈

㪉
㫆㪈

㫆㪉

㪼㪇

㪼㪇

㪼㪇

㪼㪇

㪼㪇
㪼㪇

㪼㪇
㩷㪥

㩷㪥

㫅㪺

㫅㪺

㫅㪺

㫅㪺

㫅㪺
㫀㪸㫋

㫀㪸㫋
㪇㩼

㫉㫐

㫉㫐

㫍㪸

㫍㪸

㫍㪸

㫍㪸

㫍㪸
㪼㪻

㪼㪻
㫋㫆

㫋㫆

㪘㪻

㪘㪻

㪘㪻

㪘㪻

㪘㪻
㫉㫄

㫉㫄
㫌㪺

㫌㪺
㫉㫐

㪌
㪈

㫊㫀㫊
㪉

㫋㪼

㫋㪼
㫆㪻

㫆㪻
㪼㪇

㪼㪇

㪼㪇
㪼㪇

㪼㪇
㪼㪇

㪼㪇
㫋㫆

㪠㫅

㪠㫅
㪿㪼

㫋㫉

㫋㫉
㫅㪺
㫅㪺
㫅㪺

㫅㪺

㫅㪺
㫀㪸㫋

㫀㪸㫋
㫌㪺

㪠㫅

㪠㫅
㫅㫋
㫍㪸

㫍㪸
㫍㪸

㫍㪸

㫍㪸
㪼㪻

㪼㪻
㫆㪻

㪪㫐
㪘㪻

㪘㪻
㪘㪻

㪘㪻

㪘㪻
㫉㫄

㫉㫄
㫋㫉
㪠㫅

㫀㫅㫋㪼㫉㪼㫊㫋 㫌㫊㪼㪽㫌㫃 㪼㪸㫊㫐㩷㫋㫆㩷㫌㫅㪻㪼㫉㫊㫋㪸㫅㪻 㫆㫍㪼㫉㪸㫃㫃㩷㫁㫌㪻㪾㪼㫄㪼㫅㫋

㫋㪼

㫋㪼
㪠㫅

㪠㫅

㪺㫆㫅㫊㫌㫄㪼㫉㩷㫌㫊㪼 㫀㫅㪻㫌㫊㫋㫉㫀㪸㫃 Fig.6㩷 Evaluation by learners

㪼㫅㫋㫉㫌㫊㫋㪼㪻㩷㪻㪼㫍㪼㫃㫆㫇㫄㪼㫅㫋 㪻㪼㫍㪼㫃㫆㫇㫄㪼㫅㫋㩷㪼㫅㫍㫀㫉㫆㫅㫄㪼㫅㫋
㪦㪪㪃㩷㫄㫀㪻㪻㫃㪼㫎㪸㫉㪼 㪺㫆㫅㫊㫌㫃㫋㪸㫅㫋
is not always negative because one can realize what he/she does
㪼㫋㪺 not understand.
Fig.5㩷 Types of companies H. Usefulness
Fig. 6 shows that the score of usefulness is located between
D. Types of Companies interest and easiness, and is a strong relationship with the
Types of the companies to which applicants belong are overall score.
summarized in Fig. 5. Consumer and industrial electronics For advanced-03, 04 and 05, the score of usefulness is more
manufactures account for about 60%. Specifically, there were a than 0.5 point lower than that of interest. This is mainly because
large number of applications to the introductory and most learners were very conscious of how to apply what they
intermediate courses from consumer electronics companies. learned to their daily work, and they felt that some part of the
61.9% of applications were from the Tokai area where advanced courses are not directly applicable.
Nagoya University is located. 19% were from the Kansai area On the other hand, the contents of the introductory and
(including Osaka, Kobe, Kyoto and so on), and 15.2% were intermediate courses are fundamental, so the score of
from the Kanto area (including Tokyo, Yokohama, Kawasaki usefulness is generally high.
and so on). We received some applications from the Kyushu I. How to Get to Know NEXCESS
(Fukuoka, etc.) and Tohoku (Sendai, etc.) areas. 44% of applicants were directed by their superiors. It should
E. Analysis of e-Learning Review be noted that the percentage is up to 63% for the introductory
After the courses, we provided e-learning contents so that courses. Since the courses were held weekdays, understanding
learners could review them at home and office. About 57% of and permission by their superior is necessary. However, 9% of
the introductory course learners have accessed the e-learning applicants confessed that they did not obtain permission by
contexts, while those of intermediate and advanced courses their superior.
were 32% and 27%, respectively. J. Reasons for Cancellation and Absence
F. Evaluation by Learners Since the number of applications exceeded the capacity, we
We requested the learners to rate the courses from 5 (highest) have selected attendees for most of the courses. However, 17
to 1 (lowest) in terms of interest, usefulness, easiness to persons (five for intermediate courses and twelve for advanced
understand and overall evaluation. The results are summarized courses) were cancelled or absent.
in Fig. 6. The average score of overall evaluation is 4.4, which We have asked the reason to them, and received responses
we think is a very high score. from seven persons. Four answered that it was because of some
urgent work. Three out of them judged it by themselves, and
G. Easiness to Understand one was directed by his superior or customer.
The score of easiness to understand is generally lower than
that of interest. Especially, the difference between easiness and V. SUMMARY
interest is more than 0.6 points at the second round of the Education of engineers in industry as well as ordinary
introductory course, intermediate-02, advanced-03 and students is one of important responsibility of universities.
advanced-05. We have in depth analyzed comments by those Nagoya University has started an extension program on
who gave a low score to easiness. The analysis reveals that the embedded software, named NEXCESS, with financial support
low rating is mainly due to practices of programming. On the by the government. From October 2004 to March 2005, we
other hand, easiness of advanced-02 which also has a have held in total nine courses. The evaluations by the
programming practice is 4.3, which is not low. Some learners attendees were generally high.
of advanced-02 wrote that the programming was easy, so the NEXCESS is now in the second year. We are continuing to
practice needs to be increased. improve our courses. Especially, this year, we plan to open a
If one feels difficulty in programming, he/she tends to give a new course for educating future educators so that they can
low score to easiness. In general, giving a low score to easiness educate young engineers in their companies.

19
 ACKNOWLEDGMENT
We would like to thank NPO SESSAME, NPO TOPPERS
Project, Professor Atusi Onisi (Ritumeikan University),
Professor Masamitu Noro (Nanzan University), Professor
Atusi Sawada (Kyoto University), Professor Atusi Yoshida
(Wakayama University), ATR Media Information Science
Laboratories, Fujitsu Prime Software Technology and Soliton
Systems, Inc., for their supports.

REFERENCES
[1] NEXCESS, http://www.nexcess.itc.nagoya-u.ac.jp/
[2] NPO TOPPERS Project, http://www.toppers.jp/
[3] NPO SESSAME, http://www.sessame.jp/

20
 Towards laying common grounds
for embedded system design education
Peter Marwedel, Senior Member, IEEE

 section III. In section IV, we will discuss our experience with

Abstract—In this paper, we propose to introduce a common the course structure. Section V will provide a conclusion.
introductory course for embedded system education. The course
puts the different areas of embedded system design into II. RELATED WORK
perspective and avoids an early over-specialization. Also, it
motivates the students for attending more advanced theoretical To a major extent, course structures are influenced by
courses. The content, the structure and the prerequisites of such available text books. Hence, currently available text books
a course are outlined. The course requires a basic understanding (together with information about courses on the web) give an
of computer hardware and software and can typically be taught impression on how embedded systems are currently taught.
in the second or third year. Traditionally, text books on embedded system design have
focused on the very specific problem of interfacing computers
to physical environments and the programming of these
Index Terms—Embedded systems, education, introduction, computers with interrupts and memory maps. There are a
curriculum significant number of such books [2]-[6].
However, this view of embedded systems is much too
I. INTRODUCTION restricted. The scope of embedded system design has recently

A CCORDING to many forecasts, the importance of

embedded systems will be growing over the coming
years. It is obvious, that traditional education focusing
been described in a book by Sifakis et al. [7]. While this book
lists the content that should be covered in research, it does not
present approaches for how embedded system education can
either mostly on hardware (as in many EE programs) or be taken into account by universities.
mostly on software (as in many CS programs) will not be Other text books that are available cover other specific
sufficient. According to [1], there is a lack of vision and a lack areas of embedded system design. For example, the book by
of maturity of the domain and many courses do not present a Jantsch [8] focuses on models of computation. A similar
sufficiently wide perspective. According to the same source, remark applies to the text book by Vahid [9]. There, the focus
the result is that industry has difficulty finding adequately is on implementing finite state machines. The book by Wolf
trained engineers, fully aware of design choices. [10] is used for many courses. However, a number of
Consequently, new educational programs have to be designed important topics are not covered in the book. In general,
to provide graduates with the required knowledge and skills to covered areas are certainly important, but courses based on
design embedded systems. It would be feasible to design a those books fail to provide a broad overview over issues in
special program for embedded system design. This was done, embedded system design. A broader view is also requested in
for example, at ALARI (see www.alari.ch). However, due to [1]. It is stated clearly that “training takes place continuously
the limited resources at most universities and in order to avoid during professional life, and it is not easy to distinguish what
an inflation of programs, we suggest to incorporate the should be learned during primary education and during
required education into existing EE and CS programs. This continuous training. Yet, it seems that fundamental bases are
allows the efficient use of resources and avoids over- really difficult to acquire during continuous training if they
specialization of students. However, this leaves us with the haven’t been initially learned, and we can think we must focus
problem of identifying the areas to be covered in embedded on them.” The proposed course is consistent with this view
system education and also with the problem of properly and can be seen a key element in the implementation of the
integrating embedded system education into existing curricula. requirements. However, our approach aims at the
Mutual dependences have to be identified. This paper presents undergraduate level, whereas [1] tries to avoid making
answers to the above problems. proposals for already tightly packed undergraduate curricula.
It is structured as follows: related work will be presented in Reference [1] also introduces the distinction between “a
section II, and the proposed course will be described in deductive style of education, where students go from theory to
practice” and “a more inductive approach, which adopts the
reverse order.” Our approach is more of the deductive style,
but does include references to applications. A broad view of
Manuscript received July 30, 2005.
Peter Marwedel is with the University of Dortmund, 44221 Dortmund,
embedded system design is also implemented in the Berkeley
Germany; phone: +49 231 755 6111; fax: +49 231 755 6116; e-mail: approach to embedded system design [11]. The Berkeley
[email protected].

21
approach seems to be focussing more on the use of tools. Due examples can be included in a curriculum. Teaching hardware
to the differences between the two approaches, some of the design is deferred: since many CS students will actually not be
tools used in the Berkeley course are left for more advanced involved in hardware design, it is taught in a more specialized
courses in our approach, the “Dortmund approach”. “EDA” course (see below). It would be nice to include
evaluation in the introductory course. However, we found it
III. OUTLINE OF THE PROPOSED COURSE rather difficult to select material that is applicable to a wide
range of situations. Reliability evaluation is a notable
A. Content of the proposed course exception, since standard techniques are known for that area.
The course proposed in this paper has been designed over a The course is complemented by a text book [12] and slides
period of almost ten years. During this period, material has on a web site [13]. The web site also contains links to related
been added to and deleted from the course. The selection of information and to courses referring to the text book.
the material for the current version of the course is based on Obviously, it is not feasible to cover all potential topics that
an analysis of presentations at conferences, reviewed papers, colleagues might want to teach in the suggested course.
discussions with industry and other personal talks. Overlaps Therefore, the structure of the course has been designed such
with existing courses (e.g. on control theory or digital signal that “plug-in's” can be easily added. Such “plug-in's” provide
processing) have been removed. more detailed information which the presenters might want to
The resulting scope of the course is the following: focus on. In fact, we have designed some plug-in's ourselves.
1. Introduction (Definitions, scope, examples, common These include the following:
properties); o Detailed description of UML diagrams;
2. Specification techniques: Models of computation, o Computation of invariants of Petri nets;
communication methods, StateCharts, SDL, VHDL, o Proof of optimality of rate monotonic scheduling;
Petri nets, UML diagrams; o D-algorithm for gate-level testing.
3. Embedded system hardware: hardware in the loop, These plug-ins are available in “more in-depth” sections on
discretization, communication, processors, FPGAs, the slides.
memory, D/A-converters; A lab is an indispensable part of the course. Due to the
4. Scheduling, operating systems for embedded systems broad coverage of topics, the lab cannot and should not offer
and other standard software: standard real-time hands-on experience to tools in all of the above six areas. We
scheduling algorithms, properties of RTOSes, propose to use a mixture of theoretical assignments and a
fundamentals of middleware; limited set of tools to be used. The following list includes
5. Implementing embedded systems with examples for each of the above areas:
hardware/software codesign: high-level 1. Search for definitions, characterization of
transformations (loop transformations), array folding, embedded systems, implications of the definition
task concurrency management, hardware/software of reliability and maintainability;
partitioning, optimizations for power reduction, 2. Using tools for the hierarchical description of
specialized compiler techniques for embedded finite state machines like StateMate or StateFlow
systems, design flows; (hands-on experience), proofs concerning the
6. Validation: simulation, types of models in formal depth of SDL FIFO buffers (simple examples),
verification, introduction to issues in testing. designing and showing properties of Petri nets,
This course is designed for about 60 hours (at 45 mins) of working with UML diagrams;
lectures and 30 hours of labs. 3. Using LEGO® Mindstorm robots as an example of
The order of the presentation is the order used above and is hardware in the loop (hands-on experience);
consistent with the dependencies between design information 4. Solving scheduling problems, simple proofs in
(see fig. 1). scheduling theory;
5. Generation of integer programming models for
scratch pad allocation, hardware/software
partitioning and dynamic voltage scaling, using
the SCE system on a chip (SoC) design
environment based on SpecC [14], experimenting
with program optimizations like loop tiling and
loop unrolling;
6. Generation of examples of test cases, manual test
compression of test responses, writing self-test
programs for processors.

Fig. 1: Design information flow B. Prerequisites

Application knowledge, hardware design and evaluation are The proposed course requires the students to have gained
not covered in the course. Application knowledge can only be experiences in the following areas (see fig. 2):
taught in more specialized courses and only one or two

22
 knowledge in more specialized courses. Such more advanced
courses could include the following topics (see also fig. 2):
o Control theory;
o Digital signal processing and wireless
communication;
o Machine vision;
o Real-time systems, advanced scheduling algorithms,
scheduling theory;
o Robotics;
Fig. 2: Prerequisites and follow-up courses o Courses on selected application areas (automotive,
telecom, consumer market, industrial control);
o Basic programming skills and the knowledge of o A large application project;
fundamental algorithms like topological sorting. o Presentations by the students on selected advanced
o A basic understanding of computer arithmetic, topics;
computer structures and computer organization as o Electronic design automation (EDA) and hardware
well as the implementation of higher level design, SystemC, using field programmable gate
languages by assembly programs. This arrays (FPGAs), hardware synthesis algorithms,
requirement can be met by attending a course placement, routing;
based on the introductory book by Hennessy and o Formal verification of embedded systems,
Patterson [15]. The fundamentals of finite state equivalence checking, model checking, theorem
machines must be known. proving.
o Math education, including linear algebra and These courses should include hands-on experiences
probability theory may be required for the wherever possible. It is suggested to include a major project in
discussion of certain more specialized material. the educational program. At Dortmund, such projects are
Integrals should be known as a result of high- organized such that students have to work in teams of up to 12
school education. students (so-called project groups). In a typical CS program,
o A basic understanding of electronic circuits is only a certain percentage of the students will select an
necessary for the section on embedded system embedded systems project. Those who do, benefit from the
hardware. This includes the capability to described course. Skills resulting from such a project should
understand digital logic (especially CMOS logic), be comparable to those resulting from the corresponding
Kirchhoff's laws and operational amplifiers. It is courses at Berkeley [11].
assumed that physical terms such as currents, Obviously, some of these courses do already exist at many
voltages, power, energy, and electrical fields are universities. Preceding these courses by an embedded systems
also known (typically, the level reached at good course as outlined should improve the motivation of the
high-schools is sufficient). students and put the more specialized material into
o Basic understanding of operating systems, perspective.
including memory maps, the use of interrupts,
system calls, real-time clocks and timers, mutual IV. EXPERIENCES
exclusion and task synchronisation. The proposed course has evolved during the past ten years.
Obviously, the list of prerequisites is not very long. During the last two years, the course has been taught from the
Typically, the proposed course can be taught rather early in published textbook and slides. Two types of classes were
the curriculum. For CS students, all prerequisites are available involved:
in the fourth term at our University. Due to some other 1. Each winter term, the course is taught in German to
constraints, the fifth term is the first term in which students about 100 students. While the majority of the
can actually enrol themselves into the course (and a large students are going for a diploma degree in computer
amount of students do). science, the course has also been opened for students
For computer engineering (CE) or information technology going for a diploma degree in information technology
(IT) students, all prerequisites should be available in the offered by the department of electrical engineering
fourth term as well. and information technology.
For electrical engineering (EE) students, programming 2. Each summer term, about 3/4 of the material is
skills, algorithm knowledge and knowledge about operating covered in a shortened course that is given in
systems may be missing. However, it would make sense to English. Students in this course are going for a
add these courses for EE students who would like to specialize master's degree in automation and robotics, are guest
in embedded systems. students from various other countries or are going for
the same degree as the students in the winter course,
C. Suggested follow-up courses
but would like to improve their foreign language
Due to the rather broad coverage of embedded systems in skills. This course is typically attended by about 40
the suggested course, it is recommended to extend the students students.

23
 Both courses include a lab, mid-terms and finals. Labs V. CONCLUSION
comprise theoretical and practical work. Theoretical work In the paper, we have proposed the structure of a standard
consists of solving assignments, e.g. on real-time scheduling. course on embedded systems that can be taught rather early in
Practical work involves programming Lego Mindstorm robots a computer science, computer engineering or electrical
and using hierarchical state diagram specification techniques. engineering curriculum. The course has been well-received by
A dominating observation for all the courses following the a large number of students and the corresponding text book
structure outlined is the large motivation and enthusiasm with has been picked-up by a number of departments. It is
which the courses were received. Students consistently suggested to introduce a course following the structure
reported that the courses opened a new area for them. outlined above into the CS, CE and EE education.
While all courses followed the structure, no “plug-in's”
were available in the very first iteration. This resulted in
requests for some more in detailed coverage of certain areas. REFERENCES
This is taken into account by adding special “in-depth”
[1] ARTIST network of excellence: Guidelines for a Graduate Curriculum
sections to the course and also to the slides. These sections on Embedded Software and Systems, http://www.artist-embedded.org
cover, for example, proofs for the optimality of rate- /Education/Education.pdf, 2003
monotonic scheduling. The introduction of these sections [2] Jack G. Ganssle: Programming Embedded Systems, Academic Press,
clearly improved the quality of the course, as no such 1992
[3] Stuart R. Ball: Embedded Microprocessor Systems – Real world designs,
questions popped up in the second winter term and as they Newnes, 1996
were appreciated by colleagues. Future improvements will [4] Stuart R. Ball: Debugging Embedded Microprocessor Systems, Newnes,
extend this direction and will cover, for example, the 1998
mathematical notions for reliability evaluation. [5] Michael Barr: Programming Embedded Systems, O’Reilly, 1999
[6] Jack G. Ganssle: The Art of Designing Embedded Systems, Newnes,
Furthermore, it was found that good slides offered by 2000
colleagues could be easily integrated into our own set of slides [7] Bruno Bouyssounouse and Joseph Sifakis: Embedded Systems Design:
as the structure of the course was adequate. The ARTIST Roadmap for Research and Development, Springer Lecture
Based on the experiences made so far, it was also decided Notes in Computer Science, Vol. 3436, 2005
[8] Axel Jantsch: Modeling Embedded Systems and SoCs: Concurrency and
to spend additional effort on preparing a set of standard Time in Models of Computation, Morgan Kaufman, 2003
assignments. Another experience concerns the overlap for CS [9] Frank Vahid: Embedded System Design, John Wiley & Sons, 2002
students: hierarchical state diagrams and UML are covered in [10] Wayne Wolf: Computers as Components, Morgan Kaufman Publishers,
software engineering courses. Hence, too much emphasis on 2001
[11] Alberto L. Sangiovanni-Vincentelli and Alessandro Pinto: An Overview
these techniques has to be avoided. of Embedded System Design at Berkeley, ACM Transactions on
The last iteration of the German course was complemented Embedded Computing Systems (to appear), available at http://www-
by a follow-up course on electronic design automation (EDA). cad.eecs. berkeley.edu/~apinto/Data/publications/TECS-Education.pdf
About 40% of the students of the embedded systems courses [12] Peter Marwedel: Embedded System Design, Kluwer Academic
Publishers, 2003 and Springer, 2005
enrolled for the EDA course. The EDA course included a [13] Peter Marwedel: Home page for the embedded system design book,
more detailed coverage of SystemC, FPGA programming and http://ls12-www.cs.uni-dortmund.de/~marwedel/kluwer-es-book.html
EDA algorithms (each about 1/3 of the course). The section [14] Samar Abdi, Junyu Peng, Haobo Yu, Dongwan Shin, Andreas
on FPGA programming brought the students in contact with Gerstlauer, Rainer Doemer, Daniel Gajski: System-on-Chip
Environment, SCE Version 2.2.0 Beta Tutorial, CECS Technical Report
hardware circuits (in addition to the ones that are used in the # 03-41, http://www.cecs.uci.edu/~cad/sce.html
LEGO® mindstorms). This course included about 60 hours (at [15] John A. Hennessy and David A. Patterson: Computer Organization –
45 minutes) of lectures and 30 hours of labs. During the The hardware/software interface, Morgan Kaufman Publishers, 1995
course, it was realized that the ES course had laid excellent
foundations for this more advanced course. A number of
topics could be discussed at a more detailed level, since the
fundamentals were already known. The deductive approach
turned out to work well in practice. Based on this experience,
it was decided to offer this sequence of courses on a regular
basis.
More advanced topics are typically also covered in
seminars (presentations by students). Each student has to
attend a course exclusively based on such presentations. For
example, we have offered such “seminar” courses on security
in embedded systems, and on reliability modelling in
embedded systems. Again, the broad knowledge provided in
the described embedded system course laid excellent
foundations for the presentations.

24
 Experience with an Embedded Systems
Software Course
Jogesh K. Muppala, Senior Member, IEEE

 The paper is organized as follows. Section 2 reviews some

Abstract—In this paper we share our experience with of the background for the course. Section 3 provides the
designing and offering a senior undergraduate course on details of the course. Section 4 reflects on the students’
Embedded Systems Software in the Department of Computer opinions. Finally we give conclusions in Section 5.
Science at the Hong Kong University of Science and Technology.
We give a detailed overview of the course, some reflections on
our experience with the first offering of the course, followed by
some discussion on the students’ views of the course. II. BACKGROUND
Most early embedded systems were implemented using
custom-built hardware and software. However, with the
I. INTRODUCTION growing complexity of embedded systems, system designers

E MBEDDED systems have been experiencing tremendous

growth and deployment, especially with the availability of
ever-expanding number of intelligent and complex devices
are increasingly resorting to the use of a commercial off the
shelf embedded hardware, coupled with a real-time operating
system (RTOS) kernel to provide a user-friendly API for
with diverse capabilities. The added complexity in turn software design, development and deployment. Thus
emphasizes the need for formal approaches in design and traditional computer science areas such as compilers,
development of these devices. While embedded systems operating systems, software engineering, modeling and
design draws upon knowledge from several traditional areas simulation, and formal languages like UML are being
of study such as system specification, modeling and analysis; increasingly used in the embedded system design and
computer architecture and micro-architecture; as well as deployment process.
compilers and operating systems, it adds its own twists and Many universities are beginning to offer courses on
new constraints on these areas that need to be addressed afresh embedded systems [11]. Most such courses are hardware
[9]. Several universities have started offering courses on oriented, covering topics such as System on Chip (SoC)
embedded system design. See for example the list maintained design, FPGA, and VLSI aspects of hardware design.
by Vahid [11]. While most of the courses concentrate on the Similarly most textbooks devoted to Embedded Systems tend
hardware aspects of embedded systems, there is still paucity to concentrated mostly on the hardware aspects of embedded
of courses dedicated especially to software aspects of systems. The increasing software component of embedded
embedded systems. systems nowadays has generated interest in formal study of
In this paper, we describe our experience in designing and embedded software. We describe our experience in designing
offering a course specifically concentrating on the software and offering one such course specifically designed to address
requirements and design for embedded systems. We describe all the aspects of embedded software.
the details of the course including the list of topics, the hands- Some universities typically offer courses on real-time
on laboratory exercises and some reflections on the experience systems where some of the topics that we include in our
with the first offering of the course. We also give a brief course are covered. Typically topics in real-time OS like
account of the students’ perception and opinions on the scheduling are covered in such courses. Similarly many
course. A related course on Embedded System Design is universities have courses on software engineering, but not
offered in the Department of Electrical Engineering. This necessarily with emphasis on embedded systems.
latter course concentrated more on the hardware aspects of Many of the advanced topics are usually offered in graduate
embedded systems including interfacing, system on a chip courses. However, these focus on current research topics in
design and field programmable gate array approach to the area and tend to be more theoretical in nature. On the other
implementing custom embedded systems. hand, our course is targeted at undergraduate students. Hence
the emphasis is more on practical topics.

Jogesh K. Muppala is with the Dept. of Computer Science, The Hong

Kong University of Science and Technology, Clearwater Bay, Kowloon, III. THE COURSE
Hong Kong, (e-mail: [email protected]). In this section we give the details of our course, including
.

25
the course structure and list of course topics, the hands-on training is essential to impart them some useful real-world
laboratory exercises, and textbooks. We also reflect on our skills and aid in retaining their interest in the course.
experience with the first offering of the course.
Table I: List of Course Topics
A. Course Topics and Structure
1. Introduction
The course was designed with particular emphasis on the
software aspects of embedded systems. The list of topics x Introduction to Embedded Systems
covered in the course is given in Table 1. The students were x Examples of Embedded Systems
first given a comprehensive overview of embedded systems, x Embedded System Characteristics
their characteristics and design constraints. Three major areas 2. Embedded Systems Architecture
that were emphasized in the course were: (i) embedded
x Hardware Fundamentals: Processors, Memory, Bus, etc.
software development, (ii) real-time and embedded operating
systems (RTOS), and (iii) embedded software engineering. x Software: OS, Application Software
In embedded software development, the students were 3. Embedded Software Development
introduced to the ideas of cross-platform development x Hosts and Targets
including host based embedded software development and
4. Interrupts
embedded target environments, integrated development
environments, interrupts and interrupt handling, and x Introduction to Interrupts
embedded software architectures. x Interrupt Handlers and Interrupt Service Routines
Real-time OS concentrated on reviewing the basics of 5. Embedded Software Architectures
operating systems, and also introducing the specific 6. Real-Time Operating Systems (RTOS)
constraints imposed by real-time requirements. Task
x Review of Operating Systems Basics
scheduling topics including rate monotonic scheduling, the
priority inversion problem and its solution were covered. Task o Tasks, Processes and Threads
synchronization issues including the use of semaphores and o Task Scheduling: Rate Monotonic Scheduling,
events were covered. Inter-task communication mechanisms Priority Inversion
including message queues, mailboxes and pipes were covered. o Task Synchronization and Coordination
Memory management issues including dynamic memory o Intertask Communication
management, memory leak and dangling pointer problems o Memory Management
were covered. Several example RTOS were also introduced in
x Example RTOS:PC/OS-II, Windows CE, VxWorks,
the course. As a simple and efficient real-time kernel, the
Embedded Linux, Java 2 Micro Edition, Symbian OS,
Pc/OS-II was first introduced. Three full-fledged real-time OS Palm OS
viz., Windows CE, Embedded Linux and VxWorks were
7. Embedded Software Engineering
introduced. Three other OS, specifically targeted at the mobile
environment, including Java 2 Micro Edition (J2ME), x Basics of Software Engineering
Symbian OS and Palm OS were covered. Although J2ME is x Software Engineering Models
not a true OS, but rather a portable virtual machine, it was x Unified Modeling Language (UML)
given specific coverage because of its widespread usage. x Software Testing
Embedded software engineering was the most diffuse area
8. Testing and Debugging Embedded Systems
to cover. We leveraged on the existing techniques from
software engineering and briefly covered several topics
including embedded software development, software B. Textbooks and References
development lifecycle, software development models,
Embedded systems software development, as a field, is
including the waterfall model, the spiral model, rapid
fairly recent with not a significant amount of formal
application development model, object-oriented approaches.
techniques and approaches described in the literature. Hence
Sufficient coverage was also given to software testing.
we found that there is paucity of suitable books covering the
Universal modelling language (UML) was introduced as an
complete set of topics that were chosen to be covered in our
important formal method for software engineering, and its use
course. Thus we had to resort to using several different
in the different parts of the software development lifecycle
sources for gathering the material to be covered in the course.
was illustrated. We also concentrated on specific techniques
Most formal textbooks available in the market are oriented
for testing, verification and validation for embedded systems.
towards the hardware aspects of embedded systems. See for
Designing an undergraduate course on embedded systems
example [12]. This book does give some software aspects, but
software poses several interesting challenges. The course must
mostly from the hardware perspective. Wolf [6] is another
be designed with a suitable balance of both theoretical and
book that gives a more balanced hardware/software view, but
practical issues. The theoretical coverage gives the necessary
still hardware oriented.
foundation for the students in the area, while the practical
Simon [1] was one of the first books to concentrate more on

26
software aspects of embedded systems. It introduces the field development and also prepare them for designing and
with a running example, and some concepts are well implementing the course projects.
explained. Kamal [2] is a recent book in this area which tries
D. Course Projects
to give a balanced overview of both hardware and software.
Lewis [7] also concentrates more on the software aspects, The course project was an important part of the student
especially for a beginner in the area with limited programming assessment, in addition to quizzes and examinations. Students
experience. The treatment of the language aspects and formed teams of up to 3 students per team and proposed their
memory management are very good. own project based on their interest. The students had about 2
Two books that introduce the area with several interesting months to develop their idea, propose the project, design and
working projects in different areas of embedded software implement it. Students were encouraged to apply the software
development are [3][5]. These books are very useful for a engineering principles learnt in the course during the design
practical approach to embedded software development, but and implementation of the project, starting from requirements
need to be supplemented on the theoretical aspects by material analysis to final implementation and testing.
from other sources. The students were very enthusiastic and proposed and
Books on real-time systems [13][14][15][16][17] are good implemented interesting projects. The project topics ranged
sources for information especially related to the real-time from a Bluetooth based positioning system implemented on
aspects including RTOS, scheduling etc. However they often Pocket PCs, a multi-player paper, rock and scissors game
do not present the topics from an embedded systems implemented using J2ME, an Internet based chat client
perspective. One book that gives a good overview of both the implemented using J2ME, and a multimedia center
areas is [4], but it is not available in the international market. implemented using J2ME. One group enhanced PC/OS-II by
This book is designed more as a primer for those who already implementing support for addressing the priority inversion
are into software development. Another good book that problem. They implemented support for the priority
presents the real-time concepts with embedded systems in inheritance protocol.
mind is [16]. E. Reflections on the Course
In our course, we used [1][2]as the primary textbooks, and
The first offering of our course provide a rich source of
supplemented with material drawn from [3][4][5][6][7]. Also,
interesting experiences to reflect upon and make choices and
materials about specific real-time OS were drawn from
adjustments for the future offerings of the course. We will
various websites dedicated to the specific RTOS. Details and
first reflect on the three major areas that we covered in the
links can be found on the course website [8].
course and some observations from our experience in teaching
C. Hands-on Laboratory Exercises them. Embedded software development was one of the most
The hands-on laboratory component concentrated mainly unique aspects of this course that distinguishes it from other
on the use of several real-time OS and integrated development courses. This topic while quite practical has some interesting
environments. We did not have a dedicated embedded systems theoretical aspects to be covered. Emphasis was put on
laboratory set up by the time the course was offered. So a explaining cross-platform development including issues
general purpose teaching laboratory equipped with standard related to cross-compilation, host-based development and
PCs was used for the laboratory exercises. We are currently in target deployment.
the process of setting up a dedicated embedded systems The RTOS section shared some overlap with a standard
laboratory where suitable embedded development kits and operating systems course. We leveraged on the fact that all the
access to various RTOS and integrated development students have already had taken an specific course dedicated
environments would be available. to operating systems earlier, and minimized the overlap by
The majority of the labs were organized around the only providing a quick overview of the typical OS related
Microsoft Windows Embedded software including Platform material. Greater emphasis was put on real-time scheduling
Builder 4.2 and Windows CE. Students were introduced to the and memory management issues from an embedded systems
Platform Builder IDE, Visual Studio environment including perspective.
the Embedded Visual C++ and “.NET” compact framework. As already mentioned, Embedded Software Engineering
Then the students did several laboratory exercises which were posed the greatest challenge for teaching in this course.
aimed at illustrating several RTOS concepts including threads, Software engineering is more geared towards large scale
task scheduling, task synchronization, and memory software projects. There is lack of suitable case studies
management, including memory leaks. illustrating the use of software engineering techniques in
Students were also exposed to the PC/OS-II kernel, and the embedded software development. The relatively recent
Symbian OS and Nokia Series 60 platform. The Java 2 Micro adoption of these techniques in the embedded software
Edition (J2ME) platform was also introduced through Sun engineering field is partly the cause of this scarcity.
Java Wireless Tookit and NetBeans IDE 4.0. Furthermore, the adoption of formal techniques like UML is
The laboratory exercises were mainly aimed at exposing fairly new in this area. The UML framework is too general to
students to different environments for embedded software be adopted directly for embedded software. There has been

27
several recent efforts to introduce the concepts of real-time IV. STUDENTS
and timeliness into UML. But most of these are in the research As already mentioned the course was designed as a senior
stage. There is lack of suitable case studies or meaningful undergraduate course. In the first offering of the course, most
examples to illustrate the use of UML in embedded software of the students were in their second year or third year (final
development. We scoured the literature to find some simple year) of their undergraduate education at the university. It
examples, but this area needs to be explored further. must be noted that the Hong Kong higher education system is
Several interesting issues arose before, while and after based on a three year bachelor’s degree program. Students
offering the course. Some of these issues arose from our own entering the university are at the sophomore level of a typical
reflections, while others were in response to opinions US university. Thus students in the second and third year at
expressed by our colleagues. Here we discuss some of these the university here are equivalent to students in their junior
issues. The embedded community can perhaps address some and senior year of a 4-year bachelor’s degree at a typical US
of these issues. university.
One major issue was whether the embedded software
techniques covered in this course merits a separate course, A. Background
rather than being covered as part of existing courses on Not surprisingly, most of the students taking the course
specific topics. For example, many of the RTOS concepts can (almost 99%) were doing their bachelor’s degree in computer
easily be covered in a course on operating systems. Similarly, engineering. There were just a couple of students doing their
cross-compilation and cross-platform development can be bachelor’s in computer science, although the course was
covered in a compiler course. Similarly, embedded software designed to attract students with both computer science and
engineering techniques can easily be covered in a software computer engineering background. Students in their final year
engineering course. While it is certainly useful to include of study made up approximately 60% while students in their
discussion on embedded systems related issues in the specific second year made up the remaining 40% of the enrollment in
courses, a detailed coverage may not be feasible. In our the course.
opinion, it is appropriate to have an integrated course where Two undergraduate courses were listed as prerequisites for
all the related topics are covered. Care must be taken to avoid our course, viz., Computer Architecture, and Principles of
significant overlap with the other courses. Where feasible, Systems Software (Operating Systems). Most students
some of the related courses can be included as pre-requisites enrolled in the bachelor’s programs in computer science or
so that students already have sufficient background in specific computer engineering at our university typically take these
topics. two courses by the time they have completed the first semester
Another major issue that we grappled with in designing this of the second year of their study. Since these two courses
course is how to balance the course content between provide the necessary background required for introducing
theoretical aspects and practical skills. Our approach was to embedded systems, we had to devote only a short time at the
give sufficient emphasis on practical skills through hands-on beginning of our course to review the relevant materials
laboratory exercises, while ensuring that the related theoretical before delving into the topics of our course.
areas are also emphasized. Wherever feasible, the theoretical
B. Student Feedback
concepts were reinforced with related laboratory exercises.
This area being relatively new is still deficient in generic Overall the course was well received by the students. At the
techniques that can be covered. So a greater emphasis on end of the semester, a comprehensive survey of the students’
specific platforms and solutions may be needed in the interim. opinions was carried out in order to assess how well the
This brings us to another related issue, i.e., whether the course met the students’ expectations. The results of the
course is best taught using a single platform (e.g., Windows survey indicated that the students were quite satisfied with the
CE, VxWorks, Embedded Linux), or whether more course. Some suggestions for improvement were given which
concentration should be given to the generic concepts and are noted below:
approaches. We adopted the latter approach, while still 1. Most students expressed interest in having more hands-on
ensuring adequate coverage of specific platforms. labs that currently available. They especially wanted to
have experience with dedicated hardware and embedded
Another issue is how to balance the coverage between
development platforms, rather than the general purpose
hardware and software. In particular, how much of the low-
PC. This will be addressed in the future offerings of the
level techniques should be covered in the course. We opted to course because we are setting up a dedicated Embedded
limit our hardware coverage to generic techniques and Systems laboratory equipped with suitable hardware and
hardware platforms and not get into very specific hardware. A software, including embedded development platforms.
discussion on interfacing followed by detailed discussion on 2. The topics that attracted the most interest among the
device driver design and implementation would be beneficial. students were embedded development, and RTOS. The
In this area, complete isolation of the students from the least popular topic was software engineering, perhaps
underlying hardware is neither feasible nor desirable. because of lack of demonstrative case studies.
3. Most students expressed that the coverage of the RTOS
should be limited to an in-depth coverage of only two or

28
 three major ones, rather than an overview of several ACKNOWLEDGMENT
RTOS. Their preference was to concentrate on Windows The author wishes to thank the Dept. of Computer Science
CE, Embedded Linux and VxWorks. at HKUST and especially the Dept. Head for encouraging the
4. Students also wanted more coverage on interfacing,
development of this course. We also thank Microsoft for
especially with emphasis on device-driver development.
supporting the course under the Windows Embedded
Future offerings of the course will include more emphasis
Academic Program (WEMAP) by providing us access to
on these topics.
5. Some students expressed the opinion that some of the Windows CE software.
topics had overlap with other related courses that they had
taken, and hence suggested that the overlap should be REFERENCES
minimized. This was especially true for software [1] D. E. Simon, An Embedded Software Primer, Addison-Wesley, 1999.
engineering which is covered in detail in another course [2] R. Kamal, Embedded Systems: Architecture, Programming and Design,
McGraw-Hill, 2003.
dedicated to the topic. [3] K.V.K.K. Prasad, Embedded/Real-Time Systems: Concepts, Design and
6. UML was not well appreciated because of the short time Programming, Dreamtech Press, New Delhi, India, 2003.
devoted to cover it. This is related to our observation [4] S. V. Iyer and P. Gupta, Embedded Realtime Systems Programming,
earlier that lack of suitable case studies hampers the Tata McGraw-Hill, New Delhi, India, 2004.
[5] Dreamtech Software Team, Programming for Embedded Systems:
proper coverage of UML. This issue can be addressed by Cracking the Code, Wiley, 2002.
including meaningful case studies, especially [6] W. Wolf, Computers as Components: Principles of Embedded
demonstrating the application of UML in embedded Computing System Design, Morgan Kaufmann, 2001.
software development. [7] D. W. Lewis, Fundamentals of Embedded Software, Prentice Hall, 2002.
[8] COMP 355: Embedded Systems Software Website:
http://www.cs.ust.hk/~muppala/comp355/.
[9] Design Automation Conference 2000, Embedded Systems Education
V. CONCLUSIONS Panel, 37th Design Automation Conference, Los Angeles, CA, USA,
Jun. 2000.
In this paper we discussed our experience in designing and [10] B. Hemingway, W. Brunette, T. Anderl and G. Borriello, The Flock:
offering a senior undergraduate course on Embedded Systems Mote Sensors Sing in Undergraduate Curriculum, Computer, 37 (8),
Aug. 2004, 72-78.
Software. The course was described in detail and some
[11] F. Vahid, Embedded Courses in Universities,
reflections on our experience in teaching the course are http://www.cs.ucr.edu/~vahid/courses/es_others.html.
included. [12] F. Vahid and T. Givargis, Embedded System Design: A Unified
Our experience offers only one point of reference for Hardware/Software Introduction, John Wiley & Sons, 2002.
[13] H. Kopetz, Real-time Systems, Kluwer, 1997.
academics interested in designing and offering similar [14] C. M. Krishna and K. G. Shin, Real-time Systems, Mc-Graw Hill, 1997.
courses. It is our hope that this experience sharing can [15] J. Liu, Real-time Systems, Prentice Hall, 1st ed., 2000.
contribute towards further sharing of views and experience [16] Q. Li and C.Yao, Real-Time Concepts for Embedded Systems, CMP
Books, 2003.
from academics worldwide. In the longer term, a broader [17] G. Buttazzo, Hard Real-Time Computing Systems: Predictable
consensus on the teaching of Embedded Systems in the Scheduling Algorithms and Applications, Second Edition, Springer,
academia can thus be attained. 2004.

29
 How should embedded systems be taught?
Experiences and snapshots from Swedish higher
engineering education
Martin Grimheden and Martin Törngren

 within departments of computer science, from departments of

Abstract— This paper presents results from a previously electrical engineering or from departments of automatic
published analysis performed on the subject of embedded control, which in several cases gives a slight difference
systems using a didactical approach together with some between the local definitions of the subject. As a consequence,
educational implications. To illustrate the didactical analysis,
examples from embedded systems education at KTH in Sweden
some universities treat and teach embedded systems as a
are given where an exemplifying selection and an interactive specialization of computer science, and some departments use
communication have been adopted in embedded systems related the subject of embedded systems to promote education and
courses. research in automatic control.
The exemplifying selection means that education in embedded In the examples presented in this paper embedded systems
systems would benefit from teaching ‘everything of something’ is described and analyzed according to the way embedded
rather than ‘something of everything’, that is, depth rather than
systems originally was implemented at the department of
width. The interactive communication strongly motivates
experimental work, hands-on approaches and problem based machine design, mechatronics lab, at the Royal Institute of
learning in general. Technology (KTH) in Stockholm, Sweden. In this case,
embedded systems evolved from within the school of
Index Terms—Embedded systems education, didactical mechanical engineering, specifically the department of
analysis, engineering education. machine elements where the microcontroller was introduced
as ‘a machine element’ similar to gears, bearings etc, but with
a programmable functionality. Today, 30 years later,
I. INTRODUCTION embedded systems at KTH is treated as a subject within

E VEN though embedded systems have been designed for

more than 30 years, the academic subject of embedded
systems is a new, relatively undefined subject, mostly
machine design, with a heavy focus on product development,
development of intelligent products.
B. From Education through Research to Industry
regarded as an interdisciplinary field combining areas such as
computer science, automatic control and electrical The purpose of teaching embedded systems at most
engineering. The scope of the subject is continuously universities is to provide the industry with competent staff.
discussed, with its implications on research and education. The purpose of performing research is to educate doctors in
The aim of this paper is to present results from an analysis embedded systems, for the same purpose, as well as to create
performed on the subject of embedded systems using a new knowledge in the area of embedded systems, for the
didactical approach [9]. The purpose of this analysis is to help industry as well as the common good of the society.
the establishment of the identity of the subject and to provide Within the ARTIST and ARTIST2 projects, work has been
further arguments for why the subject ought to be taught in a in progress for quite some time to identify and specify a
certain way. curriculum for education in embedded systems [1, 2]. In the
guidelines published by the ARTIST teams the technical
A. Context competencies required by an embedded software engineer are
The subject of embedded systems is mostly regarded well specified, and the need for practice is recognized as 'an
differently among different academic institutions. An example essential component for a well-rounded education in
of this is given if comparing the origin of the subject among embedded systems'. Practice, however, is defined as
different universities; in some cases the subject evolved from 'experimental laboratory work' and illustrated by the use of
tools such as Matlab/Simulink, running code on real hardware
Manuscript received July 16, 2005. platforms etc. The guidelines do not mention any
Both authors are with the Royal Institute of Technology, School of complementary skills such as teamwork, communication,
Industrial Engineering and Management, Mechatronics Lab, SE-100 44 business, etc.
Stockholm, Sweden (phone: +46-7-790-7797; fax: +46-8-20-22-87; e-mail:
[email protected]).
It is therefore of fundamental interest that the education
provided by the universities is deemed relevant and useful by

30
the hiring industry, as well as by the industries of the future. and with real-world engineering constraints that are seldom
One main question then becomes how the universities can touched upon in the academic teaching [12].
understand the needs and requirements of the current hiring
industry, how to balance between fundamental knowledge and II. A DIDACTICAL PERSPECTIVE ON EMBEDDED SYSTEMS
skills and short-term hot trends as well as predict the evolution EDUCATION
of the subject and prepare students for life long learning. Didactics is a field of educational studies mostly referring
C. Closing the loop: From Industrial experiences to to research aimed at investigating what's unique with a
Education particular subject, and how the particular subject ought to be
taught. In this paper we present results from previous attempts
By tradition the academic practice is characterized by a
of performing a didactical approach to the subject of
narrow viewpoint and a systematic approach, while the
embedded systems [5, 9]. The didactical analysis is used to
industrial practice is characterized by the need for a holistic
identify and describe the identity and legitimacy of the subject
viewpoint and a, more or less, ad-hoc approach, as in Figure
(what is the subject of embedded systems and why should
1. The white arrows show the necessary path to fulfill a better
embedded systems be taught?) [4]. We also use this analysis
balance in selection and communication (form and content).
to provide insight into the questions of selection and
Industries are constantly struggling to move from an ad-hoc
communication (which material should be taught and how?).
approach towards a more systematic approach, and in the
universities there are certainly many initiatives in the direction A. The identity of embedded systems
of reaching a more holistic viewpoint. According to the didactical analysis the identity of a subject
could be described in relation to two extremes; as being either
Viewpoint Holistic disciplinary or thematic, or somewhere in between. Most
Industrial traditional subjects, with established structures and related
practice organizations, are considered as disciplinary subjects. A
closure has then been reached as to the contents and internal
relations of the subjects and its domains. With subjects such
as embedded systems this closure has not yet been reached.
Every university and department considers and teaches the
Approach
subject differently, and on most conferences the scope and
content of the subject is discussed in depth, as is its preferred
Ad-hoc Systematic
curriculum for example.
Instead of an established disciplinary identity, themes are
used to describe embedded systems, and the themes vary
Academic amongst different universities. According to IEEE an
practice embedded system is 'part of a large system and performs some
of the requirements of that system; for example, a computer
Narrow system used in an aircraft or rapid transit system' [10]. From
this definition it follows that computer based systems
Fig. 1. Traditional differences in practice between industry and academy. The
white arrows represent a desirable move to meet discrepancies in legitimacy of embedded into products like for example TVs, telephones,
the education. toys and vehicles qualify as embedded systems, and that the
characteristics of these products include their interactions with
One way to reach a more holistic viewpoint is to focus the environment. Examples of relevant aspects are
more on the communication, the form, and, for example, to dependability, performance and cost which implies key areas
teach in a more project organized and problem oriented way - such as safety critical systems, real time systems etc. Such
both to increase student motivation and also to move towards aspects, areas and applications can therefore be used to
a more functional approach and thereby hopefully reaching a describe the subject of embedded systems, as themes of the
higher level of understanding. A further motivational factor subject.
for the move towards these educational methods is that the However, even if most universities happily agree upon a
project- and problem based educational methods can be seen number of themes, applications and products, discrepancies
as preparations for a future professional role as an embedded between how to approach these themes arises. Some
systems engineer, which require skills such as teamwork, universities focus on control aspects of embedded systems,
communication etc. some on developing methods within computer science to
Another example from teaching indicates synergetic effects reach certain goals while some focus on more general product
when giving courses with participants both from industry and development of embedded systems.
university. Industrial participants can contribute along the
lines of Figure 1, with experiences that place theoretical B. The legitimacy of embedded systems
pieces in a context, by reflections relating to tacit knowledge The legitimacy of a subject is defined as the relation

31
between the educational effort performed by the university,
resulting in educated embedded systems engineers, and the
demands put by the hiring industries on the graduated Functional
engineers. According to the didactical approach this
legitimacy could be illustrated according to two extremes; as a
formal legitimacy or a functional legitimacy. A formal
Identity
legitimacy is defined as when the demands put by the
surrounding actors on the university are expressed in terms of
number of credits in specific subjects, which subjects the
Disciplinary Thematic
degree requires etc. In a functional legitimacy instead the
actors requires skills and abilities, and expresses these in
terms such as capabilities to design controllers etc.
In the case of embedded systems the legitimacy is classified
Legitimacy Formal
as functional [9]. In Sweden, the hiring industry is primarily
interested in functional skills, engineers capable of designing
and implementing embedded systems. A study of 21
embedded systems companies in Sweden further motivates
this; the companies studied put formal knowledge and Interactive
traditional courses aside and instead ask for functional skills
and complimentary skills such as teamwork abilities and
presentation techniques [11].
Selection
C. The selection and communication of embedded systems
The results from the analysis, the thematic identity and the
functional legitimacy, affects the final two dimensions or Representation Exemplification
questions; the questions of selection and communication.
These two questions deal with the what and how; what should
be taught, and how.
A representative selection means that ‘something of Active
everything’ is taught. This is often the case in, for example, Communication
first year courses in mathematics. The opposite is defined as Fig. 2. Illustration of the didactical analysis applied to the subject of
an exemplifying selection where ‘everything of something’ is embedded systems.
taught. This is often the case in problem based learning or in
In Figure 2 the subject of embedded systems is mapped
postgraduate education where the focus is on a narrow field
according to its identity, legitimacy, selection and
instead of an overview. One example of teaching with a
communication. The exemplifying selection and interactive
representative selection could be a course in, for example,
communication is a direct consequence of the identity and
microcontroller technology that focuses on giving general
legitimacy, which also is emphasized in the Swedish study
knowledge on the varieties of the existing microcontrollers,
performed on 21 Swedish embedded systems companies [11].
the differences between these, and more theoretical
In brief, the exemplifying selection is a consequence of the
knowledge about microcontroller principles. If instead
functional legitimacy; the companies want engineers with in-
choosing an exemplifying selection, the course should focus
depth knowledge and functional skills rather than formal
on complete understanding of one single microcontroller. All
knowledge. The interactive communication also facilitates
effort should then be spent on learning this microcontroller,
functional skills rather than formal knowledge since such a
and to become an expert of understanding, programming and
teaching approach focuses more on hands-on approaches and
using this microcontroller. The basic idea with an
provides complimentary skills such as teamwork abilities and
exemplifying selection is that the knowledge and skills
presentation techniques.
learned from this selection could be generalized and applied to
similar problems and areas.
III. EXAMPLES FROM TEACHING EMBEDDED SYSTEMS WITH AN
The final dimension, the question of communication, deals
EXEMPLIFYING SELECTION AND AN INTERACTIVE
with the preferred method of communicating the subject. In an COMMUNICATION
active communication both parties are active; teacher and
student, but in an interactive communication the action by the The aim of this section is to provide examples and
teacher is dependant on the current status and knowledge level experiences from teaching embedded systems at KTH with an
of the individual student or student team. exemplifying selection and an interactive communication. It is
important to note though that the examples provided here
should be considered in their respective context, as described

32
earlier in this paper. All courses below attract mainly students considered the capstone course most important and
mechanical, vehicle and management engineering students useful [5].
specializing in mechatronics or embedded systems.
B. The lab in your pocket
A. Teaching embedded systems according to the CDIO ‘The lab in your pocket’ project was created to implement
initiative both an exemplifying selection and an interactive
The CDIO initiative was established in unison between communication in a course in microcontroller technology. The
KTH, MIT and a number of other Swedish universities to basic ideas of ‘the lab in your pocket’ concept are the
move engineering education further from a formal legitimacy following:
towards a functional. The purpose of the CDIO initiative was
to create a curriculum that trained students to Conceive, 1. Each student has constant access to his/her own set
Design, Implement and Operate (C-D-I-O) a system; in this of laboratory equipment.
case an embedded system [3]. 2. The laboratory equipment can be used at any
location, at any time. The only requirement is
Course Perspectives D&P A D&P B D&P C Intermediate access to an ordinary PC.
Skill on D&P thesis project
3. With the equipment, each student can perform all
Analyze laboratory work within the course.
technical
solutions 4. The equipment promotes open-ended solutions,
Team work meaning that all experiments are flexible enough
to encourage creative solutions.
Written
presentations X X X 5. The total cost of all sets of equipment does not
Oral exceed the cost of the traditional laboratory
presentations X X X facilities.
Sketching

The laboratory equipment consists of one microcontroller,

Etc.
an Infineon C167CS, an I/O-board with a LCD-display,
keyboard, buttons, LEDs, a DC motor etc as well as some
Introduced trained ability requested X occurs unspecified sensors such as accelerometers and temperature sensors. Also,
Fig. 3. An illustration of the CDIO-concept applied to course design at KTH. manuals, C-compilers and examples are provided for all
The illustration shows how complimentary skills are integrated in traditional students.
subject courses, and the three-step model where each subject or skill is
introduced, trained and requested over time.

At KTH the CDIO idea is implemented mainly in a

capstone course in the fourth and final year of the
specialization in embedded systems, a complete problem
based and project organized course. In this course, a team of 6
to 15 students are given a task, typically in terms of an
industrial development project involving concept evaluation
and prototype development, where a corporate sponsor
provides the problem, motivation, relevance and funding to
the project. The student team spends more than 50% of their
time during three quarters of a year in a project that is
organized in four phases (C-D-I-O). Complimentary skills
such as teamwork skills, project management, economy,
language skills etc are interwoven in the project as each
student receives two responsibilities, one related to the
product and one related to the process. Student responsibilities Fig. 4. The Mechatronic Learning Concept, as developed by KTH. Modules
are cycled in each phase, and after the nine months each for the ‘Lab in your pocket’ is chosen from these.
student will have practiced skills in embedded systems
technology as well as team management, teamwork etc. For
more information about the KTH capstone course, see for
example [6].
In an evaluation performed by KTH all graduated
mechatronics/embedded systems students were asked which
course taken at KTH that was most important to them in their
professional career. An absolute majority of the former

33
 C167 C I/O-module
b. The focus group attended fewer lectures
+ Sensors Actuators
Display than the reference group (53% compared to
Keyboard Temperature DC servo 68%)
LED’s Accelerometer AC servo
Buttons Pressure Pneumatics c. The focus group attended more exercises
IR IR
Ultrasonic Ultrasonic
than the reference group (87% compared to
Proximity 80%)
2. Results of the experimental work
a. The focus group received considerably
One from each
higher grades on the projects than the
reference group (grade 4,7 compared to 3,9)
Fig. 5. The modules used in the ‘Lab in your pocket’ b. In the focus group, only 6% compared to
43% in the reference group chose the
projects with the lowest grade. 79% of the
focus group chose the highest grades
compared to 32% in the reference group.
3. Non-quantified measurements2
a. The average student in the focus group spent
considerably more time doing experimental
work than the average reference student.
The reference group often worked against a
deadline, while the focus group worked
more spontaneous and at irregular hours.
b. The faculty spent considerably less time
supervising the focus group compared to the
reference group. The reference group
required constant supervision, while the
focus group communicated via the
educational web based platform, and
Fig. 6. One set of the ‘Lab in your pocket’ collaboratively supported each other.
4. Economical results
In an evaluation of this project we found that the participating
a. The cost of supervision can be reduced since
students received considerably higher grades, that the students the focus group required considerably less
spent considerably more time on experimental work, and that support from the faculty.
the faculty spent considerably less time on supervision, all this
as compared to a traditional experimental course [7]. As a The cost of laboratory facilities can be reduced since the focus
consequence, the total course cost for the university was group did not require any facilities except the portable sets. In
reduced, again as compared to the traditional course. this experiment, the annual cost of keeping the laboratory
C. Results from project ‘Lab in your pocket’ exceeds the initial investment of portable sets.
For an evaluation 30 students constituting a focus group D. Education as preparation for future work on a global
answered a set of questionnaires, and a selection of ten market
students was selected for interviews. In these questionnaires The functional legitimacy gives at hand that the education
and interviews the students were asked to describe their ought to be a preparation for future work, and since most
approaches towards the experimental work; when, where and companies act on a global market there is a need to also
how the exercises and projects were done, the overall attitude encompass these global aspects into the education. In one
towards the concept, how much time spent experimenting etc. example at KTH, this is done within a capstone course that is
Another comparison was made between the focus group and expanded to cover international aspects [8]. Several modes of
the reference group regarding the grades of the projects, the international collaboration has been experimented with, either
delivery time of the project results, and the overall view of the collaboration with a foreign corporate sponsor or
course. These results can be summarized into the following: collaboration with one or several international student teams.
Among other conclusions, the international collaboration in
1. Overall course attitudes the studied capstone courses promoted [6]:
a. The focus group appreciated the exercises,
the project and the teachers considerably
more than the reference group (grade 4,41 1. Improved disciplinary learning and other skills.
compared to grade 3,8)
The international collaboration creates access to

1 2
The grades vary from 1 (really bad) to 5 (excellent) This data is based on the students’ own estimates, gathered in interviews.

34
 more resources and gives new and different from the International Conference on Mechatronics ICOM 2003, 18-20
June, Loughborough, UK, 2003.
perspectives to problems. The collaboration also [8] M. Grimheden and H. Strömdahl, “The Challenge of Distance:
promotes general skills such as teamwork, team Opportunity Learning in Transnational Collaborative Educational
management and presentation techniques. Settings”, International Journal of Engineering Education, 20, 4, 619-27,
2. Awareness of cultural differences and different 2004.
[9] M. Grimheden and M. Törngren, “What is Embedded Systems and how
educational systems. The collaboration promotes should it be taught? – Results from a didactical analysis”, To appear in
this awareness, which is an important competence the ACM Transactions on Embedded Computing Systems, 2005.
in a future career in a global company. [10] IEEE. “Glossary of Software Engineering Terminology, IEEE Std
610.12”, IEEE, New York, 1990.
3. Enhanced motivation. The international [11] M. Josefsson (Ed.), ”Industriell Programvaruutveckling”, ITQ Nordic
collaboration itself is seen by several students as Institute, 2003.
an interesting challenge. [12] J. Twiefel, T. Hemsel, C. Kauczor, J. Wallaschek, “Teaching
Mechatronics to a mixed audience from industry and university”, in
Proceedings of the 6th International Workshop on Research and
Education in Mechatronics, 30 June – 1 July, Annecy, France, 2005.
In the above, examples can be found of functional
legitimacy related to both the subject of embedded systems as
well as to general skills related to working in a global
company.

IV. CONCLUSIONS
The purpose of this paper is to argue for a view on
embedded systems education where the results of the
didactical analysis are put into focus. Embedded systems, in
Sweden, is a subject with a thematic identity and a functional
legitimacy, which means that the embedded systems
companies are requesting engineers capable of conceiving,
designing, implementing and operating embedded systems.
The main idea of the didactical approach is not to specify a
certain curriculum or a number of courses, but to start with the
functionality – to agree upon the idea of primarily educating
engineers capable of this rather than engineers with a certain
number of credits in a certain number of courses.
Three examples are given from embedded systems
education at KTH in Sweden, where the ambition has been to
build on the foundation of this thematic identity and
functional legitimacy, to create courses with a exemplifying
selection and an interactive communication, meaning that the
students should learn ‘everything of something’, with an
experimental approach, or in a problem-oriented and project-
organized setting.

REFERENCES
[1] ARTIST, “Guidelines for a Graduate Curriculum on Embedded Software
and Systems”, http://www.artist-embedded.org/Education/Education.pdf
(accessed Aug. 2004).
[2] ARTIST2, http://www.artist-embedded.org/FP6/Overview/ (accessed
Feb. 2005).
[3] E. D. Crawley, “Creating the CDIO Syllabus, a universal template for
engineering education”, in Proceedings from the 32nd ASEE/IEEE
Frontiers in Education Conference, November 6-9, Boston, MA, 2002.
[4] L.-O. Dahlgren, Undervisningen och det meningsfulla lärandet,
Linköping University, 1990.
[5] M. Grimheden and M. Hanson, “What is Mechatronics? Proposing a
Didactical Approach to Mechatronics”, in Proceedings of the 1st Baltic
Sea Workshop on Education in Mechatronics, Kiel, Germany, 2001.
[6] M. Grimheden and M. Hanson, “Collaborative Learning in Mechatronics
with Globally Distributed Teams”, International Journal of Engineering
Education, 19, 4, 569-74, 2003.
[7] M. Grimheden and M. Hanson, “The Lab in Your Pocket – A modular
approach to experimental learning in Mechatronics”, in Proceedings

35
A Case Study in Efficient Microcontroller Education
Bettina Weiss, Günther Gridling, Markus Proske
Vienna University of Technology,
Embedded Computing Systems Group E182-2,
Treitlstr. 3/2, 1040 Vienna, Austria
Email: bw,gg,proske @ecs.tuwien.ac.at
✁

Abstract— Undergraduate education typically is characterized with microcontrollers, with hardware, and with Assembler
by a large number of students. Therefore, courses must be programming.
conducted efficiently and should not only focus on conveying the When setting up this course, we faced the challenge of many
course material, but must also be oriented towards a maximum
transfer of knowledge with a minimum amount of invested time (about 150) students in an 8 workstation lab. We also wanted to
on the instructor’s part. At the same time, courses should be make the course more accessible to employed and handicapped
flexible to accommodate different student needs. students, potentially scalable to a large number of students, and
In this paper1 , we identify the needs of a practical course in suitable for distance learning, which further added to the chal-
microcontroller programming with respect to course structure lenge. This made it very demanding to balance the needs of the
and grading, present our solutions, and discuss our experiences.
students, the demands of the curriculum, and the constraints
Index Terms—embedded systems education, automatic grading, of available resources. We are teaching the microcontroller
distance learning, pedagogy course since 2003 and in each year experimented with different
mechanisms to attain our goals. This year’s course had good
I. I NTRODUCTION student feedback and was conducted very efficiently from our
Embedded systems education is a vital part of the computer point of view. So we can conclude that it is possible to find
engineering curriculum and has gained increasing importance a satisfactory solution to this optimization problem, and we
in the last decade [1], [2]. However, it also suffers from believe that our experiences, both positive and negative, gained
problems that are specific to any hands-on course using from setting up this course can be of value to other instructors.
hardware: To teach the practical skills involved, students must In the following sections, we will first identify the require-
be assigned an appropriate workload, but lab resources are ments on practical courses in Section II. In Section III we will
limited. Add to that the increasing demand for embedded sys- present the course structure of the Microcontroller course and
tems engineers, which entails an increase in student numbers, explain why we structured the course in this way. Section IV
and embedded systems education soon reaches its limits with is dedicated to our grading scheme, which is essential to
respect to both lab resources and available personnel. It thus achieving our goals. In Section V, we give a discussion of our
makes sense to invest a significant amount of time into the current course, its advantages and disadvantages, and student
setup of a course, if the course can then be managed with less feedback. Section VI concludes the paper.
strain on the university’s resources.
The recently introduced bachelor study “Computer Engi- II. C OURSE G OALS
neering” at the Vienna University of Technology contains When reviewing our expectations for the course, we identi-
several courses which focus on programming embedded sys- fied three different and possibly conflicting areas of concern:
tems, among them the introductory course Microcontroller
[3]. The Microcontroller course gives second-year computer Financial Impact:
engineering students their first experiences with microcon- The course should be conducted efficiently, with a
trollers and hardware-near programming. We expect students minimum amount of time and resource efforts. It
to be proficient in C programming and to have basic computer should be scalable to a large number of students
architecture and electrical engineering knowledge. The course and should be suitable for distance learning. Since
is intentionally kept low-level, much like [4], and teaches stu- the time of a professor is most expensive, whereas
dents both the basics of microcontroller programming (without tutors are comparatively cheap, the bulk of student
debugging tools) in Assembler and C and how to control supervision should fall to tutors.
external hardware. For most students, it is their first contact Educational Impact:
The course should be successful, that is, it should
1 This work is part of the SCDL “Seamless Campus: Distance Labs” project, have high student retention, a high passing rate, and
which received support from the Austrian “FIT-IT Embedded Systems” convey both microcontroller programming skills and
initiative, funded by the Austrian Ministry for Traffic, Innovation and Tech- understanding of the issues involved.
nology (BMVIT) and managed by the Austrian Research Promotion Agency
(FFG) under grant 808210. See http://www.ecs.tuwien.ac.at/Projects/SCDL/ Motivational Impact:
for further information. The course should motivate students and should re-

36
 sult in high student satisfaction. Students should get III. M ICROCONTROLLER C OURSE
interested enough to start their own private projects. This year’s course got very good student ratings. The struc-
Naturally, these goals require different techniques, which in ture we describe here already incorporates our experiences
turn may have a positive or negative influence on the other gained this year and will be first employed in the summer
objectives. For example, in our first try, we allowed students term of 2006. Since the changes intended for 2006 are minor
free access to the labs, gave them an exercise set that was and to a large extent supported by student and tutor feedback,
completely voluntary, told them that we were available for we expect the course to have a similar (if not better) impact
questions by email or newsgroup at any time, and conducted on students as this year’s course.
one programming exam at the end of the term. So basically,
we told them to exercise as much as they thought they needed A. Educational Material
and then come to the exam. This scored well on the financial Since students should be able to work at home, we needed to
axis, moderately well on the motivational axis, and pretty low get the lab to the students. Although it would have been more
on the educational axis, since most students put off doing the cost effective to use simulators like in [5], simulators cannot
exercises until it was too late and then dropped the course. capture all the problems that arise when using real hardware
Even those that passed lacked some basic knowledge. This [6]. Furthermore, working with real hardware instills into
taught us that for each of our objectives, we must identify the students the confidence that they know how to handle hard-
techniques most beneficial to it, but at the same time must ware, and often encourages them to start their own projects.
also account for their effects on the other areas. As a result, Therefore, we decided to use real hardware in the course,
we went through the different pedagogical measures available which had to be cheap to be suitable for “mass” production.
to us and estimated their impact, see Table I. In the table, a Unfortunately, we did not find any suitable existing hardware
represents a positive impact, a negative one, and values in ✁

and hence proceeded to develop our own lab hardware.

brackets are setup costs that only occur once. The total column One important lesson we learned about student hardware is
states the overall impact. that it is vital to let students connect the hardware themselves.
Due to limited space, we cannot discuss our reasoning In our first course, we used a commercial HCS12 evaluation
behind the values, but bear in mind that the table represents board with fixed connections, and we ended up with a lot of
our personal assessment and values, so other instructors may students who simply did not understand how a LED and a
come to slightly different evaluations. microcontroller pin go together. They had just learned that
“writing 0x0F to port X turns on LED0-3”. So our own
TABLE I
hardware has no fixed connections, students must do all the
D IFFERENT TEACHING TECHNIQUES AND THEIR IMPACT IN DIFFERENT
wiring.
AREAS
Fin. Edu. Mot. Total
autogradable exams ✂ ✂ ✂ ☎ ☎ 1
essay exams ☎ ☎ ☎ ✂ ✂ ✂ 0
just 1 exam ✂ ✂ ☎ ☎ ☎ -1
several exams ☎ ✂ ✂ ✂ 2
drop result ☎ ✂ ✂ ✂ 2
flexible grading ☎ ✂ ✂ ✂ ✂ 3
voluntary homework ✂ ✂ ✂ ☎ ☎ ☎ 0
ungraded homework ✂ ✂ ✂ ✂ ☎ ☎ ☎ 1
graded homework ☎ ☎ ☎ ✂ ✂ ✂ ✂ 1
flexible workload ☎ ✂ ✂ 1
extra work counts ☎ ✂ ✂ ✂ 2
open labs ✂ ✂ ✂ ☎ ✂ ✂ 4
closed labs ☎ ☎ ✂ ✂ ✂ ☎ 0
supervision ☎ ☎ ☎ ✂ ✂ -1
no supervision ✂ ✂ ✂ ☎ ☎ ☎ ☎ ☎ -2
group work ✂ ✂ ☎ ☎ 0
lectures ☎ ☎ ✂ ✂ ✂ ✂ 2
electronic lectures ✞ ☎ ☎ ☎ ✟ ✂ ✂ ✂ 3
no lectures ✂ ✂ ✂ ☎ ☎ ☎ 0
script [ ☎ ☎ ] ✂ ✂ 2
suppl. material [ ☎ ☎ ] ✂ ✂ ✂ 3

With this table in mind, we then did a complete redesign

Fig. 1. Basic microcontroller hardware
of our course, employing the mechanisms indicated by bold
numbers in the total column of the table, and had far better suc-
cess with it while still keeping the workload of the professor
acceptably low. We can thus conclude that it is possible to get We decided to use an Atmel microcontroller because they
good educational and motivational results with only moderate are common and fairly inexpensive, and because their RISC
concessions on the financial part. architecture is easy to understand and to program. In order

37
to be more flexible, we designed several separate boards: The
microcontroller board only contains the microcontroller, an
ATmega16, and its supportive logic (power jack and regulator,
oscillator, reset button, programming connector) and single
connectors to its I/O pins instead of a fixed connector like
for example in [7]. As a side benefit, the microcontroller can
be exchanged freely, and we are in fact working on several
additional controller boards (HCS12, ARM, MSP430) to allow
good students to broaden their knowledge by switching to a
different controller during the course. The simple I/O board
contains 8 LEDs, 8 buttons, 8 switches, a 6-digit numeric
display, a 4 4 matrix keypad, 2 potentiometers, and a light
sensor. Most of the exercises can be done with the controller
board and the simple I/O board. For communication to the
Fig. 3. Contents of the lab kit
PC, we also offer an RS-232 board which contains a serial
interface. All three boards are mounted on a wooden plate, see
Figure 1, and can be connected via normal wires. For more a power supply, and a Knoppix CD with our lab environment,
challenging projects, we offer additional boards like a motor see Figure 3.
board with dc and stepper motors, see Figure 2, an interface
board with serial, parallel, and CAN interfaces, or a chip-card
Apart from the hardware, we also offer some instructional
reader.
material. Although most of the course is lab work, there are
some accompanying lectures that give students an introduction
into the microcontroller and the hardware. To allow distance
learning and to remove the lecture load from the instructor,
lectures are not held in class, but will in the future be
provided electronically as slides and/or video with audio track.
A lecture script complements the electronic lectures. Finally,
manuals for the hardware are available, and we provide sample
programs to get students started.

B. Course Structure
Basically, our course employs a mixture of exams, light
compulsory workload and flexible voluntary workload that
allows different work styles while still yielding comparable
grades.
The course is divided into three parts. The first part is in-
tended as an introduction into the programming environment,
Fig. 2. Motor board with dc and stepper motors
the microcontroller architecture, the hardware, and assembly
language. The second part is dedicated to learning how to
program the basic features of the microcontroller like timers
The lab kit allows our students to work in their own and the analog module, how to handle interrupts, and how to
time according to their own schedules. They only have to program typical hardware like matrix keypads and numeric
synchronize with us for homework submissions and the exams. displays. The third part is concerned with interfaces, mo-
Student feedback for the kit is very positive, and we feel that tor control, and application programming. Both second and
the lab kit especially helps slower students to catch up and third part are in C. To ensure that the students learn the
acquire the necessary programming skills. Students could also most important concepts, they have to do a couple (3-4) of
keep the lab kits if they desired, and this offer was taken by compulsory exercises in each part. These exercises cover the
over 70% of the students, showing us that (a) many students microcontroller’s features in simple tasks designed to convey
got interested into the topic during the course, and (b) the lab basic knowledge about how the feature works and how it
kit is useful to them beyond the course. is programmed. We decided to focus on simple tasks here
because in our experience complex tasks cause students to
concentrate on getting the program to work instead of on
This year is the first in which we offered take-home lab getting it right. To deepen their knowledge, students may select
kits for a deposit of about 70 Euro. The kit consists of the additional voluntary exercises from a significantly larger (20-
microcontroller, simple I/O and RS-232 boards, wires, cables, 30) exercise pool. Some of these exercises cover special details

38
of the microcontroller or the hardware in depth, others are help with debugging problems, check whether students are
applications. Depending on the quality of the work and the on schedule with their homework, and generally lend an ear
complexity of the exercise, students get a certain amount of in case of problems and keep up the students’ motivations.
“bonus” points per completed exercise, which are added to We found that the tutors have a tremendous influence on the
their course result. motivation and performance of the students and are in fact
Since there cannot be any guarantee that students do their the pivotal factor in determining the motivational impact of a
homework all alone, each part is concluded by a programming course.
exam (consisting of two exam tasks) and a theory exam. Since the lab hour is not for doing work, but for discussing
Attendance at all exams is not compulsory, but students must problems and asking questions, it could easily be conducted in
fulfill some minimum requirements concerning their exam a distance learning setting via Webcam. The important thing
results for a passing grade. If students come to all three exams here is that the student is encouraged to regularly report about
of a type, their worst result on these exams will be dropped. his or her progress, and that the tutor keeps track about each
student’s progress and motivation and can react to problems
C. Lab Organization at an early stage.
Although closed labs seem to be more effective [8], they
D. Personnel
are hard on resources and not flexible w.r.t. working hours.
Even though we concur with [8] that having a closed lab in In order to minimize personnel costs and to provide scal-
the initial phases of the course would probably be a good ability, the course uses a hierarchical system for student
thing, we cannot do this due to resource problems, except supervision: The course is managed by one assistant professor,
✁ ✄ ✆ ✞ ✠ ✁

if we make students work in groups. However, after two one teaching assistant, and tutors, where is the
years of experience with group work in a closed lab setting number of students in the course2 .
(3 persons/group), we cannot affirm the results of [9] that Tutors work for three hours a week and meet with 5 students
students learn more in group work. We suspect that the effect per hour. In this time, they talk with their students about their
of group work depends on the tasks posed to the students: progress, check their work, answer questions, and determine
Large and difficult tasks that cannot be done by one member how well the students have mastered the material so far.
alone make for good teamwork and allow students to learn They should also do a preliminary grading of their students’
more in the team; simple tasks, however, are more conducive homework (check whether the programs work and whether
to one student doing the work and the others just watching. the protocols are in order). The work is very challenging for
The student doing the work possibly benefits, but the onlookers the tutors, so this job requires highly motivated students. It
will lack essential practical programming and debugging skills is important to be on the look-out for such students during
at the exam. Since we focus on simple tasks that capture the term, and to actively interest them in a tutor job for the
the essentials, we observed that group work is detrimental following year.
to overall student performance and also brings the danger of The teaching assistant, who works for 18 hours per week, is
students over-assessing their skills – after all, they put in a lot responsible for the lab equipment, for organizing the exams,
of hours watching and feel that it should suffice if they know and for the final grading of the homework (after checking for
how to do it in theory. For many students, the exams are real plagiarisms). The TA is also the first address for tutors with
eye-openers in this regard. questions or problems.
So closed labs and group work are out. On the other hand, The assistant professor is responsible for the course contents
we also have experience with an open lab and voluntary and organization, for the course materials, for the exam
individual work, which resulted in students putting off the contents, and for exam grading. Since we use electronic
work as long as possible and then getting into trouble with the lectures which only have to be done once, after course setup
exams due to lack of practice. Also, retention in this course is complete the course poses only a minimal load on the
was terrible, only about 30% of the students remained until the professor.
end of the course, because most failed to acquire the necessary IV. G RADING
skills in time. Furthermore, the lack in supervision resulted
in exercise solutions that appeared to work, but were pretty For grading, we must ensure that diligent students can use
convoluted and sometimes even wrong. Yet, students thought homework to balance bad or missing exam results, while at
that their solutions were right and without feedback had no the same time not allowing dishonest students to pass with
way of knowing otherwise. So just doing open labs was not a somebody else’s work. To this aim, we do both theory and
viable option either. programming exams, and we require that all students should
To get the best of both worlds, we decided on a mixture of get at least two out of the six programming exam tasks right.
open and closed labs: Students are expected to work at home, Students who fail to meet this requirement do not get a passing
but each student is assigned to a supervised lab hour once a grade, no matter how many points they attain. This ensures that
students who pass the course have some basic microcontroller
week. Attendance is not compulsory, but highly recommended.
The lab supervisor (tutor), a senior student, is assigned 5 2 This maximum allowable number of tutors is prescribed by the computer
students per hour, and is there to answer their questions, science faculty of the TU Vienna.

39
programming skills. For an excellent grade, students must also tive side, students can try out their programs and have the
show that they have a grasp of the theory, so attaining at least opportunity to debug them. This in turn allows us to use an
one third of the theory points is a prerequisite for an excellent all-or-nothing grading, which definitely would not be accepted
grade. by students were this just a paper exam. As another benefit, the
exam results are instantly available, no later grading session is
A. Programming Exams
necessary. On the negative side, since students generally pass
Our programming exams consist of two tasks each. Students on their exam tasks to the colleagues that come after them, one
get two hours time, starting with a half hour design phase either requires a lot of PCs or a lot of different exam groups.
without computer, followed by the programming (and testing) Since coming up with good yet simple exam tasks is quite
phase on the actual lab hardware. To attain points for an exam hard, the first is preferable if the computers and hardware are
task, students have to write a correct program. Since no partial available.
credit is given, the tasks are very easy and generally consist To allow a distance learning setting, we need to give
of at most 20 lines of code. Students are provided with a students, who are sitting the exam at some external location,
framework, consisting of an Assembler or C skeleton program, remote access to the automatic test system. We should also
possibly header files, additional object files, and a Makefile, provide them with remote tutor help via Webcam. We are
and just have to add their code to the skeleton to complete currently working on this problem in the SCDL project. Note
the task. This allows us to place our exam tasks within more that as soon as the exam can be conducted remotely, a large
complex settings while still giving simple student tasks. For number of students can sit the exam concurrently. The persons
example, an exam task could be: supervising them do not have to be trained, only the tutors at
Task: Create a program which acts as a frequency the university giving the debugging help do.
measurement routine. Configure the Input Capture
Function of Timer/Counter 1 to determine the fre- B. Theory Exams
quency produced on pin PD7. For our theory exams, we decided to use exams with yes/no
The frequency is in a range between 10 Hz and 99 questions instead of the traditional essay exams. Our decision
Hz, so use prescaler 256. Display the ten’s place of was led by our desire for a fair grading scheme and by the
the measured frequency value on the display, using fact that such exams can be graded automatically. Hence, we
the provided function display result(). conduct our theory exams on computers, and the evaluation
Here, the students just have to set up the input capture is done automatically as well. Originally, our exam questions
feature of a particular timer and compute the frequency. All were classical multiple choice questions in the form of a root
other functionality, like displaying a number or generating the (question) and several stems (answers) [10], but we gradually
input function that should be measured, is provided by the shifted away from this exam type and now use topics with
framework. several independent yes/no questions each. First of all, it
broadens the range of material that can be covered with the
Tutors are available during the exams to help students with exam (not every topic can be covered by a question with
hardware trouble. Since hardware-near programming is prone multiple plausible answers). As a nice side effect, we found
to simple but hard-to-find bugs, the tutors are also allowed that students like this kind of exam better as well.
to help with debugging problems, but only if the student can
demonstrate that he or she understands the material and just Correcting the exams is done automatically. A correct
✆ ✆

suffers from a blackout. answer is worth points, a wrong answer gets , and no
✁

Right now, the correctness of the student programs is answer get points. In consequence, if the maximum number
checked manually by the tutors. To help the tutors assess of attainable points is , then a student can get between
✁ ✁ ✁

whether the register initializations of the timer and other and ✁ points on the exam. A negative exam result is set
components are correct, we add some functionality to the to zero. Guessing is neither punished nor rewarded by our
provided framework to regularly check the register configura- system: On the average, a student will neither gain nor lose
tions and put the results on the LEDs. Thus, the tutor can see with guessing. However, we strongly discourage students from
at a glance whether the register initializations are correct, or guessing. At this time, we do not feel the need to actively
whether there are missing and/or superfluous bits. In addition, punish guessing by making the penalty for a wrong answer
we are currently working on an automatic external test system any larger, but we could of course do so. However, since this
which can provide the microcontroller with specific test stimuli also punishes students who did not guess but simply got the
and verify its responses. Since the software check outputs its answer wrong, we decided to refrain from using this means
results on the LEDs, these results can easily be taken over by to curb guessing as long as we get the impression that (most)
the external test system, which can thus perform a completely students try not to guess anyway.
automatic correctness check. We expect to have this system To improve the quality of our exams and to increase
working by next summer. the students’ trust in our questions, we conduct a statistical
Doing the practical exams on a computer with the actual evaluation of the exam papers prior to grading the exams, and
hardware has both advantages and drawbacks. On the posi- we make students aware that we do this. For each question,

40
our statistic calculates the percentage of students who got Questions: Turn SW1 to OFF. Wave your hand
the answer right, the percentage who got it wrong, and the closely over the board, tap or wiggle the wire
percentage who abstained from answering. Questions with a connecting SW1 to the controller. What do you see
high percentage of wrong answers or abstentions are carefully on the LEDs? Why?
examined for their appropriateness, and are removed from Set SW1 to position ON. Repeat the actions of the
the exam if we belatedly find them controversial. With this previous question. What do you see on the LEDs
method, we have caught a fair share of ambiguous questions now?
which slipped by our initial scrutiny but were identified by the This exercise demonstrates the effects of a floating pin
number of students who had trouble with it. As a side benefit, (when switch SW1 is turned OFF, the line floats; when it is
this method also points out errors in the question database. We ON, the line is grounded). Students observe the volatile nature
highly recommend this procedure for anyone who wants to do of the power levels on the wire when they wave their hand over
automatically evaluated exams. It does not cost much time, it or when they touch it, and are encouraged to speculate on the
but makes the exams fairer and increases student satisfaction. technical reasons for the observed effects. The exercise helps
them identify floating problems, which occur quite frequently,
The theory exams can be graded very efficiently. Even with in future programs.
the additional effort of the statistic, we grade all exams (about Our most complex exercise task is to measure and plot the
100) in a couple of minutes, and would have no problems at speed curve (acceleration and deceleration phases) of a dc
all to grade 1000+ exams either. A general advantage of our motor for different PWM ratios. The students have to program
electronic exams is that they can be conducted anywhere where the microcontroller to gather the data, send it over the serial
a computer and network are available. So it is no problem if interface to the PC, and create a 3D-plot with gnuplot. In their
such an exam is conducted at another university, or even at protocol, they have to interpret the resulting plot. This exercise
a high-school, as long as a trusted person is supervising the forces students to put thought into program design, induces
exam. As a drawback, one needs either many computers or a them to reuse previously written code, and thus gives the
lot of different exam questions. students a taste of complex application program development.

C. Homework The major problem of homework is plagiarism. This can

In addition to exams, students do some exercises from either take the form of copying (student A copies the work of
a larger set as homework. In order to get credit for their student B, possibly slightly modified), or substitution (student
work, they have to submit a working program and a protocol A writes the homework for student B). Unfortunately, there is
describing their work and answering some questions about the no sure-fire means to verify whether a student has done the
subject. work by himself. Even oral exams may not do the trick, since
the student could have been tutored by the author of the code.
The homework is the only part of the grading that does
Plagiarism detection mechanisms [11] can be used, but they
not scale well and is easily exploitable by dishonest students.
too cannot identify cases of substitution. Therefore, our main
However, it greatly increases the flexibility of the grading
means to catch such students is our requirement that students
system, is beneficial to the student’s development of practi-
complete two exam tasks for a positive grade. This makes sure
cal skills, and thus vastly improves student motivation and
that students passing the course can write simple programs by
satisfaction. Therefore, we include graded homework despite
themselves. A similar approach has been taken for example
all its problems.
by [12]. Of course, this does not catch students who know
To lessen our workload, we need homework that can be
how to program and are just too lazy to do the work by
corrected mostly by tutors. Here, the microcontroller course
themselves. Therefore, we additionally check for similarities
benefits from its low-level approach: The exercises generally
in the program codes and the protocols. Right now, we do
are not complicated. Thus, a well-trained tutor can check
this manually, which is extremely time-consuming. We thus
whether a program works, and can also give pointers if the
strongly recommend to use an automatic tool for this purpose,
solution is not programmed well. The same goes for the
and we are currently looking for suitable tools.
protocol: The tutor can check whether the answers to the
questions are correct, and whether the protocol is well-written. With our lab kits, homework is naturally suited for distance
This takes the bulk of the load off the instructors, who only learning settings, since students can work anywhere. Electronic
have to verify the first assessment of the tutors to assign the submission should not be a problem either, but in this case
grade. we should also provide some means for automated program
For example, a simple homework task would be to explore verification, both to relieve the tutors from the load of having
the effects of a floating pin: to check the correctness of all student programs and to allow
Task: Connect SW1 to pin PA4, set PA4 to input the students to check the correctness of their programs prior
and do not activate the pull-up. In the main loop, to submission. To allow students to get feedback from their
display register bit PINA4 on LED0 and bit PORTA4 tutors on their submitted work, tutors should be available via
on LED1. Webcam to discuss the program and the protocol. So students

41
can submit their work anytime and can get feedback from their tutors a great deal, foremost a tool to manage the student data
tutor in his or her next (virtual) lab hour. (student name, progress, homework submissions, submitted
voluntary work, . . . ). We are currently working on such a tool
V. D ISCUSSION in our SCDL project and expect it to be ready by next year.
This year’s course was on the whole well received by The tool should also be able to handle electronic submissions
our students. Student favorites, in descending order, were the and check for plagiarism.
quality and friendliness of our tutors, the take-home lab kits, It is also important to prepare tutors properly for their work.
the interesting and diverse hardware, the possibility to get They must of course be trained on the exercise material, but
bonus points for additional work, the large exercise set with they must also be made aware of their social duties. For
its varied exercises (and its availability from the start of the instance, they must understand why they should monitor the
course), and the flexible grading system. performance of their students and play an active role in their
Students criticized the fact that we do programming exams, development. We must also call to their attention the problems
their all-or-nothing nature, and that we demand two completed of plagiarism and their obligation to try and prevent such
programming exam tasks for a positive grade. things among their students. This is of particular importance
Suggestions for improving future courses included addi- because tutors, as senior students, are liable to have “helped”
tional and more complex hardware, and to be able to take their own friends one time or another, and are thus vulnerable
home all the hardware (the motor boards were only available to turning a blind eye when encountering such activities among
in the lab this year). their own students. So care must be taken to explain to tutors
why plagiarism hurts the person that plagiarizes.
We do of course try to improve criticized areas, but cannot We never really addressed these issues in former years, but
do much about our programming exams. Neither do we really always chose tutors that we believed were liable to have a good
want to change our procedures. After all, our exam tasks impact on students. By actively making tutors aware of their
are kept fairly simple to ensure that prepared students have social role and explaining their impact on student motivation
sufficient time, and the tutors are allowed to help to prevent and grades, we hope to improve tutor motivation even more.
students from failing just because of a simple bug they were
too nervous to find. Our impression is that the students take Since student satisfaction with our course is very good,
the exams too lightly and do not appreciate the fact that just student retention is quite high (70%). Of the students who
getting a homework exercise to run with the help of the tutor remained in the course, 73% passed. These are acceptable
and a lot of trial-and-error does not make them proficient values, but we hope to increase these numbers even more by
microcontroller programmers. An unfortunate aspect of our improving the quality of support. The hardware in its current
on-target programming exams is that students are generally form is well suited to convey the course contents. To increase
convinced that they were “just five more minutes” away from the fun aspect of our course, we plan to introduce a line-
a correct solution, which makes them feel the lack of partial following robot into the third part. It will be used to teach
credit all the more3 . We believe that we can overcome this motor control and power-efficient programming issues.
problem with better exam preparation, and thus in the future Although we are currently not conducting the course in a
will ask our tutors to assess the students’ current level of distance learning setting, we could easily do so. Due to the
knowledge regularly. lab kits, homework can be done at home. All course material
Since the homework is beneficial to students, we allow it is contained on the Knoppix CD that is part of the lab kit,
even though plagiarism may occur. Of course, we try to iden- so students have all information they need at home. The
tify plagiarism, and in future courses will emphasize more why supervised lab hour can easily be offered via Webcam. The
plagiarism is detrimental to performance. A study conducted theory exams are already conducted via Internet, and since
on patterns of plagiarism [13] indicates that plagiarism is the exam supervisor does not have to help students, any exam
mostly done by weaker students, possibly because of problems room and supervisor would suffice as long as it is guaranteed
with handling the work. We hope that regular supervision and that students cannot get illegal help during the exam. The
support by the tutor can help weaker students overcome their programming exams currently need skilled supervisors to help
problems without resorting to plagiarism. with debugging problems, but this might also be achievable
with a Webcam, so as soon as our test system to automatically
To improve our motivational impact without too much evaluate the correctness of student solutions is available, the
financial backlash, we strove to shift as much supervision load programming exams can be conducted via Internet as well.
as possible to tutors. It turns out that tutors can handle the Although due to some hardware problems we do not yet
bulk of the student supervision, as long as they in turn are have experience with the electronic lectures, some students
well supported. Here, we still lack a few tools that would help already told us that they think it is a great idea. We will try
3 It is interesting to note that in the cases where we followed up such claims,
to make each lecture as self-sustaining as possible, complete
it always turned out that the student solution had one or more serious errors with indications on which other lectures it relies, to allow other
and was far from being complete. courses to use our lectures as necessary. In turn, we believe it

42
would be useful to generate a faculty-wide database of such exploited by lazy students to get a better grade. Finally, we
lectures, possibly even with exam or self-assessment questions need a suitable course management tool that also supports
about the material, so that instructors can easily assemble tutors in their work.
material students should brush up on for their course.
R EFERENCES
VI. C ONCLUSION [1] W. Wolf and J. Madsen, “Embedded systems education for the future,”
The course in its current form is successful, student satisfac- Proceedings of the IEEE, vol. 88, no. 1, pp. 23–30, Jan. 2000.
[2] B. Haberman and M. Trakhtenbrot, “An undergraduate program in
tion is high. Our course structure has proved effective, students embedded systems engineering,” in 18th Conference on Software En-
like the take-home lab kits, the flexible grading scheme, and gineering Education and Training), Apr.18–20, 2005, pp. 103–110.
the homework exercises. The course can easily be exported to [3] MCLab, “Microcontroller homepage,” 2005, www.ecs.tu-
wien.ac.at/lehre/Microcontroller/MCLab.shtml. [Online]. Available:
other universities or can even be held in a distance learning http://www.ecs.tuwien.ac.at/lehre/Microcontroller/MCLab.shtml
setting. [4] C. E. Nunnally, “Teaching microcontrollers,” in 26th Annual Frontiers
in Education Conference (FIE’96), vol. 1, Nov. 6–9, 1996, pp. 434–436.
To keep the course scalable and efficient, we employ a hier- [5] M. Amirijoo, A. Tešanović, and S. Nadjm-Tehrani, “Raising motiva-
archical structure for supervision, with 1 tutor per 15 students tion in real-time laboratories: The soccer scenario,” in 35th SIGCSE
Technical Symposium on Computer Science Education, Mar. 2004, pp.
and 1 TA for all tutors. Lectures are provided electronically, 265–269.
so after the setup phase of the course, the professor only has [6] J. W. McCormick, “We’ve been working on the railroad: A laboratory
to handle the course organization and assign the final grades. for real-time embedded systems,” in 36th SIGCSE Technical Symposium
on Computer Science Education, Feb. 23–27, 2005, pp. 530–534.
Final scores are composed of programming exam results, [7] R. Bachnak, “Teaching microcontrollers with hands-on hardware exper-
iments,” Journal of Computing Sciences in Colleges, vol. 20, no. 4, Apr.
theory results, light compulsory homework, and voluntary 2005.
bonus homework. A certain minimum score on the program- [8] A. N. Kumar, “The effect of closed labs in Computer Science I: An
ming exams is necessary to attain a positive grade to prevent assessment,” Journal of Computing Sciences in Colleges, vol. 18, no. 5,
pp. 40–48, May 2003.
unprepared students to pass by plagiarizing their homework. [9] L.-K. Soh, A. Samal, S. Person, G. Nugent, and J. Lang, “Closed
laboratories with embedded instructional research design for CS1,” in
There are still some open tasks which can make the 36th SIGCSE Technical Symposium on Computer Science Education,
Feb. 23–27, 2005, pp. 297–301.
course more self-supporting. First of all, we intend to [10] B. Weiss and G. Gridling, “Creating and grading multiple choice
expand our set of electronic lectures to include video tests,” Vienna University of Technology, Institut für Technische
introductions to the hardware, and generally introductions Informatik, Research Report 63/2004, Dec. 2004. [Online]. Available:
http://www.vmars.tuwien.ac.at/frame-papers.html
to all subjects students have problems with (e.g., C [11] X. Chen, B. Francia, M. Li, B. McKinnon, and A. Seker, “Shared
programming). Second, we will continue to develop our information and program plagiarism detection,” IEEE Transactions on
automatic test system, which is currently only available Information Theory, vol. 50, no. 7, pp. 1545–1551, July 2004.
[12] K. W. Bowyer and L. O. Hall, “Experience using “MOSS” to detect
as a prototype, and work on the web cam approach cheating on programming assignments,” in 29th Annual Frontiers in
so we can eventually conduct all exams remotely and Education Conference (FIE’99), vol. 3, Nov. 10–13, 1999, pp. 13B3/18
without trained supervisors on site. We are also currently – 13B3/22.
[13] C. Daly and J. Horgan, “Patterns of plagiarism,” in 36th SIGCSE
looking for suitable plagiarism detectors to strengthen the Technical Symposium on Computer Science Education, Feb. 23–27,
value of our homework exercises, which can in theory be 2005, pp. 383–387.

43
 A System for Automatic Testing of Embedded
Software in Undergraduate Study Exercises
Voin Legourski, Christian Trödhandl, and Bettina Weiss
Vienna University of Technology,
Embedded Computing Systems Group E182-2,
Treitlstr. 3/2, 1040 Vienna, Austria
Email: [email protected], {troedhandl,bw}@ecs.tuwien.ac.at

Abstract— As student numbers in embedded systems lab teaching concept for embedded systems laboratory courses.
courses increase, it becomes more and more time-consuming to This concept incorporates the required web infrastructure and,
verify the correctness of their homework and exam programs.
depending on the requirements of the course, customized
Automatic verification can vastly improve the speed and quality
of such tests. This paper describes a system that can carry out learning packages and remote workplaces. The distant goal
black-box tests to verify whether the embedded software running of the project is to provide a remote learning environment
on a target system meets predefined requirements. To this aim, we that can be used for most of the embedded systems courses at
employ a special test board using an ATmega128 microcontroller the Vienna University of Technology. This will enable us to
which is connected to both the target system and to a host
increase our training capacity and to better support working
computer. Tests can be selected and started remotely, the results
are presented to the user on the host. Monitoring and control via or handicapped students.
Internet is also easily possible. A special meta-language is used There are other projects similar to the SCDL project, with
to describe the correct behavior of the tested program, and this the goal to extend the education in embedded systems in a way
description is compiled and downloaded to the test system via a to meet the requirements of the constantly growing embedded
standard RS-232 interface, where the test is executed. The same systems industry [1]. Such projects are described in [2], [3],
interface is used to control the tests and for transfer of data and
end results. [4]. In the past years, many systems have been developed
which can test embedded software and hardware in different
Index Terms—embedded software education, automatic testing, ways. For instance, testing by fault-injection is performed by
black-box testing
the tools described in [5] and [6]. The object-oriented scenario-
I. I NTRODUCTION based test framework shown in [7] places its emphasis upon
test re-usability in case of product families or new product
Laboratory courses in embedded systems programming are versions. In contrast to our solution, which performs black-
characterized by tight resource constraints and a significant box functional tests, their approach requires knowledge of the
expenditure of time and effort per student. One of the major underlying software structure of the tested system.
factors contributing to the time expenditure is the verification
Our test system employs a special language to describe
of student programs, be they homework or exam solutions.
tests and expected results. There are several other projects that
To facilitate this work, we proceeded to develop a test system
use special languages to test embedded systems. For example,
which allows to verify the functionality of simple embedded
SystemC is a language that defines abstract models of software
software. In a first trial run, we plan to employ the test system
and hardware components, and [8] explores the possibilities of
in our introductory microcontroller course to automatically
using SystemC for testing embedded systems.
verify the correctness of student exam programs. The Micro-
The system described in [9] is a generic test equipment for
controller lab course is held once every year and is attended
embedded software. It is based on the C++ interpreter CINT
by 120 to 150 undergraduate students. It teaches the basics of
and adopts the C++ language and its features.
microcontroller programming, such as the usage of timers, a/d
Another design of a generic test and maintenance node for
converters, UARTs, and so on in assembler and C language
embedded system testing is the subject of [10]. It is built on
on simple 8 bit, 16 bit, or 32 bit microcontrollers, and is thus
the IEEE 1149.1 standard test bus and is designed to provide a
particularly well suited for a first trial. In the long run, the
cheap solution for the design-for-test and built-in-test overhead
tool will be used to automatically verify student programs in
cost problem.
several different embedded systems courses.
This work is part of the FIT-IT project SCDL “Seamless Our own test system [11] is executed on an ATmega128
Campus: Distance Labs”1 , which aims to develop a remote microcontroller and is programmed and controlled via a Linux
host computer. The basic idea of our system is to supply
1 The “Seamless Campus: Distance Labs” project received support from the tested target system with input signals on its I/O pins
the Austrian “FIT-IT Embedded systems” initiative, funded by the Austrian and to evaluate its responses in order to compare them with
Ministry for Traffic, Innovation and Technology (BMVIT) and managed by
the Austrian Research Promotion Agency (FFG) under grant 808210. See predefined patterns. Hence, we do black-box tests only and
http://www.ecs.tuwien.ac.at/Projects/SCDL/ for further information. are mainly interested in the timing of the response signals.

44
The tests and expected results are defined in a special meta- Our test hardware consists of the test system itself, the tested
language, which in practice allows any type of program be- board, which we will call the target system in the remainder
havior to be tested. The test system performs and evaluates the of the paper, the host computer, and the connections between
tests automatically and provides reports to a human operator them. The whole structure is shown in Figure 1.
on a local or remote computer. New tests can easily be loaded
to the system and executed.
Compared to the other works cited above, our approach
corresponds well to the goals of an embedded software test
system for the education. In contrast, [7], [9] are well suited
for testing high-level functionalities and expect high-level
communication of some kind in order to perform tests, and
[8] is based on abstract modeling.

In the following paper, we first give an overview of our

test system in Section II, then proceed to describe the system
implementation in more detail in Section III. Section IV
shows the system in action with a small example, Section V
discusses the usefulness of the system, and Section VI lists
some possible extensions. Section VII concludes the paper.
II. T EST S YSTEM OVERVIEW
Fig. 1. Test system hardware and connections
Resources for undergraduate studies are rather limited – in
obligatory courses, one or two faculty members have to handle
up to 150 students, supported only by about ten tutors. Yet, Currently, the test system is a universal ATmega128 board,
embedded systems programming skills are best conveyed by which was developed in the Department of Computer Engi-
letting students program a lot, so many such student programs neering at Vienna University of Technology. In addition to
have to be evaluated. In the Microcontroller laboratory course the microcontroller, a digital to analog converter is used in
that will be used for a trial run, for example, students have order to extend the functionality of the tests and to support
to solve about 10-15 programming exercises during the term, analog test signals. There are four types of signals that can be
may voluntarily submit up to another 15 programs to improve connected to the target system board: Digital signals, analog
their grade, and additionally have to attend exams. The course signals, RS-232, and the TWI (I2 C) interface.
offers three practical exams, and students need to do at least The ATmega128 microcontroller executes a C program,
one of these exams to pass, but may also come to all three the interpreter, whose main function is the interpretation and
exams to further improve their grade. On the average, about execution of the actual test program instructions, which are
120 students attend these exams. Each exam consists of two written in a special meta-language. The interpreter is also
simple programming tasks which the students have to solve in responsible for the communication with the host computer and
the given time. Students work on the hardware during these the loading of new tests. Note that due to the interpreter, the
exams, so they can try out their solutions and debug their test program itself is system independent. It can be executed
programs. Whenever a student believes he or she is finished, on any hardware that provides the interpreter. So although we
(s)he can submit the solution. are currently using the ATmega128, we could easily change
In our experience, much of the time spent per student in the system by porting the interpreter.
undergraduate embedded programming courses is invested into Two software tools are located on the host computer: The
correcting homeworks and exams, so it makes sense to look meta-language translator, which translates test descriptions
into means of automating this process. Since our undergrad- into “executable” code, and the mc prog programmer tool,
uate courses generally tend to use simple exercises to teach which can download the tests to the test system and manipulate
the basic concepts, automatically verifying the correctness of them. The results from the test evaluation as well as all
programs appeared to be an achievable goal. messages are received at the host computer via the standard
We wanted our test system to be versatile and to be useful to serial port in text format.
a wide variety of courses, ranging from FPGA programming The language developed to describe the test behavior is
over different microcontrollers to industrial automation with referred to as “meta-language”. It is an assembler-type lan-
SPS hardware. So simulators or code instrumentation were no guage whose purpose it is to facilitate the writing of test
viable options. Instead, we focus on the interface of the control programs and to make them more understandable. It offers
unit to the hardware, in a microcontroller’s case its I/O pins, a set of instructions including arithmetical and logical opera-
and use black-box tests to verify program functionality and tions, memory manipulations, compare and jump instructions,
timing. Of course, these tests have their limitations, but they time measurement, analog and digital signals I/O, TWI and
are the most flexible solution as far as the supported target UART communication interfaces, and test control instructions.
system hardware is concerned. Currently, the meta-language is the top-level interface to the

45
test system. handle this change in functionality without requiring a change
in connections. Hence, it is of no particular importance how
III. I MPLEMENTATION
the digital I/O pins of the target system are connected to the
A. Hardware test system.
As we already mentioned, the test system is implemented There could be one problem when connecting the test
on a 5V Atmel ATmega128 microcontroller, which is driven system to the target system, and this pertains to the analog
by a 16 MHz clock. An external digital to analog converter, pins of the target system, which may either be used as digital
the DAC6574 of Texas Instruments, is connected via a TWI I/O or as analog I/O. In the case of digital I/O, they should be
interface. Figure 2 shows a block schematic of the test system connected to digital I/O pins of the test system. If the target
hardware and its available connections. requires analog inputs, however, the pins must be connected
to the outputs of the external d/a converter. Different tests may
entail different functionality of these pins, thus necessitating
a change in the connections.
In this version of the test system we do not have any
built-in solution for this problem, so currently the user has to
reconnect the pins if the change in functionality is required. In
a future version, we will solve this problem with an external
multiplexer, which can of course in turn be controlled by the
test system, see Figure 3. This technique allows to dynamically
switch between testing analog input functionality and digital
I/O (or analog output). Of course, it requires one more pin
to control the multiplexer, so it might be sensible to control
several analog inputs/outputs of the test system simultaneously
if the extra pins cannot be afforded.

Fig. 2. Test system block schematic

32 digital inputs and outputs are available for the digital

signals. Additionally, up to 14 other pins could be used for
digital signals if their primary functions are not required.
These are the analog inputs, the two UART interfaces, and
the TWI interface. However, in order to prevent or at least
minimize changes to the connections between the test system
and the target system, it is recommended that the special
function pins not be used for digital I/O.
In addition to the digital I/O, the ATmega128 has 8 analog
input pins with 10 bit resolution. A resolution of 8 bit is also
supported by the test system. The external d/a converter is
controlled via the TWI (I2 C) serial bus of the ATmega128 and
provides 4 analog outputs with 10 bit resolution. Again, an 8 Fig. 3. Connecting more than one test signal
bit resolution is supported as well. More converters could be
attached to the bus as necessary, and the test system currently Note that in most cases the problem will not occur anyway,
supports two DACs and thus 8 analog outputs. Note that the since normally the connection between hardware and the
TWI interface can also be used to test TWI code on the target control unit are fixed, so the pin functionalities will remain
system, independently of the function of the DAC module. the same over all exercises and exam tasks that use this
One of the two UART interfaces of the test system is used hardware. For courses that do not use such statically assigned
for communication with the host computer. Over this interface, connections, it may still be feasible to formulate program
the user can control the tests, and data can be sent back to the specifications that keep these problematic pins fixed. So this
host. The second UART interface can be used to test UART problem does not pose much of a limitation on the test system
code running on the target system. in its current form, and a couple of such multiplexers will be
B. Connections sufficient to support the few pins that for whatever reasons
must remain flexible.
Our test system can dynamically assign the functionality
of a pin. So if, for example, a certain pin PB0 of the target Another aspect we do not currently address is the problem
system is used to output a PWM signal in one test and utilized of different power supplies for target and test system. If the
as an input from a switch in another, the test system can target system happens to work with different voltage levels,

46
level converters must be employed to bridge the gap between address. The #PHASES section contains one or more groups
the target and the 5V levels of the test system. of addresses and phase numbers.
Our meta-language also supports labels. Each label points
C. Software
to the address of the next instruction and does not need to
The software of the test systems consists of the translator be previously declared to be used in the code. Labels can for
tool and the programmer tool on the host, and the interpreter example be used in instructions which control the program
on the test system itself, see Figure 4. flow, like jump instructions. It does not matter whether the
instruction expects relative or absolute addresses. Another
application where labels are useful is in the definition and
subsequent call of subroutines.
Definitions can be used to associate a variable name with a
number in the range of 0 to 255. The value of the definition
cannot be changed once assigned, so it only allows the usage
of definitions as constants.
As we have already indicated, our meta-language supports
the definition and use of subroutines. They can be placed on
any address, usually at the end of the test program. Each
subroutine must start with a label and end with the return
instruction. Parameters can be passed only implicitly.
The translator tool is used to transform programs in the
meta-language into a hex-code that is ready to be transferred
to the test system. The translator should not be referred
to as a compiler, because no special high-level language
constructions are translated. One of the basic features that the
translator provides is the transformation of complex instruction
Fig. 4. Software structure of the test system parameters into a tightly packed form, which is thus not a
responsibility of the test developer. The parameters are packed
in spaces of less than 1 byte, so that one parameter byte can
The test description is written in the meta-language and contain one, two or more values relevant to the instruction.
is translated to a test program that can be executed by
the interpreter on the test system. The programmer tool is 2) Programmer Tool: The mc prog programmer tool re-
responsible for uploading the test program to the test system, alizes the communication between the host PC and the test
and for controlling the tests. system. It can download test programs or variable sets to the
system, and can start or stop a test. It accepts a hex-file as
The test program itself consists of one or more phases, input. The hex-file consists of hex-numbers as they are to
which can be individually controlled by the programmer. Each be uploaded into the memory of the test system, and of the
phase tests a particular aspect of the target program. Among directives (#PROGRAM , #VARIABLES , #PHASES ) which tell
the things that can be tested are the timing of signals, timing the programmer what to do with the data following it. The
relations between two signals, signal states, or analog outputs. hex-file must begin with a directive.
To perform the tests, the test system can generate diverse The upload to the test system is done through the serial port
stimuli ranging from simple digital or analog signals over of the host computer.
changing analog values to more complex actions like UART
communication. 3) Interpreter: The test system executes an instruction
interpreter which interprets the instructions that describe the
1) Meta-language and Translator: The meta-language is a
test behavior. All data required by the interpreter, such as the
full image of the instructions implemented on the test system,
size of the last uploaded test program and a pointer to the
so it resembles an assembler language with an emphasis on the
currently executed instruction, are stored in global variables.
functionality required for the tests. Additionally, some higher-
The test description itself is stored in the microcontroller’s
level constructs are implemented. Contrary to [9], our meta-
4kB SRAM.
language is built entirely on the test functionality and not on an
existing programming language. It is also not object-oriented
Every test description consists of several instructions. Most
as are [7] and [9].
instructions are 2 bytes wide (1 byte for the instruction code, 1
Each test description can contain up to three sections. byte for the parameters), with the exception of some extended
The most commonly used section is the #PROGRAM part, instructions, which are 4 bytes in length and represent func-
which contains the sequence of instructions which form a tionalities which either cannot be coded in two bytes or which
test program. #VARIABLES contains pairs of addresses and are an extension of the corresponding 2 byte instruction for the
sequences of values which are to be stored starting at the given purpose of optimization. Extensions perform a functionality

47
in one instruction which would otherwise take two or more only be performed by some pins of the ATmega128, but has
two-byte instructions. This leads to faster program execution, the distinct advantage that the measurement is interrupt driven.
because the instruction decoding time is roughly the same as Hence, it is possible to check the timing of two signals at the
the instruction execution time. same time. In both cases, the time is measured in milliseconds,
microseconds or in processor clock cycles.
A set of local variables can be used for the purposes of the The test system can also perform wait loops. Wait loops are
test process. They can be initialized during upload of the test for example useful when a time delay has to be implemented
program. The memory size for the variables is configurable in the test program, or when the test needs an external event
and is currently set to 512 bytes. Paging is used in order to (signal change) to continue. Note that the value of the waiting
allow the addressing of all variables. All instructions which period is stored in a variable and thus does not have to be set
use 8 bit addresses refer to the active page, paging itself is in advance, but can be dynamically computed during the test
controlled by special instructions. execution.
The first 16 variables can also be addressed with a spe- A variant of the wait loop is implemented by the wait-until-
cial 4-bit addressing mode. This type of addressing is pro- condition instructions. Depending on the parameters, these
vided so that the remaining 4 bits in the instruction word instructions wait for a positive or negative edge on a particular
are free for other parameters. For example, the instruction pin. The test execution is blocked until either the bit change
test_bit 3, 13 (in hex: 0x06 0x3D) tests the 3rd bit takes place, or until a previously defined timeout occurs.
of the variable at address 13 (the 14th variable). The result
is implicitly stored in variable 0. The 16 variables are not IV. E XAMPLE
affected by paging, so our example would have the same effect This section shows a practical example in the form of a
no matter which page is currently active. This addressing mode simple program executed on an ATmega16 target system. The
thus provides an easily reachable set of 16 variables and can program should wait for the press of a button and then start
be compared to the concept of registers in a microprocessor. to generate a PWM signal with a given period and ratio. A
Variable 0 is used as an accumulator, which means that it is timing diagram of the desired behavior of the tested target
used as an implicit parameter of some instructions or stores system is shown in Figure 5.
the results of an operation.

A special array contains values of user-defined timeouts.

These timeouts define the test system reaction in case of
instructions which depend on external signals, like for instance
time measurement instructions or instructions that wait for a
bit change. This prevents hang-ups in case of unexpected or
missing signal patterns. We can provide timeouts in the range
of 1 µs up to over a minute.
Fig. 5. Expected time behavior of the tested target
An important issue is the addressing of the digital and
analog pins of the test system. To this aim, all of the micro- The following connections are required between the target
controller’s registers can be accessed by using the instructions and the test system:
load_acc_reg and store_acc_reg . The names of all
I/O registers of the microcontroller are defined and can be used ATmega128 - ATmega16
in the test descriptions. Instructions for manipulating separate PA0 - PA0
bits of a register are also available. Thus, all digital I/O signals PB0 - PB0
of the ATmega128 can be manipulated through their ports’ The positive edge of PA0 is the start condition for the
registers. The analog I/O pins as well as the special signals ATmega16. The output is on PB0. The width of the PWM
like TWI and UART can be manipulated through special signal is 240µs for LOW and 220µs for HIGH. The response
instructions, depending on the function. Please refer to [11] signal on PB0 should be tested with an accuracy of 5µs.
for a detailed description.
To test the behavior of the target, we must write the test
The test system offers two types of time measurement: Com- description using the meta-language. The program consists of
mon blocking mode realized through polling, and input capture several parts, which are described below.
mode, which works in parallel to the test execution. Time The test program begins with the #PROGRAM directive,
measurement through polling can be performed by every pin after which the addresses of some variables are declared. For
of the ATmega128. It blocks the test program execution until instance, var2=2 shows that the name var2 refers to the
the measurement is finished or a timeout occurs, so it is for variable at address 2.
example not possible to check the timing of two such signals #PROGRAM
at the same time. Time measurement through input capture can // definitions

48
acc=0 // accumulator been performed and the next section is executed. It outputs a
var10=10
var2=2 message to the computer and terminates the test.
var6_32=6
// TESTING DONE! EVALUATE AND PRINT RESULTS
var6_32_LW=8
// PROGRAM TERMINATED WITH SUCCESS
var0_32=6
sbi_reg ADDR_PORTA 0 // turn off PA0
var0_32_LW=8
pc_printstr 0x80 // accuracy=+-
pc_printdec16 accuracy
pin0=0
pc_printstr 0x90 // us
low_duration=12
pc_printstr 0x60 // new line
high_duration=4
stop_test 0 1 // if here - test success
accuracy=14

The first instructions initialize pins PA0 and PB0, which are Now all that is left is the reaction for all error cases. Each
used later on. one begins with a label and ends with a termination of the
test. User messages are passed as well.
begin:
// label; defines start of the program // PROGRAM TERMINATED WITH ERROR
// INIT error_low:
cbi_reg ADDR_DDRB pin0 // PB0 as input sbi_reg ADDR_PORTA 0 // turn off PA0
sbi_reg ADDR_PORTB pin0 // PB0 -> pull-up pc_printstr 0x10 // message "LOW pulse duration="
cbi_reg ADDR_PORTA pin0 // PA0 -> 0 pc_printdec16 var2 // print duration value
cbi_reg ADDR_DDRA pin0 // PA0 -> output pc_printstr 0x60 // new line
// initialize timeout pc_printstr 0x50 // message must value=
set_timeout 0 ms var10 pc_printdec16 low_duration
pc_printstr 0x60 // new line
Then the signal that is expected by the tested target program pc_printstr 0x80 // message accuracy=+-
pc_printdec16 accuracy
is produced, and the test system checks whether the response pc_printstr 0x90 // message us
has come within the predefined response time. If not, the test pc_printstr 0x60 // new line
stop_test 0 0 // measured time not ok or timeout
program executes the jump instruction and outputs an error
message. error_high: // similar to error_low

// START error_timeout:
// apply positive edge on PA0 sbi_reg ADDR_PORTA 0 // turn off PA0
sbi_reg ADDR_PORTA 0 // sbi PA0 pc_printstr 0x70 // message timeout
wait_us_imm 50 // wait for about 50us pc_printstr 0x60 // new line
// (response time) stop_test 0 0 // measured time not ok or timeout

// test for response error_no_response:

load_acc_reg ADDR_PINB sbi_reg ADDR_PORTA 0 // turn off PA0
test_bit_var 0 acc // test bit 0 of acc pc_printstr 0x93 // message no response
if0_var acc // no response pc_printstr 0x60 // new line
jump_rel_imm error_no_response stop_test 0 0 // measured time not ok or timeout
// PROGRAM TERMINATED WITH ERROR
In the next section, the duration of the low pulse is
measured. The first negative edge starts an internal counter This concludes the program part of the test description. The
and the measured value is obtained with the next positive next section contains no instructions, but defines initial values
edge. The measure_pulse_width instruction provides a for the program variables, as well as the user messages. After
resolution of the ATmega128 clock cycle. Two possible errors each #VARIABLES directive, we place first an address and
are checked here: Whether a timeout has occurred during then constants that should be stored at this location. This is
the measurement, or whether the measured value does not done more than once, since each message begins at a different
match the requirements within the bounds set by the desired location.
measurement accuracy. In case of an error a corresponding // UPLOAD PREDEFINED CONSTANTS
#VARIABLES
jump is performed. 0x0000 // start @ address 0
// MEASURE duration of the LOW pulse
use_timeout 0 // define use of timeout 0 0 0 0
// pulse width in us, 0=LOW pulse, 1=one pulse, on 0 220 // high_duration must value
// pin0; store into var6_32 (32 bits), of IO port PINB 0 0 0 0
measure_pulse_width us 0 1 pin0 var6_32 ADDR_PINB 0 10 // var10 contains timeout
// CHECK whether timeout has occurred 0 240 // low_duration must value
if_flags flag_timeout 0 5 // accuracy
jump_rel_imm error_timeout
memory_transfer 2 0 0 var2 var6_32_LW #VARIABLES
// save measured time in var2 0x0010 // start @ address 0x10
operation_var16_var sub var6_32_LW low_duration ’L’ ’O’ ’W’ 32 ’p’ ’u’ ’l’ ’s’ ’e’ 32
// var6_32_LW -= low_duration ’d’ ’u’ ’r’ ’a’ ’t’ ’i’ ’o’ ’n’ ’=’ 0
comp_var16 var6_32_LW accuracy
// compare difference to the stored accuracy #VARIABLES
// CHECK whether the difference is greater than the 0x0050 // start @ address 0x50
// accuracy ’m’ ’u’ ’s’ ’t’ 32 ’v’ ’a’ ’l’ ’u’ ’e’ ’=’ 0
if_flags >
jump_rel_imm error_low #VARIABLES
0x0060 // start @ address 0x60
13 10 0 // new line
Similar instructions are used to measure the duration of
the high pulse. If the test has been successful, no jump has #VARIABLES

49
0x0070 // start @ address 0x70 which generally is a tedious task. It also eliminates human
’t’ ’i’ ’m’ ’e’ ’o’ ’u’ ’t’ ’!’ 0
error from the verification process, allows to conduct exams
#VARIABLES in a distance learning setting, i.e., at a remote location without
0x0080 // start @ address 0x80
’a’ ’c’ ’c’ ’u’ ’r’ ’a’ ’c’ ’y’ ’=’ ’+’ ’-’ 0 qualified supervisors on site, and scales to a large number of
students.
#VARIABLES
0x0090 // start @ address 0x80 These features are bought with the additional effort neces-
’u’ ’s’ 0 sary to generate automated tests. Here, exam programs reap the
’n’ ’o’ 32 ’r’ ’e’ ’s’ ’p’ ’o’ ’n’ ’s’ ’e’ ’!’ 0
highest benefit from the tool, since they tend to be fairly simple
// END OF TEST PROGRAM and thus the correctness tests are easily constructed. As a rule
In our test description, both automatic messages and texts of thumb, we estimate that the time it takes to write the test
defined by the test developer are returned via the serial for an exam task is approximately equal to the time it takes to
interface. The following list shows the resulting output on the set up the task description and program its solution. So doing
host PC in some important cases. automated tests roughly doubles the time required to set up the
exam. However, verifying a student solution by hand certainly
• No response within the predefined response time is rec-
ognized: takes at least ten times as long as doing it automatically, and
STARTING COMPLETE TEST this factor increases with increasing task complexity. Hence,
no response!
TEST FAILED!
even a moderate amount of students already makes automated
testing economic. Add to that the time-independent advantages
• The test is successful, the time properties of the measured of no room for errors, getting rid of a tedious labor, and the
signal meet the predefined expectations, the response time
meets the requirements as well: advantages for students, and we feel that automated tests are
STARTING COMPLETE TEST justified even for smaller student numbers like 15-20 students.
accuracy=+-5us
TEST OK!
Homework exercises pose more problems since they tend
to be more complex. Furthermore, homework is generally not
• The low pulse duration is not correct, considering the only about writing a correct program, but also about writing
predefined accuracy:
STARTING COMPLETE TEST a good (well-designed) program. Since the test system does
LOW pulse duration=249 only a black-box test, it cannot be used to verify whether the
must value=240
accuracy=+-5us student has employed special features of the target system, like
TEST FAILED! using the timer to automatically generate a PWM signal, and
• A timeout is reached while measuring the pulse width. it can of course not be used to evaluate higher-level issues
This can be the case when the pulse is too long or if the like programming style or efficiency. Still, it does free the
signal does not change at all: instructors from the rather tedious, uninteresting, and error-
STARTING COMPLETE TEST
timeout! prone task of checking the correctness of a large number
TEST FAILED! of programs and leaves more time to concentrate on high-
level issues like programming style. Furthermore, the test
This test description occupies 146 bytes of the memory of system allows students to remotely submit their homework
the test system. Additionally, 16 bytes are used for variables with instant feedback on the correctness, which will certainly
and constants, and 93 bytes contain the user-defined messages. be appreciated. So here it will certainly be worthwhile to
Of course, the tool is also capable of processing more investigate methods to generate test programs more easily, as
sophisticated tests. By using conditional instructions, logical we will elaborate in the next section.
operations, and timeouts, various types of state machines
could be implemented and therefore the complexity of the test As we have seen in the previous section, the result of a
scenario is only limited by the memory size. test is either that the test has completed successfully within
the given constraints, or that an error has occurred. It is the
V. D ISCUSSION responsibility of the test programmer to specify what output
The tool should facilitate program submission for both message the test system should print in case of errors, so
students and instructors: From the students’ point of view, the detailed information about the nature of the failure is possible.
tool allows them to submit (and thus check) their programs at Therefore, the test system can be used both for binary tests
any time and to get instant feedback. In the case of homework, (program works/failed) and for more fine-grained evaluation
this makes remote submissions with feedback possible. During and can thus also be used to assign partial credit (e.g., award
exams, students can check the correctness of their programs k% of the full points if the program has successfully passed
at any time, without the need to call and wait for a supervisor. k% of the test).
If the instructor desires, the tool can also give feedback on
the nature of problems in case of failed submissions, although VI. P OSSIBLE E XTENSIONS
such features should probably be used with care to prevent As one can already see from the example, the test system
students from employing a mindless trial-and-error strategy. is well capable of handling timing relations. However, setting
From the instructor’s point of view, the tool saves a lot of up the test description is currently done by implementing a
time otherwise spent on manually checking student programs, test program in the meta-language. Although not particularly

50
difficult, it is still time-consuming, so an obvious extension time and value domain against the program specification. The
of the system would be to provide a high-level translator that output of the system can be used both for simple binary
can directly take timing diagrams as input and translate them grading (passed/failed), but also for assigning partial credit
into an appropriate test description. Such a tool would greatly for partial functionality.
facilitate the design of test descriptions. Of course, in case of a
The tool will allow us to increase the cost efficiency of
failed test, the system should still be able to tell the user which
our teaching activities, since faculty staff is relieved from the
part of the test failed. But since we only check the timing of
monotonous task of correcting more than hundred program
signals, it should be relatively easy to automatically generate
examples per exam. Additionally, the system enables us to
test cases for all errors that can occur during a test.
increase the number of students and to devise courses where
As we have mentioned, the test system is intended for exams can be held at other locations than our own university.
checking both exam programs and homework programs. Exam Students benefit from the tool as well, since they can submit
programs tend to be relatively simple, so the current memory their programs anytime and from any location, can expect fast
space is more than sufficient for our purposes. If more complex and correct verification of their programs, and can also get
homework is tested, however, it might be necessary to extend feedback in case of errors. Therefore we are planning to try
the test system’s SRAM. To allow completely automatic test- out this system in our next year’s microcontroller laboratory
ing of diverse programs, we should also add some multiplexers course, and in the long run intend to employ the tool in all
for the analog pins to our target hardware. undergraduate courses on embedded systems.
It might sometimes be interesting not only to test the The system is currently available as a prototype. We are
external signals, but also to verify internal information like reg- now working on enhancements of the basic functionality, most
ister initializations of the target microcontroller. This can for notably on a good and easy to use interface for developing test
example be useful to check whether a student has programmed descriptions.
the PWM generator of the target microcontroller as demanded
R EFERENCES
in the exercise task, or is simply using a manually tuned
busy-wait loop to achieve the same effect. If such additional [1] W. Wolf and J. Madsen, “Embedded systems education for the future,”
Proceedings of the IEEE, vol. 88, no. 1, pp. 23–30, Jan. 2000.
checks are desired, the course instructor has to provide some [2] M. W. Mutka and A. Bakic, “Teaching undergraduate computer science
additional (target-dependent) code which is linked to the and engineering students techniques for the design and analysis of real-
student code and which verifies register initializations. This time applications,” in 28th Annual Frontiers in Education Conference,
vol. 3, Nov. 4–7, 1998, pp. 1079–1084.
code could then use some free pins of the target system to [3] B. Haberman and M. Trakhtenbrot, “An undergraduate program in
communicate its results to our test system, which could in embedded systems engineering,” in 18th Conference on Software En-
turn incorporate this additional information into its tests. No gineering Education and Training), Apr.18–20, 2005, pp. 103–110.
[4] J. Sztipanovits, G. Biswas, K. Frampton, A. Gokhale, L. Howard,
change in the test system is required to use such additional G. Karsai, T. J. Koo, X. Koutsoukos, and D. Schmidt, “Introducing
data provided by the target. embedded software and systems education and advanced learning tech-
nology in engineering curriculum,” ACM Transactions of Embedded
Of course, the meta-language can still be enhanced by Computing Systems, Special Issue on Education, 2005.
adding complementary functionality to some instructions. For [5] A. Benso, P. L. Civera, M. Rebaudengo, and M. S. Reorda, “A low-cost
programmable board for speeding-up fault injection in microprocessor-
example, the duty cycle of a digital signal could be measured based systems,” in Annual Reliability and Maintainability Symposium
in one instruction and thus one would not have to measure (RAMS’99), 1999, pp. 171–177.
the positive and negative pulse durations separately. Or, we [6] A. Sung and B. Choi, “An interaction testing technique between hard-
ware and software in embedded systems,” in 9th Asia Pacific Software
could add some special types of comparison instructions which Engineering Conference (APSEC’02), 2002, pp. 457–464.
already compare with a certain accuracy. This would be useful [7] W.-T. Tsai, Y. Na, R. J. Paul, F. Lu, and A. Saimi, “Adaptive scenario-
when determining whether a measured time or an analog value based object-oriented test frameworks for testing embedded systems,” in
26th International Computer Software and Applications Conference on
is in the required interval. Prolonging Software Life: Development and Redevelopment, 2002, pp.
321–326.
VII. C ONCLUSION AND F UTURE W ORK [8] A. Fin, F. Fummi, M. Martignano, and M. Signoretto, “SystemC: A
The test system described in this paper is intended to homogenous environment to test embedded systems,” in International
Conference on Hardware Software Codesign, 2001, pp. 17–22.
automatically check undergraduate student exam programs [9] H. J. Zainzinger, “Testing embedded systems by using a C++ script
and homework exercises in the area of embedded systems interpreter,” in 11th Asian Test Symposium (ATS’02), 2002, pp. 380–
programming for correctness, that is, in compliance with a 385.
[10] J. D. Lofgren, “A generic test and maintenance node for embedded
given specification. To this aim, we do a black-box test on the system test,” in IEEE International Test Conference on TEST: The Next
I/O pins of the target system, for example a microcontroller. 25 Years, 1994, pp. 143–153.
We provide the microcontroller with stimuli, thus simulating [11] V. Legourski, “Test system for embedded software,” Bachelor Thesis,
Vienna University of Technology, Institute of Computer Engineering,
the behavior of hardware input elements like switches, and 2005.
check the output responses of the microcontroller in both

51
 Experiences Teaching an FPGA-based
Embedded Systems Class
Stephen A. Edwards
Department of Computer Science
Columbia University
New York, NY 10027
Email: [email protected]

Abstract— I describe a two-year-old embedded systems design

course I teach at Columbia University. In it, the students
learn low-level C programming and VHDL coding to design
and implement a project of their own choosing. The students
implement their projects using Xilinx FPGAs and tools running
on Linux workstations.
The main challenges the students face are understanding and
complying with complex and often poorly-documented interfaces
and protocols, personal time management, and teamwork. While
all real-world challenges, this class is often the first time the
students encounter them, which makes the class quite challenging,
but very practical.
In this paper, I describe the structure of the class, the
configuration of our teaching laboratory, some of the more
successful projects, and give suggestions to instructors wishing
to implement the class elsewhere. (a) (b)
Fig. 1. The two boards used in different incarnations of the class. (a) The
I. I NTRODUCTION XESS XSB–300E board, centered around a Xilinx Spartan IIE (XC2S300E).
(b) The Digilent Spartan 3 Starter Kit board, centered around a Xilinx Spartan
Embedded system design is a challenging problem that III (XC3S400).
represents the future of digital system design. Moore’s law and
the relentless downward-spiraling cost of integrated circuits
has made it possible to price very powerful computing artifacts The class focuses on the design of a fairly complex hard-
at consumer levels, as the ubiquity of devices such as DVD ware/software system, which the students implement on an
players, digital cameras, and cell phones attest. FPGA board. This is consistent with the role of the course as
We in academia must follow this trend. As recently as fifteen a “capstone lab” in the Columbia Electrical Engineering and
years ago, wire-wrapping TTL parts was a sufficient intro- Computer Engineering programs. As I describe below, the first
duction to state-of-the-art system design techniques; today’s half of the class consists of cookbook-style lab assignments
systems are orders of magnitude more complex. Teaching that teach the students the design tools. The second half of the
students to handle this complexity is the central challenge. class is devoted to the project.
In this paper, I describe an FPGA-based embedded systems As of September 2005, I have taught the class three
course I developed and teach at Columbia University. Follow- times: twice at Columbia, and once at National Chaio Tung
ing the suggestion of Frank Vahid, whose book [1] I used for University (NCTU) in Hsinchu, Taiwan. At Columbia, the
the first year, I created this course to replace a microprocessor majority of students are fourth-year undergraduates completing
system design course that until 2003, had students assemble an Electrical Engineering or Computer Engineering degree.
systems using Z80-based trainers with breadboards1 . The Taiwan group consisted of sixteen students, most of whom
I wanted the students to learn hardware/software codesign, were Master’s-level, and many of whom had worked or were
specifically the design of microprocessor systems and their working full-time in the electronics industry.
peripherals. Students taking the course have experience with
Java and C, know basic digital design, and have taken com- II. H ARDWARE
puter organization, which should have familiarized them with Just as embedded hardware/software systems can take many
assembly language, but few have any experience integrating forms, there are many possible vehicles for teaching a practical
these skills. embedded systems class. At one point, I considered having the
students only build simulations, a practical approach used in
Edwards is supported by an NSF CAREER award, an award from the SRC,
and by New York State’s NYSTAR program. computer architecture courses, but I wanted the students to
1 To emphasize their antiquity, these trainers were labeled “Copyright 1985.” experience real hardware.

52
 2004 2005
Count in decimal on 7-segment LEDs C Count in decimal on 7-segment LEDs C
Display “Hello world” using framebuffer C Terminal emulator using supplied video controller C
TV typewriter C Reverse-engineer some VHDL drawings
Count in hex on 7-segment LEDs VHDL Sum the contents of a memory VHDL
Make framebuffer display characters VHDL Complex multiplier as OPB peripheral VHDL
TV typewriter using character display C & VHDL SRAM controller for OPB (omitted at NCTU) C & VHDL
Fig. 2. The six lab assignments.

One standard approach is to use a microprocessor devel- and ideas it contains are good, but the students do not find it
opment board. Frank Vahid has taken this approach with terribly relevant to the project construction task.
his course at University of California, Riverside [1], using Many texts are software-centric. Wolf [2], for example, dis-
the 8051. While this is a practical option, it tends to lead cusses things such as the ARM instruction set and operating-
to software-centric thinking that does not consider hard- system-level concepts such as processes. Simon [3] is even
ware/software trade-offs. more focused on software, although a bit more practical than
Modern field-programmable gate arrays (FPGAs) offer Wolf. Heath [4] is similar. Brown [5] has a more industrial
many advantages for instruction, including flexibility, fast focus and includes a large avionics example.
reprogrammability, and the capacity to implement large, fast Many books are specific to a particular processor. Although
digital designs. The two leading FPGA companies—Xilinx practical, I find such an approach focuses too much on the
and Altera—offer comparable technology. Xilinx, however, idiosyncrasies of a particular instruction set. Books in this
appears to have the superior university program, so I decided vein include Morton [6], which focuses on the Motorola
to use Xilinx FPGAs for this course. 68HC11 series of microcontrollers. Lewis [7] targets the x86
Many FPGA development boards are available, but most architecture and ordinary PCs, which makes acquiring suitable
are designed for industrial use (and budgets) and can cost as hardware easy: most departments have a collection of old
much as US $5000 per board—beyond our price range. PCs that make suitable embedded targets. Barr [8] chooses an
At Columbia, my TA and I selected a board built by 80188-based board, although focuses mostly on C and C++.
XESS Corporation: the XSB–300E (Figure 1a), which sells for Pont’s book [9] should have been titled Embedded C on the
about $900. Centered around a Xilinx Spartan IIE FPGA—the 8051. Peatman [10], by contrast, makes it clear that he focuses
XC2S300E—with a raw capacity of roughly 300k gates, the on the PIC18F452 processor. Incidentally, is is the only book
board also has a wide variety of peripheral chips, including I know of that comes with a (bare) PC board.
video input and output; Ethernet; USB 2.0; a serial port; There is another family of texts that are more concept-
SRAM, DRAM, and flash memory; and an audio CODEC. The oriented and targeted at graduate students. These are even more
peripherals were particularly attractive; using these peripherals abstract that Vahid and Givargis and would probably frustrate
would be a focus of the projects. my students. Examples include Gajski et al. [11], Jantsch [12],
In Taiwan, we used a newer, smaller board made by Marwedel [13], and the volume edited by Jerraya et al [14].
Digilent (the Spartan 3 starter kit board, Figure 1b). This was Noergaard’s sprawling volume [15] tries to discuss just
satisfactory, especially given its $120 price, but greatly limited about everything, ranging from the difference between
the range of projects as its peripherals are limited to an 8-color enhancement- and depletion-mode MOSFETs to HTTP meth-
VGA port, a PS/2 keyboard interface, and an RS-232 port. This ods. While a very interesting reference, it is too long to
particular board comes in a few different configurations. The consider in its entirety in a single semester.
most common has an XC3S200 part, but this is too small to
IV. L AB A SSIGNMENTS
accommodate the Microblaze soft processor core, which every
project has used. Instead, we paid a bit more and got boards As I mentioned above, I divide the class into two: during
with the larger XC3S400 part. the first half, the students follow cookbook lab assignments
meant to teach them how to use the design tools. During the
III. T EXTBOOKS second half, they design and implement projects of their own
devising.
I have not found a satisfactory text for the class. In the Figure 2 lists the six labs I have given over the last two
first year, I used Vahid and Givargis [1], partially because years and the main language they need to use in each. The
Vahid had originally suggested the idea of the class to me and goal of these labs was to get the students familiar with using
because the text embodies the philosophy of functions being the tools through a sort of tutorial style. I provided detailed
implementable in either hardware or software. But the students explanations of what to do as well as collections of files as a
and I found the book disappointing. It deliberately shies away starting point. The results were mixed.
from talking about any particular languages or platforms, mak- In the spring of 2004, I made the mistake of trying to
ing it useless as reference manual. The background material balance software and hardware labs, making half of them

53
 ✂✁✄✄✁✄✄✁✂✄✁✄✄✁✄✂✁✄✄✁✄✄✁✂✄✁✄✄✁✄✂✁✄✄✁✄✄✁
Dout Clk
Char.
Din RAM Controller
VSYNC
☎✆☎✆☎✝☎✆✞✄☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆✞✄☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎
✄✠✆✠✝✁ ✄✠✆✠✝✁
CharAddr i−1 i i+1

HSYNC
LoadChar ✟✆✟✆✟✝✟ ✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟ ✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟
Addr 2.5K

CharData ☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝✞✄☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝✞✂☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎

BLANK
Load/Shift
✄✠✆✠✆✁ ✂✠✝✠✆✁
i−1 i i+1

FontLoad ✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟ ✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟ ✟✆✟✝✟✆✟✝✟✆✟

Font
RAM
1.5K PixelData ☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆✞✄☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆☎✝☎✆☎✆☎✝☎✆✞✄☎✆☎✝☎✆☎✝☎✆☎
✄✠✝✠✆✁ ✄✠✆✠✝✁
i−1 i i+1

Load/Shift ✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟ ✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟✆✟✝✟✆✟✆✟✝✟ ✟✆✟

Video

Shift Register Bit ✞✂☎✝☎✆✞✄☎✆☎✝✞✄☎✆☎✆✞✄☎✝☎✆✞✄☎✆☎✝✞✂☎✝☎✆✞✄☎✆☎✝✞✄☎✆☎✆✞✄☎✝☎✆✞✄☎✆☎✝✞✂☎✝☎✆✞✄☎✆☎✝✞✄☎✆☎

3 2 1 0 7 6 5 4 3 2 1 0 7

Fig. 3. A block diagram of a text-mode video controller. I describe the Fig. 4. A detailed timing diagram for the text-mode video controller. I teach
design of this peripheral in great detail to introduce the students to the design the students such timing diagrams are crucial for designing functioning digital
process. hardware.

software-dominated; the rest hardware. While this does reflect the bus protocol spoken by the Microblaze soft processor (i.e.,
the class focus I had in mind, it was not well-matched to the the OPB protocol) or the protocol spoken by the audio codec.
students’ backgrounds, which were heavily software-centric. I To try to address this, the three hardware labs in 2005 were
found myself teaching experienced programmers who were protocol-centric. The first was fairly easy: building a controller
able to complete the first three labs with almost no effort that would sum the contents of a small on-chip memory.
at all. But digital design with VHDL stumped them: they Students had to understand the (very simple) interface to
did not have any real experience designing digital circuits, the memory, design a simple data path with controlling state
despite having taken a beginning digital design class. They machine, and understand how to use the VHDL simulator.
were also flummoxed by the odd syntax of VHDL. Many of The second hardware lab involved interfacing with the OPB.
them resorted to trying to write VHDL as if it were C. I had students design and implement a simple memory-mapped
In the spring of 2005, I made the labs more hardware- peripheral that performed complex multiplication. We supplied
centric. Again, the first two gave the students experience in the students with a combinational (one-cycle) 8 × 8 multiplier
low-level C programming and some experience with the tools, and asked them to construct a simple data path and controller
but the rest of the labs were mostly about design with VHDL. that used the multiplier four times to compute the product of
Most students, when introduced to synthesizable VHDL, two complex numbers.
treat is as a programming language, but it is more a textual The final hardware lab was the most complicated, although
form of coding schematics and state machines. VHDL “state- still far from what the students would have to do while
ments” such as if-then-else and assignments are deceptive: implementing their projects: an interface for an off-chip static
they only provide a way of decomposing a function and do not RAM part. This is a typical problem: interfacing one protocol
behave like the imperative versions the students are familiar with another—in this case, the protocol of the OPB and the
with. To try to help them avoid this error, I tried to emphasize protocol of the static RAM. To keep things simple, I had them
a particular design methodology. only map half of each 32-bit processor word to match the 16-
Two concepts distinguish hardware from software: structure bit width of the SRAM chip. This would allow them to store
and timing. While software has structure in the form of data in the memory, but not execute code from it since the
functions and classes, the structure in hardware is at a block- processor needs all 32 bits.
diagram level, reflecting its concurrent nature. Similarly, the These labs definitely worked better in the second year,
software programming style is to ignore performance concerns but there remains room for improvement. While all groups
until absolutely necessary and only concentrate on functional- managed to complete the labs successfully, many seemed to
ity, a technique that does not work in hardware. As a result, I forget the lessons they taught when doing the project. I often
teach the students a three-step hardware design process: draw found myself answering questions with “we did that in lab
a block diagram, such as the one for the text-mode video four,” which was disappointing. Furthermore, it remains the
controller in Figure 3, draw a timing diagram (e.g., Figure 4), case that the students need more practice at hardware design
and then code it in VHDL. To get them started, the third lab and debugging the mess they have created.
in 2005 had them do this in reverse: we provided them with At Columbia, the course spans a normal fourteen-week
a clearly written VHDL description and asked them to draw semester; in Taiwan, it was condensed to a single month in
the block diagram and a timing diagram for it. which the class met daily. To accommodate the tight schedule,
The biggest challenge the students faced while doing the I omitted the sixth lab assignment and scaled down the scope
projects in 2004 was dealing with existing protocols such as of the projects.

54
 V. T HE P ROJECT A. Video Projects
In my experience, students prefer working on projects of I am a fan of video-centric projects, having built some as an
their own devising rather than what I could supply. As an undergraduate. They have certain advantages: they are visually
example, when I taught the compilers class at Columbia for satisfying when they work; they can often be debugged by
the first time, I had the students implement the Tiger language inspecting the displayed image; they have substantial, but
from Appel’s Modern Compilers book, and the students hated not insurmountable, real-time requirements; and VGA-style
it. The next year, I had the students design and implement video signals are a simple protocol whose central idea (a
a language of their own devising—a much more difficult raster image) is fundamental. To support video development,
procedure, but the students clearly enjoyed it far more. each workstation in our lab has two flat-panel displays: one
For the projects, I break the class up into groups of between connected to a Linux workstation; the other connected to the
two and six students. A size of three seems optimal—any XSB–300E board and its video DAC.
smaller and the project becomes too simple, any larger and the Video games Simple video games make for excellent
group starts to lose its cohesion and ability to communicate. projects. Students have implemented games inspired by Pac-
Overall, about 80% of groups have completed the project, man, Scorched Earth, and a 3D maze game. For the Pac-man-
meaning they have something working at the end that closely like maze game, students designed and implemented a custom
resembles what they set out to do. The remaining 20% have video generator capable of drawing sprites over a character
difficulties with group dynamics (e.g., the members hate each display, much like the original Namco arcade game. The
other), technical difficulties (one group spent their time trying game logic, implemented in C, was primitive, but I was more
to communicate with the USB controller, to no avail), or are concerned with their implementation of the custom hardware
just incompetent. The good students at Columbia are excellent; and the hardware/software interface.
the bad students are awful. Scorched Earth is an artillery game in which players take
I ask the project groups for four deliverables: a two- turns lobbing shells at their opponents’ tanks over a 2D
paragraph project proposal, a project design document, a terrain. The students implemented custom graphics hardware
demonstration on “75% day,” and the final demonstration that superimposed sprites for the tanks and shells over a
and report. Such deadlines are absolutely necessary to keep terrain generator (each column has a height that corresponds
the students moving as otherwise they would work on other to the line at which the sky ends and the ground begins) and
classes’ shorter deadlines. Even so, four deadlines seems like a character generator for displaying the current score, gun
it may not be enough; I plan to add a “50% day” next year. inclination, and so forth. Again, the game logic was simple but
I expect a resonable project to incorporate both software successful. This project was the star of 2005; most students
(C) and custom hardware (VHDL) and interface with at least wanted to play it.
one of the on-board (but off-chip) peripherals on the XESS One group implemented a 3D maze game. I had them create
board. Interfacing with one of the peripherals is relatively a custom video controller that contained two numbers for each
straightforward, but using two or more is difficult because of X coordinate: one that corresponded to the line at which the
the odd shared bus structure of the XSB–300E board, which sky begins and the wall starts; the other that holds the line at
connects all of the peripherals to a common set of pins on which the wall ends and the floor begins. The students used
the FPGA. Thus, to communicate with multiple peripherals, a primitive raycasting technique to determine these numbers:
the students must build a controller that behaves differently from the player’s position, they sent out a ray that goes until
depending on the peripheral being accessed (each has very it hits a wall. The distance the ray travels indicates the size
different timing requirements), yet does so through a common of the wall at that column (more precisely, it is the reciprocal
set of pins. Without question, this is one of the most awkward of the distance). The students found it challenging to do this
aspects of the XSB–300E board. calculation using fixed-point arithmetic (the Microblaze does
Students usually start by proposing overly ambitious not have a hardware floating-point unit), but were ultimately
projects (at least in the US—the Taiwanese students were able to achieve nearly a 20 fps frame rate.
much more realistic, but this may have been because many Since we used the simpler Digilent Spartan 3 Starter Kit
were professionals). My teaching assistants and I have had to Board (Figure 1b) at NCTU in Taiwan, the range of projects
curtail countless proposals that incorporate MPEG encoding, the students could build was greatly restricted. I suggested
a complete TCP/IP implementation, or other systems that are they build simple video games and most groups did.
orders of magnitude more difficult than beginning students Chess Rather than spend time on the algorithm for
could realistically implement in half a term. playing chess, this group built a two-player chess game that
Below, I describe the majority of the successful projects could display the chessboard, let a player select a piece to
students have completed over the last two years. Broadly, they move, show where it could be moved, and move it. They
fall into four classes: video, audio, networking, and “other.” even implemented such complicated rules as pawn promotion
The majority of projects focus on one of these areas, but some and castling. As with most of the NCTU projects, this group
of the more ambitious and successful projects incorporate, say, adapted the video display code I provided (based on Figures 3
both video and networking. and 4) to display the board and pieces.

55
 The four other NCTU video game projects were Tetris, One group implemented a stereo depth extractor using the
Sokoban, a scrolling maze game loosely patterned on the video decoding capabilities of the XSB–300E board. They
Namco game Rally-X, and a two-player snake game. Each pointed a video camera at a mirror nearly parallel to the
group modified the text-mode video controller code I had centerline of the camera to generate a split image from two
provided, adding color and changing the size of the characters. slightly different vantage points. They then looked for the two
Video Effects Processor Modern FPGAs have enough pro- brightest spots on the image and used the difference in their
cessing power to perform limited real-time image processing. location to compute the 3D location of the spot. To test this,
One group put this to use by building a framebuffer with they placed the camera in a black cardboard box and shined a
the ability to distort its output. Rather than simply reading laser pointer at a movable target. Although clearly not at the
the contents of memory in sequence for adjacent pixels, they cutting edge of computer vision, the group was able to get
added the ability to change the starting point and memory interesting results.
stride for each line. Such a set-up was able to transform, say, a Robot with Vision Perhaps the most unique project to
rectangular picture into a triangular one, and be able to modify date, this incorporated the XSB–300E board as the controller
this distortion on-the-fly. The group had originally intended to for a mobile robot built using Lego Mindstorms. In the end
perform this distortion on real-time video (the XSB–300E has able to follow a black line drawn on a white piece of paper,
a Philips video decoder chip), but ran out of time and only the most unique aspect of this project was the successful use
displayed the static contents of memory. of video as vision. The group mounted a small video camera
Digital Picture Frame This project, which was unsuccess- to the Mindstorms robot and fed the input to the XSB–300E
ful in 2005, decodes JPEG images and displays them on the board. The board decoded the video, posterize it to one bit
screen. The easiest way is to perform most of the computation per pixel, divided the image into nine rectangular regions, and
in software and only use hardware for the framebuffer. The used the relative number of black pixels in each region to
XSB board includes a Compact Flash interface (a parallel bus decide whether to turn left, right, or to go straight.
protocol), so in theory it would be possible to read and display Software running on the Microblaze analyzed the heavily
files from a digital camera, but no group has been successful decimated video input signal and transmitted simple com-
at being able to read from a CF card. mands through a serial port to an IR tower and the robot itself,
One group attempted to port the independent JPEG library whose controller was running a very simple program that took
onto the Microblaze in the process of performing this project, simple direction commands.
but ran into serious size and complexity problems. In the
future, I will advise any group that undertakes this project to B. Audio Projects
write their JPEG decoding code from scratch and not worry
about making it support all JPEG variants. There is also an Like video projects, audio projects engage the senses and
obvious opportunity for hardware acceleration (i.e., the inner therefore share some of the thrills of success and easy debug-
loop of the DCT). ging of video projects. Compared to video, however, audio is
Another group, this one in Taiwan, also attempted the digital nearly three orders of magnitude slower and one-dimensional,
picture frame project, this time with greater success. First, they making it much easier to manipulate and presenting many
implemented a frame buffer that used external SRAM (there more opportunities for elaborate signal processing.
is only 32K of on-chip block RAM on the XC3S400 used on The audio CODEC on the XSB–300E (an AKM AK4565:
the Digilent board) and had to grapple with the usual problem 50 kHz, 20 bits/sample, stereo) has a synchronous serial inter-
of simultaneous access from both the video system and the face with a fairly simple protocol, although its configuration
processor. They took the simplest route and added a mode bit protocol, which goes through a separate synchronous serial
that would blank the display and enable to processor to access interface that is, unfortunately, connected to the low-order data
it. Next, they took a small JPEG library written by Pierre bits on the XSB–300E peripheral bus, was difficult for most
Guerrier2 and made it compile on the Microblaze. Finally, they of the students.
added a mechanism for copying data from the RS232 port into MIDI Synthesizer One of the most successful projects
memory in preparation for decompressing and displaying it. of 2004, a MIDI synthesizer leads to a nice combination of
Unfortunately, little of this worked completely at the end of hardware and software. While it would be possible to perform
the class. The JPEG library, for example, just barely fit in the the sound synthesis in software, its real-time requirements
16K of on-chip memory they were using. are sufficiently demanding and its computational complexity
Video Input Projects These are quite a bit more challeng- makes it simple enough to do in hardware. This group im-
ing than video generation projects. First of all, the video DAC plemented both the standard FM synthesis algorithm and the
is a much simpler chip than the Philips SAA7114H video Karplus-Strong plucked instrument algorithm. Both sounded
decoder, which has a 140-page manual. Second, it is much remarkably good.
easier to generate a signal than to understand one, especially MIDI is an asynchronous serial protocol like RS-232, but
when it comes from the real-world. at an unusual bit rate and generally transmitted through a
current-loop designed to be terminated with an optoisolator to
2 Their source was http://www.es.ele.tue.nl/˜mininoc/c prog/djpeg orig/ avoid noise. The group built a simple MIDI-to-RS-232 level

56
converter and used the soft UART core supplied by Xilinx to listen to the iPod through the speakers on the Linux-based
receive the protocol. workstation running a standard mplayer program. Like the
The MIDI protocol consists mostly of note-on and note-off Internet camera project, this one went to pains to speak
messages. While fairly simple, managing polyphony with a many standard protocols and ultimately made something very
finite number of oscillators is much easier to do in software, complicated look simple.
which the group did. Thus, the MIDI protocol was decoded A similar project took on an even more complex protocol:
in software and the synthesis was done in hardware. SIP. Designed for Internet telephony, SIP is a standard protocol
Sound Effects Synthesizers FPGAs now have more than for establishing Voice-over-IP telephone calls. I was amazed
enough processing power to perform fairly complex audio- when this group was able to hook up the board to the
band signal processing. At least two groups have taken advan- campus Ethernet network and make a friend’s VoIP phone ring.
tage of this by implementing various sound effect generators. The final result was a little disappointing—the audio quality
One, for example, was designed to implement various effects, was poor, which I attributed to some sloppy programming
such as phasing and distortion, that worked well with input somewhere—but overall the project was a success.
from an electric guitar. The algorithms for such filters are fairly
straightforward; the groups implemented them in hardware and D. Unique Projects
placed their parameters under software control. All the projects I described above used the XSB–300E board
Audio Spectrum Analyzer I was a little surprised by the and its FPGA at the center. By design, in this class I have not
speed of the FPGA for this project: one group implemented focused on the electrical and physical challenges of embedded
a real-time 1024-point FFT running at audio speeds. The system design, but a number of groups decided to tackle these
majority of the algorithm was in software; they only used problems, too. The result has been a largely successful group
hardware to accelerate complex multiplication. Coupled with of unique projects.
a nifty graphic equalizer-like display, this was an impressive Automotive Projects Columbia participates in the Soci-
project. ety of Automotive Engineers’ Formula SAE competition, in
Pitch Detection Detecting the fundamental pitch of an which student groups design, fabricate, and race small cars
audio signal, such as a voice, is a fairly interesting prob- built around motorcycle engines. While largely targeted at
lem with applications to singer training. Two groups have mechanical and automotive engineers, two groups in my class
attempted projects along these lines, with varying results. One have done projects related to this effort.
group did the obvious and performed an FFT on audio input The first, in 2004, built a vehicle telemetry system that
samples, but found that the linear bin arrangement of the FFT gathered data from various sensors on the car (e.g., tachometer,
made for rather imprecise measurement at low frequencies. oil pressure) and sent it through a wireless link. The group
Another group attempted to implement an algorithm based on purchased the wireless transmitters and receivers, but built
autocorrelation and got so far as to built a prototype in Matlab, a small processor system on the car centered around a PIC
but did not complete the project because of group dynamics. microcontroller. This was a particularly challenging project
for this class because it involved a number of analog signal
C. Networking Projects conditioning circuits. While ultimately mostly successful, the
The XSB–300E contains an NE2000-compatible Ethernet group did have the problem of relying on the car itself—which
chip, and a number of projects have used it for network was often unable to start—to demonstrate their project.
communication. By sheer numbers, students seem to prefer The 2005 group built a digital dashboard and controller for
audio and video projects, but the successful network projects an automatic shifter. They worked with a pair of mechanical
have been quite impressive. engineers who designed the mount and levers for a large
Internet Camera This project, which combined video (25A) solenoid that moved the mechanical gear shift lever
and networking components, spoke the most protocols of any (the gears on this motorcycle engine could be selected by
project to date. The students used the Philips video decoder moving a lever—designed to be operated by foot—up and
chip to sample real-time video, decimate its resolution and down). The group also built a dashboard with LEDs displaying
frame rate, packetize it, and send it as UDP packets over engine RPMs, the current gear, and a suggestion about whether
Ethernet. On the receiving end—a standard Apple laptop—a to shift up or down. As is typical of beginning electrical
simple Java program of their own devising received the packets engineering students, their fabrication skills were lacking,
and displayed them. I joked that the project amounted to a very resulting in a tangled mess of wires and cold solder joints,
expensive wire, but it was actually one of the most technically exactly the sort of problems using an exclusively FPGA-based
challenging projects that exemplified good engineering: it approach avoids. Alas, this group, too, was stymied by the
made something quite complicated look effortless. engine not starting when they tried to demonstrate it to me,
Internet Audio In 2005, two groups built projects that although it had been working earlier.
communicated audio over the Internet. One built an Internet Scrabble Timer When the class started, an inventor hap-
radio broadcaster that took audio in through the CODEC, pened to approach me about building a prototype of a timer,
packetized it, and sent it out via RTP. They connected an much like a chess timer, for the game of Scrabble—he had
iPod and an Ethernet cable to the board and were able to aims of selling the design to a large board game manufacturer.

57
 Question 2004 2005 VII. C ONCLUSIONS
Amount Learned (out of five) 3.72 4.04
The embedded systems class I have described remains a
Appropriateness of Workload 3.33 3.64
work-in-progress, but has been fairly successful. The word-of-
Overall Quality 3.74 3.89
mouth among students has been excellent, to the point where
it has clearly siphoned off students from other, competing
Selected comments from 2005:
classes. An informal poll suggests students prefer the mix of
“Tough class but learned a great deal. Recommended.” hardware and software and the ability to choose their projects.
“I’d like to see a lecture that goes into more detail about the way I have put all the class materials on the web, includ-
that the various files definitions and programs are used to create ing all slides, handouts, lab assignments, lab template files,
the hardware. We end up learning it in pieces but a more detailed and students’ project files and reports. All can be found at
overview would be useful since the tools are a key component of
understanding this class.” http://www.cs.columbia.edu/˜sedwards/classes.html.
I have not been able to address to my satisfaction the
“The lectures didn’t seem to serve as much help for the assignments balance between practical knowledge and fundamental un-
and project.” derstanding. There is a plethora of practical knowledge the
Fig. 5. Course evaluation results for the Columbia classes. Numbers are students need to be able to execute their projects, ranging from
averages, with 0=poor and 5=excellent. VHDL coding styles to how to get the Xilinx tools to work,
but I feel the class is overly demanding of knowledge of such
trivia. Frustratingly, the students actively complain that I spend
I figured it would make a good project for the embedded too little time lecturing about such details. While this is very
systems class and it did. A group worked closely with the realistic and class is meant to be a capstone class in which
inventor, who had a clear idea of the behavior he wanted students bring together the knowledge they have gained during
(he came to me with a multi-page document describing how their careers as undergraduates, it still frustrates me that I feel
it should work) but did not have the skills to implement they are learning trivia that will be out-of-date in a year.
it. This arrangement worked perfectly—the students got the The more fundamental ideas I see in practical embedded
opportunity to work for a client and in return were given very system design—the balance between top-down and bottom-
precise requirements and a helpful client. up design necessary to build high-performance systems, the
Like the automotive groups, this group built a system ability to debug, the ability to seek and find the information
centered around a PIC microcontroller. Its interfaces were you need, and the ability to understand and reverse-engineer
simple: a collection of buttons numerous enough to require poorly-written documentation—are subtle, difficult to convey,
multiplexing and 4 line × 40 character LCD display module. and not the sort of thing you can easily ask on a test. My
While a very simple design, the quality of the software and hope is that these more subtle ideas will enter in the students’
attention to detail (the group put their project in an attractive thinking during the process of implementing these complex
box and spend a lot of time thinking carefully about the projects, because it is unlikely they will learn them from a
arrangement of buttons) made this project a stand-out. lecture or a book.
All three of the groups that used PIC microcontrollers got
little instruction from me. I do not discuss microcontroller R EFERENCES
programming in class, but the students were able to glean the [1] F. Vahid and T. G. Givargis, Embedded System Design: A Unified
Hardware/Software Introduction. New York: John Wiley & Sons, 2001.
information they needed from tutorials and web references. [2] W. Wolf, Computers as Components: Principles of Embedded Computer
The students who have worked on such independent projects, Systems Design. San Francisco, California: Morgan Kaufmann, 2000.
not surprisingly, have been among the best in the class. [3] D. E. Simon, An Embedded Software Primer. Reading, Massachusetts:
Addison-Wesley, 1999.
VI. E VALUATION [4] S. Heath, Embedded Systems Design. Oxford: Newnes, 1997.
[5] J. F. Brown, Embedded Systems Programming in C and Assembly. New
As with all Columbia classes, students were asked to fill out York, New York: Van Nostrand Reinhold, 1994.
a standard course evaluation form. The results are summarized [6] T. D. Morton, Embedded Microcontrollers. Prentice Hall, 2001.
[7] D. W. Lewis, Fundamentals of Embedded Software. Prentice Hall,
in Figure 5. While the results are positive overall, and the 2002.
ratings improved uniformly in the second year, the main [8] M. Barr, Programming Embedded Systems in C and C++. Sebastopol,
negative complaints were that the course required a lot of California: O’Reilly & Associates, Inc., 1999.
[9] M. J. Pont, Embedded C. Addison-Wesley, 2002.
work (which is certainly true) and that my lectures were not [10] J. B. Peatman, Embedded Design with the PIC18F452 Microcontroller.
that relevant to the labs and project. Specifically, they wanted Prentice Hall, 2003.
much more instruction on how to use the CAD tools, which [11] D. D. Gajski, F. Vahid, S. Narayan, and J. Gong, Specification and
Design of Embedded Systems. Prentice Hall, 1994.
are very complicated. I had attempted to address this issue [12] A. Jantsch, Modeling Embedded Systems and SOC’s. Morgan Kauf-
through detailed lab writeups, which described the operation mann, 2004.
of the tools in detail, but some students obviously prefer to be [13] P. Marwedel, Embedded System Design. Kluwer, 2003.
[14] A. A. Jerraya, S. Yoo, D. Verkest, and N. Wehn, Eds., Embedded
shown something. Software for SoC. Kluwer, 2003.
[15] T. Noergaard, Embedded Systems Architecture: A Comprehensive Guide
for Engineers and Programmers. Newnes (Elsevier), 2005.

58
 An Evaluation of the VME Architecture for Use
in Embedded Systems Education
Kenneth G. Ricks, David J. Jackson, and William A. Stapleton

 applications;
Abstract— The VMEbus is an IEEE standard architecture x There are many different technologies used in
upon which many embedded and real-time systems are built. It embedded systems;
has existed for nearly 25 years and has been extensively used for
x There is a wide range of design constraints
military, industrial, and aerospace applications. This paper
describes the general characteristics of the VMEbus architecture, imposed on embedded systems; and
specifically relating these characteristics to aspects of embedded x There are many different embedded systems
systems education included as components of the IEEE/ACM architectures and platforms in use today.
CE2004 computer engineering model curriculum. Portions of
this model curriculum are currently being implemented at Because of these characteristics, embedded systems
universities across the country as part of an increasing effort to
address the need for embedded systems education. This
education is fragmented and customized from one university
evaluation will help to identify the strengths and weaknesses of to another. In an attempt to provide curricular guidelines for
this architecture as a general-purpose embedded systems education in this field, the IEEE/ACM CE2004 computer
educational tool. engineering model curriculum for embedded systems was
created [2]. This model provides a comprehensive list of
Index Terms— Computer architecture, computer engineering recommended topics that are important for embedded systems
education, educational technology, embedded systems.
education. Universities are challenged to integrate these
topics into the classroom and to create laboratory platforms
capable of supporting these topics.
I. INTRODUCTION
In this paper, we evaluate a popular embedded systems

E MBEDDED systems are becoming more and more common

as feature size and power requirements of electronic
components decrease and overall performance improves. As a
architecture to determine its suitability as a general-purpose
laboratory platform for embedded systems education. This
architecture, the VMEbus, was developed nearly 25 years ago
result, more and more graduates are entering careers working and has been used extensively in industrial, military,
directly with the design and implementation of embedded aerospace, communication, and control applications. Despite
systems [1]. In order to prepare graduates for the challenges its age, it is still one of the most popular architectures for
in this field, many universities are incorporating embedded embedded and real-time systems accounting for 38% of the
systems concepts into their computer engineering curriculum. embedded systems market in 2002 [3,4]. The emphasis here
However, embedded systems education is difficult to will be to evaluate the VMEbus architecture against the model
generalize due to the following: curriculum as opposed to comparing various embedded
x Embedded systems education incorporates a broad architectures.
range of concepts from many disciplines; The remainder of this paper is organized as follows.
x Different programs have different goals associated Section II provides a general description of the VMEbus
with their embedded systems curricula; architecture. Section III evaluates how the architecture
x There exists a diverse range of embedded supports many of the components of the model curriculum.
Conclusions are presented in section IV.
This work was supported in part by the National Science Foundation under
grants DUE-0310831 and EEC-0431792.
Kenneth G. Ricks is with the Department of Electrical and Computer
Engineering, The University of Alabama, Tuscaloosa, Alabama, 35487-0286 II. THE VMEBUS ARCHITECTURE
USA. (phone: 205-348-9777; fax: 205-348-6959; e-mail:
[email protected]). A. Background
David J. Jackson is with the Department of Electrical and Computer
Engineering, The University of Alabama, Tuscaloosa, Alabama, 35487-0286
The VMEbus is a system architecture consisting of the
USA. (phone: 205-348-2919; fax: 205-348-6959; e-mail: electrical specifications for a communication bus and the
[email protected]). mechanical specifications describing the backplane, bus
William A. Stapleton is with the Department of Electrical and Computer
Engineering, The University of Alabama, Tuscaloosa, Alabama, 35487-0286
connectors, board sizes and formats, as well as card cages,
USA. (phone: 205-348-1436; fax: 205-348-6959; e-mail: racks, and enclosures. VME stands for Versa Module
[email protected]).

59
Eurocard and refers to the VERSAbus, the predecessor Table 1. Summary of the VME32 system bus characteristics
electrical data bus standard, and the Eurocard, a predecessor [5, 6].
mechanical format for computer components. The VME
specification was completed in 1982 and is now part of the Architecture
ANSI/IEEE STD. 1014-1987. This is an open architecture Master/Slave
allowing third parties to freely develop VMEbus products [5, Transfer Mechanism
6]. Asynchronous (no central synchronization
B. General VMEbus Architecture clock)
Fully handshaked
The VMEbus architecture is a shared system bus Non-multiplexed
architecture. The system bus resides on a backplane. The Multiplexed for 64-bit transfers
backplane has slots where processor modules, memory
modules, or I/O modules connect to the system bus [6, 7]. Addressing Range
The backplane and all of the modules connected to it reside in 16-bit (short I/O)
an enclosure that serves to protect the components, provide 24-bit (standard I/O)
structural support for the system, and house utility 32-bit (extended I/O)
components such as power supplies and cooling fans. Figure 64-bit (long I/O)
1 shows one possible system configuration. The modular Address range is selected dynamically
design of this architecture provides great flexibility. All the Datapath Width
components are available commercially-off-the-shelf (COTS). 8, 16, 24, 32, 64-bit
Datapath width selected dynamically
C. System Bus Characteristics
A functional block diagram of the VME system bus is given Unaligned Data Transfers
in Figure 2, and the basic system bus characteristics are Yes
summarized in Table 1. It is beyond the scope of this paper to Compatible with most popular processors
describe all of the specific characteristics and the timing
Error Detection
behavior of the bus. However, Figure 2 and Table 1 provide a Yes
broad summary of the basic bus characteristics that will aid Using BERR* (optional)
the reader during this evaluation. Also, these characteristics
are those of the basic VME32 specification. Many extensions Data Transfer Rate
to this specification have been created, but for this discussion, 0-80 Mbytes/sec
the basic design will be used.
Interrupts
7 levels
Priority interrupt system with STATUS/ID
Backplane
Multiprocessing Capability
1-21 processors
Flexible bus arbitration
System Diagnostic Capability
Yes
Using SYSFAIL* (optional)
Mechanical Standard
Single height (160 x 100 mm eurocard)
Double height (160 x 233 mm eurocard)
DIN 603-2 connectors
Figure 1. Diagram of the general components and
configuration of the VMEbus architecture [8].

60
 Data Processing Device Memory or I/O
(CPU) Devices

Defined by VMEbus Specification

Interrupt
Master Handler Interrupter Slave Interrupter

System Controller Module

System Power IACK* Bus Location

Clock Monitor Arbiter Daisy-chain Timer Monitor Requester
Driver Driver

Backplane Backplane Backplane

Interface Logic Interface Logic Interface Logic

Data Transfer Bus

Priority Interrupt Bus

Data Transfer Arbitration Bus

Utility Bus

Figure 2. Functional block diagram of the VME system bus [6].

A. CE-ESY0 History and Overview (core)

III. THE VMEBUS SUPPORT FOR THE MODEL
CURRICULUM Topics
x Highlight some people that influenced or contributed to
To evaluate the capability of the VMEbus architecture for
the area of embedded systems;
use as a general-purpose embedded systems educational
x Contrast between an embedded system and other
platform, its characteristics and capabilities will be discussed
computer systems [2].
as they apply to each embedded systems component of the
IEEE/ACM model curriculum for computer engineering [2].
Learning Outcomes
The rationale is that if the architecture can address the
concepts in the model curriculum it should be able to support x Identify some contributors to embedded systems and
the diverse embedded systems curricula being taught across relate their achievements to the knowledge area;
the country. x Describe the meaning of an embedded system;
The embedded systems portion of the model curriculum is x Explain the reasons for the importance of embedded
broken into eleven areas of which seven are core topics and systems [2].
four are considered to be elective material. In the following
subsections, each of these areas is addressed. Each section The VMEbus architecture holds its own place in the history
begins with a list of the topics and learning outcomes from the and evolution of embedded systems. It was developed
model for a particular area that can be supported by the specifically for embedded applications. It is one of the most
VMEbus architecture. How the architecture supports these frequently used architectures for real-time applications [3] and
topics and learning outcomes for each area is then presented. accounts for 38% of the embedded systems market [4]. Also,
the fundamental components of the VMEbus architecture are
designed and configured differently than those used in
desktop computer systems. The form factor, component

61
placement, component interaction, and overall system design to the design of various memory hierarchies. This also allows
is different. This makes it easy to introduce embedded for the introduction of memory inconsistency into the
systems, compare and contrast them to general-purpose curriculum and provides a platform to demonstrate its effects
computing systems, and to justify their significance. on system and program performance.
B. CE-ESY1 Embedded Microcontrollers (core) C. CE-ESY2 Embedded Programs (core)
Topics Topics
x Structure of the basic computer system: CPU, memory, x The program translation process: compilation,
I/O devices on a bus; assembly, linking;
x CPU families used in microcontrollers: 4-bit, 8-bit, 16- x Fundamental concepts of assembly language and
32-bit; linking: labels, address management;
x Basic I/O devices: timers/counters, GPIO, A/D, D/A; x Compilation tasks: mapping variable to memory,
x Polled I/O vs. interrupt-driven I/O; managing data structures, translating control structures,
x Interrupt structures: vectored and prioritized interrupts; and translating expressions;
x Direct memory Access (DMA) transfers; x What can/cannot be controlled through the compiler;
x Memory management units; when writing assembly language makes sense [2].
x Memory hierarchies and caches [2].
Learning outcomes
Learning Outcomes x Understand how high-level language programs convert
x Understand the CPU in the context of a complete into executable code;
system with I/O and memory; x Know the capabilities and limits of compilers [2].
x Understand how the CPU talks to the outside world
through devices; The VMEbus architecture supports these topics and learning
x Understand how memory system design (caches, outcomes through the wide variety of operating systems and
memory management) affect program design and software development environments available for use with the
performance [2]. architecture. The variety of software available for this
architecture is unparalleled. For example, there are at least
The VMEbus architecture design is based upon the most 103 operating systems known to be ported to this architecture
basic of system structures. The modular design and [11]. Compilers and assemblers for many different high-level
interchangeable characteristics of the system components languages (HLLs), such as C, C++, and FORTRAN, and
gives students real system design and integration experience assembly languages are available depending upon the system
reinforcing the first learning outcome. Also, the asynchronous components used. This makes it convenient to examine high-
bus protocol and variable width data transfers make the level code and its associated lower-level constructs.
architecture compatible with many different processor Applications can be implemented in both a HLL and an
families. This is a key concept since a large percentage of assembly language for performance comparisons. Also, the
embedded systems rely on technology other than 32-bit processor modules can be used without an operating system
processors [9]. The ability to connect a logic analyzer directly (OS), which is often the case for embedded systems. In this
to the bus signals also provides a means for students to case, students are exposed to rudimentary development
analyze bus and system timing, to study the asynchronous environments possibly even entering the binary representation
handshaking protocol in depth, and to investigate bus of each instruction directly into memory manually. Students
arbitration and bus saturation. can be exposed to both locally hosted development
Since the architecture was originally designed for I/O environments and cross-compiled environments.
intensive applications, there are many COTS I/O devices that D. CE-ESY3 Real-Time Operating Systems (core)
can be used to teach the I/O topics and achieve the second
Topics
learning outcome. The asynchronous system bus design
x Context switching;
allows the architecture to support I/O peripherals of various
speeds using either polled I/O or an interrupt-driven design. x Real-time scheduling concepts;
The VME system bus supports 7 levels of prioritized x Interprocess communication mechanisms [2].
interrupts and can handle vectored interrupts.
The VME specification also provides flexible memory Learning outcomes
design helping to achieve the third learning outcome in this x Distinguish a real-time operating system (RTOS) from
area. For example, single transfers can be used or block a workstation/server OS;
transfers can be used for DMA operations. Different memory x Distinguish real-time scheduling from traditional OS
configurations can be created ranging from shared global scheduling;
memory to completely distributed memory creating both x Understand major real-time scheduling policies;
uniform memory access (UMA) and non-uniform memory x Understand interprocess communication mechanisms
access (NUMA) system configurations [10]. Cache memory [2].
is commonly available on processor modules and contributes The VMEbus architecture is one of the most popular

62
architectures for real-time computing and has been for many design;
years [3]. Many different RTOSs have been ported to many x Fault-tolerant techniques [2];
different processor families for this architecture. Some of
these RTOSs include Real-Time Linux, VxWorks, QNX, and Learning outcomes
OS-9. Many of these RTOSs support the POSIX real-time x Understand the variety of sources of faults in embedded
extensions for interprocess communication. Various computing systems;
scheduling strategies and timing issues can be investigated. A x Identify strategies to find problems;
VMEbus system using an RTOS can be configured to address x Identify strategies to minimize the effects of problems
an exact subset of these topics and learning outcomes to [2].
accommodate different educational strategies. In addition,
multiple processor modules in one VMEbus system can be To address these concepts and learning outcomes, students
configured to execute different OSs. In this way, direct using the VMEbus architecture can be exposed to a wide
comparisons can be made between an RTOS and a non-real- variety of problems ranging from low-level errors in the
time OS executing on the exact same architecture. fundamental bus transactions to debugging software written in
E. CE-ESY4 Low Power Computing (core) high-level languages. Fault tolerance using redundancy can
be introduced by including redundant system components.
Topics
Students have access to both hardware and software on these
x Sources of energy consumption; systems requiring failure strategies and debugging in both
x Instruction-level strategies for power management: domains.
function unit management;
x Memory system power consumption: caches, off-chip G. CE-ESY6 Design Methodologies (core)
memory; Topics
x Power consumption with multiple processes; x Multi-person design projects;
x System-level power management: deterministic, x Designing on-time and on-budget;
probabilistic methods [2]. x Design reviews;
x Tracking error rates and sources;
Learning outcomes x Change management [2].
x Understand why low-power computing is important;
x Identify sources of energy consumption; Learning outcomes
x Identify possibly remedies for energy consumption at x Understand why real-world projects are not the same as
various levels of design abstraction [2]. class projects;
x Identify important goals of the methodology;
There is no specific support in the VMEbus specification x Understand the importance of design tracking and
for low power computing. A typical VMEbus enclosure is not documentation [2].
remotely powered, thus eliminating the need for strict energy
management strategies such as those seen in handheld and The VMEbus architecture actually supports these design
remotely deployed embedded systems. However, this does concepts and learning outcomes better than many other
not prevent one from monitoring energy consumption of the educational technologies. The reason for this is that the
system modules such as memory and comparing and VMEbus architecture supports design at various levels of
contrasting energy usage in single and multiple processor abstraction. For example, given a set of modules, students can
systems to achieve the learning outcomes. Additionally, the make meaningful system-level design decisions including the
asynchronous bus protocol will support both high and low number of processors, the design of the I/O system, and the
speed processors in the same system. Since reducing clock configuration of memory (distributed, shared, hierarchy
speed is one primary power management technique, this characteristics, etc.). Low-level design can be incorporated
architecture can provide a platform to make direct into a project by having students design logic components
comparisons of power consumption for system components capable of interfacing to the VME system bus. Real-world
having different clock speeds. Finally, custom low power concepts can be addressed by incorporating VMEbus
circuitry can be developed on prototyping system modules and component documentation into projects, thus exposing
interfaced to the VMEbus system for control and monitoring. students to typical technical documentation they are likely to
Controlling custom low power components within an existing see as a practicing engineer. This tends to reinforce the
system architecture can also help to achieve the learning importance for students to produce accurate documentation of
outcomes suggested in this area of the model curriculum. their own systems. The fact that the VMEbus is a real
F. CE-ESY5 Reliable System Design (core) embedded systems architecture can motivate students since
they see the project as more than an academic exercise.
Topics
x Transient vs. permanent failures in hardware; H. CE-ESY7 Tool Support (elective)
x Sources of errors from software; Topics
x The role of design verification in reliable system x Compilers and programming environments;

63
 x Logic analyzers; to produce a heterogeneous system. Memory configurations
x RTOS tools; are also flexible ranging from completely shared to completely
x Power analysis; distributed. Thus, the VMEbus architecture can easily be used
x Software management tools; to teach students general multiprocessor architectures and
x Project management tools [2]. basic design techniques. FPGA devices integrated into a
VMEbus module are available and can be used to teach
Learning outcomes hardware/software co-design [13], partitioning, trade-off
x Understand the role of hardware and software tools in analysis and performance analysis. The use of reconfigurable
system design; hardware technology for embedded systems education is
x Understand how to use tools to support the common [14], but incorporating it into the VMEbus
methodology [2]. architecture creates a robust educational platform where this
hardware can be integrated with real-time system components.
The tools and environments available to VMEbus designers Multiprocessor architectures can be used to teach other topical
areas in the model curriculum as well including bus
are plentiful and varied in design, objective, and scope. There
characteristics such as arbitration and saturation. Bus
are many different software tools such as compilers,
saturation is a key design consideration within multiprocessor
assemblers, debuggers, development environments, and real-
architectures. Also, memory characteristics such as mutual
time analysis tools. There are also custom function libraries exclusion and interprocess communication, as discussed in
and drivers tailored to particular system components available section III D, are reinforced.
from various vendors. For locally hosted systems, software
tool availability is dependent upon the OS executing on the J. CE-ESY9 Networked Embedded Systems (elective)
processor module. But, this is typically not a limitation since, Topics
as previously mentioned, at least 103 OSs have been ported to x Why networked embedded systems;
this architecture [11]. There are also special purpose logic x Example networked embedded systems;
analyzers designed specifically to analyze VME system bus x The OSI reference model;
timing. Individual institutions can select particular OSs and x Types of network fabrics;
tools to tailor their VMEbus system to accommodate their x Network performance analysis;
particular curricular goals and objectives. Finally, something x Basic principles of the Internet protocol;
that is not directly listed in the model curriculum but does x Internet-enabled embedded systems [2].
represent a major concept is the development of device drivers
[12]. If desired, students can develop drivers for various I/O Learning outcomes
peripherals using this architecture. x Understand why networks are components of
embedded systems;
I. CE-ESY8 Embedded Multiprocessors (elective) x Identify roles of hardware and software in networked
Topics embedded systems;
x Importance of multiprocessors as in performance, x Compare networks designed for embedded computing
power, and cost; with Internet networking [2].
x Hardware/software partitioning for single-bus systems;
x More general architectures; The VMEbus architecture can provide insight into
x Platform field programmable gate arrays (FPGAs) as networking concepts in several different ways. Since the
multiprocessors [2]. architecture is common in industrial control applications, it is
normal to have VMEbus enclosures physically distributed
Learning outcomes throughout the factory yet logically connected to promote
x Understand the use of multiple processors in embedded sharing of resources and provide for centralized monitoring
systems; and control. There are many different products available that
x Identify trade-offs between CPUs and hardwired logic can logically connect distributed VMEbus systems. Some of
in multiprocessors; these products include reflective memory (shared memory),
x Understand basic design techniques [2]. fiber optics, and various standardized communication
protocols like the TCP/IP and the MIL-STD-1553 bus
With the increasing complexity of embedded systems, standard. With so many choices, institutions can investigate
multiprocessing is becoming a requirement in order to meet concepts such as shared memory, dedicated local-area-
performance specifications. This is especially true for real- networks, shared wide-area-networks, different protocols, and
time applications. One of the strengths of the VME network bandwidth and congestion. Comparisons can be
architecture is its multiprocessing capabilities [4]. The made between dedicated networks and Internet networking.
modular design of the components makes it easy to create Various customized networked systems can be created to
various multiprocessor configurations. For example, all achieve the specified learning outcomes.
processors can be identical creating a homogeneous system, or
each processor can be different, even executing different OSs,

64
 K. CE-ESY10 Interfacing and Mixed-Signal Systems curriculum, low-power computing. Also, size constraints are
(elective) not addressed outside the context of the VME form factor.
Topics Although size is not specifically part of the model curriculum,
x Digital-to-analog (D/A) conversion; system-on-a-chip implementations are critical for many
x Analog-to-digital (A/D) conversion; embedded applications including handheld consumer
electronics. Finally, VME system components are relatively
x How to partition analog/digital processing in interfaces;
expensive. This is a serious consideration for educational use.
x Digital processing and real-time considerations [2].
Despite these weaknesses, the authors feel that the VME
architecture represents a powerful, capable embedded systems
Learning outcomes
architecture that is appropriate for general-purpose embedded
x Understand pros and cons of digital and analog
systems education based upon its strong support for most of
processing in interfaces;
the concepts in the model curriculum.
x Understand fundamentals of A/D and D/A conversion
[2]. REFERENCES
A/D and D/A conversion are important components of I/O
[1] Y. H. Lee, A. Oo, “Teaching Microprocessor System Design Using a
processing and are addressed in that context in section III B. SoC and Embedded Linux Platform”, Proceedings of the 2005
The main topic in this section deals with mixed-signal design. Workshop on Computer Architecture Education (WCAE) held in
There is no direct support for this within the VMEbus conjunction with the 32nd International Symposium on Computer
specification. However, mixed-signal design fits well within Architecture, Madison, Wisconsin, June 5, 2005.
[2] Joint Task Force on Computer Engineering Curricula, IEEE Computer
the VMEbus architecture which was designed for I/O Society, Association for Computing Machinery, “Computer Engineering
intensive applications. Specifically, interfacing the digital and 2004: Curriculum Guidelines for Undergraduate Degree Programs in
analog components of the system can be addressed using bus Computer Engineering”, December 12, 2004, pp. A.43 – A.45,
modules which include prototyping areas for custom design. Available: http://www.computer.org/education/cc2001/CCCE-
FinalReport-2004Dec12-Final.pdf.
In this way, students can be tasked with interfacing analog
[3] A. Kornecki, H. Wojcicki, L. Peltier, J. Zalewski, N. Kruszynska,
components to an existing digital system outside the normal “Teaching Device Drivers Technology in a Real-Time Systems
I/O context. The real-time aspects of the architecture provide Curriculum”;
unlimited possibilities for investigating signal processing with Proceedings of the 1998 Real-Time Systems Education III, Nov. 21,
real-time constraints. 1998, pp. 42 – 48.
[4] J. Moll, “Shared Bus Versus Switched Fabric Technologies”, EE Times,
January 17, 2003, Available online:
http://www.eetimes.com/story/OEG20030116S0036.
IV. CONCLUSIONS [5] IEEE Standard for a Versatile Backplane Bus: VMEbus, ANSI/IEEE
Standard 1014-1987.
Embedded systems education is rapidly being implemented [6] W. D. Peterson, The VMEbus Handbook3 3rd Edition, Scottsdale,
in electrical and computer engineering programs across the Arizona: VFEA International Trade Association, 1993.
nation. But, it is unlikely that institutions of higher learning [7] K. G. Ricks, “An Improved Bus-Based Multiprocessor Architecture”,
M.S. thesis, Electrical and Computer Engineering Dept., the University
will implement a common embedded systems curriculum in of Alabama in Huntsville, Huntsville, Alabama, 1997.
the near future. The broad nature of the field and different [8] M. Timmerman, “The Right Bus in the Right Place: A Tutorial (part 1)”,
educational objectives have led to highly customized curricula Real-time Magazine, 4Q96, pp. 6-11, Available: http://www.realtime-
supported by equally customized laboratory platforms. The info.be/magazine/index/index964.htm.
[9] P. Koopman, “Embedded Systems Design Issues (the Rest of the
IEEE/ACM model curriculum attempts to provide guidelines Story)”, Proceedings of the 1996 IEEE International Conference on
for the concepts required in this field. Laboratory platforms Computer Design: VLSI in Computers and Processors, October 1-9,
capable of supporting these concepts can be applied as 1996, pp. 310-317.
general-purpose educational tools across many curricula. [10] K. Hwang, Advanced Computer Architecture: Parallelism, Scalability,
Programmability, McGraw-Hill, New York, New York, 1993.
In this paper, the VMEbus architecture is evaluated against [11] Portions of this FAQ have been reprinted (with permission) from The
the model curriculum to determine its suitability as a general- VMEbus Handbook, 4th Edition by Wade D. Peterson. VITA 1997. For
purpose educational platform in this field. This architecture is more details the user is directed to the handbook, or the VMEbus
shown to support many of the concepts in the model specification(s). Other items have been reprinted from the VITA Journal
(with permission) VMEbus FAQ's article series by John Rynearson.
curriculum addressing many different educational objectives
Available online: http://www.vita.com/vmefaq/
and learning outcomes. Specifically, there is strong support [12] A. Kornecki, H. Wojcicki, J. Zalewski, N. Kruszynska, “Teaching
for topics including historical and introductory concepts, device drivers technology in a real-time systems curriculum”
system design, I/O, real-time systems, multiprocessing, Proceedings of the 1998 Real-Time Systems Education III, Nov. 21,
1998, pp. 42 – 48.
memory configurations, networked embedded systems, and
[13] W. Wolf, Computers as Components: Principles of Embedded
software tool support. Other benefits of the use of this Computing System Design, Morgan Kaufmann, New York, New York,
architecture include exposing students to a real-world 2001.
embedded architecture, the wide range of COTS components [14] Proceedings of the 2005 International Conference on Microelectronic
available supporting various system configurations, and its Systems Education, Anaheim, California, June 12-13, 2005.
longevity in the field.
Like all other architectures, it is not perfect. The VMEbus
architecture does not address one key concept from the model

65
 Diverse Hardware Platforms in Embedded Systems
Lab Courses: A Way to Teach the Differences
Falk Salewski, Dirk Wilking, Stefan Kowalewski

Abstract— Traditional methods for teaching the design of Since reconfigurable hardware (CPLD/FPGA) has blurred
embedded systems usually deal with either a hardware or a the gap between hardware and software programming [1] it
software view of the system. In computer science it is mostly the has become harder to distinguish between these two areas.
software view. The hardware issues taught mostly deal with CPU
based systems only and seldom with reconfigurable hardware. This is our reason to recommend dealing with all kinds of
We recommend having a more general view at embedded ”programmable hardware” like hardware whose behavior is
systems in the way that it is always a programmable hardware defined by software. On the one hand, an MCU is used, which
platform (CPU based or reconfigurable hardware) which has to is programmed in classical software (C in this case) as a
be programmed in a suitable programming language. In this representative of CPU based hardware. On the other hand,
context we offer a lab course where students should get familiar
with different hardware platforms used in embedded systems. we use a CPLD, which is programmed in a suitable hardware
They should solve the same task both with a CPLD and a description language (VHDL in this case), as a representative
microcontroller each in order to clarify the differences between of reconfigurable hardware.
the two implementations. In this paper our experiences in this The basic ideas of the differences between these two
field of embedded systems education are described as well as our hardware approaches should be taught in a lecture. This
plans to continue.
basic knowledge should include the possibilities to implement
sequential and parallel structures, possibilities of interfacing
Index Terms— Computer science education, Lab course, Real-
time and embedded systems internal and external hardware modules, limitations according
to the amount of memory and the number of logic cells etc.
I. I NTRODUCTION However, if the students lack the practical experience, most
of them would not consider designing a system containing
HE number of embedded systems is increasing. These
T days, already more than 98% of all microprocessors are
found within embedded systems [3]. Such systems integrate
reconfigurable hardware. Thus, we recommend a lab course
to become more familiar with these embedded systems. Since
we focus on the differences of hardware platforms and their
hardware and software components and require developers according software, a single task is given that has to be solved
with skills in both subjects. In this respect an interesting successively with the CPLD and the MCU. Thus, a suitable
aspect is, which types of hardware are applied preferably in task had to be found which is representative for the field of
embedded systems. This information should form the basis embedded systems and which could be solved on the basis
for the education of hardware and software for embedded of both types of hardware. We will deal with this topic in the
systems. Aside from many versions of CPU based systems like following chapter. Another important aspect regarding the lab-
microprocessors, microcontrollers (MCU) and digital signal structuring is how much a priori knowledge can be assumed,
processors (DSP) also two other groups of hardware can be which issues can be taught in a short introduction as well
found. The first group consists of reconfigurable hardware as how much the students can teach themselves by using the
as complex programmable logic devices (CPLD) and field according material. It is also important which hardware and
programmable logic arrays (FPGA); application specific inte- software is necessary during the lab and how the lab course
grated circuits (ASIC) form the second group. In most embed- should be structured. These points will be discussed in chapter
ded system design courses for computer science students only 3. Chapter 4 then states the experiences we gained in the
the design of CPU based systems is taught [1], [2]. However, first run of our lab course and the most interesting results are
reconfigurable hardware is a good option to improve many presented in chapter 5. Then, chapter 6 states some advantages
embedded applications [4], [8]; an option which students will of this kind of a lab course and lab courses in general. We
probably never choose if they do not get in touch with it conclude with chapter 7 and present our plans for future work.
before. According to the need of education in this field [1],
[2], [3] we aim to teach our students the general ideas of II. O NE TASK FOR DIFFERENT IMPLEMENTATIONS
different hardware and their corresponding software. In the lab The task chosen for the lab course should allow present-
course presented in this paper the differences between CPU ing as many properties of embedded systems as possible.
based systems and reconfigurable hardware are focused on. In our opinion the most important properties are the need
to interface with the environment (real time requirements,
All authors are with the Embedded Software Laboratory - Chair of
Computer Science XI, RWTH Aachen University, 52074 Aachen, Germany concurrency) and with external peripherals (e.g. bus driver,
(surname)@informatik.rwth-aachen.de memory chips, engine driver). Other important properties are

66
 MCU CPLD / VHDL Peripheral
12,0% programming 4,0% programming 12,0% programming
24,0% knowledge knowledge 20,0% knowledge
Very high 24,0%
Very high Very high
28,0% High High High
56,0%
Medium Medium 64,0% Medium
36,0% Low 16,0% Very low Very low

Fig. 1. Improvement of programming knowledge by hardware aspect.

the restricted resources in memory/logic cells, space, cost and more important point was, that students this way could use
power consumption. The task we chose for our lab course is the environment at home in order to become familiar with it.
the implementation of the speed measurement for an automo- The simulator, which was available in both cases, even allows
tive prototype vehicle we are designing at our institute for the debugging of example implementations without having the
research and teaching purposes [6]. The task comprises three actual hardware.
major sub-tasks: first, the actual speed measurement, second, For the access to the CAN bus additional boards with
a measurement data processing and third, communication via CAN controllers and the according bus interface were needed.
CAN bus. We designed boards, which can be connected to the MCU
The sensor signal for the speed measurement is rectangu- (5V device) and to the CPLD (3,3V device), and provided 6
larly shaped with a frequency proportional to the speed of the of them. We also provided 6 simple frequency synthesizers
according wheel. Four of these signals have to be evaluated for testing the velocity measurement (simulating the sensor
concurrently in order to gain new data for all four wheels in signals). Therefore, two groups had to share one CAN board
a short interval. Maximum values for delay and accuracy are and one frequency synthesizer for debugging.
given.
The measured values have to be processed according to a
given table in order to fit into a given format of the CAN
message. Furthermore an error message should be calculated.
The measured and processed values of the actual speed
values have to be sent to the CAN bus as soon as new data is
available in a single CAN message. For an easy access to the
CAN bus an external stand alone CAN controller (SJA1000)
is used which has to be initialized before.
Since this task is a combination of parallel and sequential
tasks we believe that it is suited for both implementations.
Details of the task can be found in [7].
Fig. 2. Used hardware structure (use CPLD or MCU).
III. T HE L AB C OURSE
According to the fact that hands-on work significantly
improves a students learning and subsequent retention of For the participation in this lab course we recommend
material [5], all student’s should have access to suitable visiting the lectures Introduction to Embedded Systems and
development boards. For a lab course consisting of 24 students Embedded Software Design offered by our institute. The first
twelve sets of hardware were needed (groups of two). Since all lecture deals with the basic properties of embedded systems
students should work on both hardware platforms they were and provides an introduction for microcontrollers and pro-
split up in two main groups. One group started with MCUs and grammable logic controllers. We are planning to add basics of
the other one with CPLDs. This procedure allowed working Programmable Logic Design in the future. The second lecture
with six MCU and six CPLD boards. For the CPLD the Xilinx deals with development processes and methods for software
CoolrunnerII CPLD Starter Kit was chosen, for the MCU we for embedded systems. This includes requirements engineering
used a development board based on the ATMEL ATmega16 (functional and non-functional requirements) and architecture
8-bit RISC MCU. Both decisions were made according to the design and analysis. In addition to this lectures we offered
following reasons: low price, free development environment a two day introductory course in the week before the actual
and good support with tutorials, news groups etc. lab course had started. On the first day, the students were
The development environments used are based on freeware introduced to the programming of MCUs in C. On the second
only for the following reasons: First we would not be able day, an introduction was given in the programming of CPLDs
to afford the high number of licenses. The second and even in VHDL. Since most of the students were not familiar with

67
VHDL, an introduction to the basics of this language was in this context. Wrong initialization was hard to detect since
given as well. At the end of each day the same example (traffic students had difficulties in separating the problems they had
light with user interface) had to be implemented on the actual in the software part of the communication (wrong values in
hardware in order to give a first impression of the differences. initialization, incorrect timing in write/read function, incorrect
During the introductory course we tried to clarify the important order of write/read accesses) and the hardware part of the
properties and techniques for MCUs (e.g. Interrupts, I/O ports, communication (problems with bidirectional communication,
internal peripherals like timer, hardware specific C commands, incorrect jumper settings, incorrect connections in general).
debugging) and CPLDs (e.g. parallel/sequential structures, I/O Thus we are planning to provide more detailed information
ports, VHDL, debugging). Data sheets for all hardware, the about the use of the SJA1000 and its initialization in the next
introduction slides and a document with VHDL basics were lab.
handed out to each group on a CD. One of the major problems that occurred with the imple-
The actual lab course took place on 13 appointments for mentation on the CPLD were the restricted resources. Many
3h/week. We had to offer more appointments for some students students had problems fitting their design on the chip. In most
who had not completed their task after the 13 dates yet; of the cases this problem could be solved by adapting the
however some of the students also finished earlier. Since there calculations done in the design (reducing size of variables,
had been no dedicated room available for the lab course, the simplifying calculations). However, in some cases the problem
hardware equipment and all cabling had to be set up for each remained and thus we are planning to use bigger FPGAs
day. Therefore, for installation and unistallation about 15min (much more logic available) for the next term. We also realized
each were needed. that some students were not able to implement a useful com-
During the lab course all CAN boards were connected to bination of parallel and sequential structures successfully in
a single bus, which in turn was connected to a PC based VHDL. Thus, more information how to solve these problems
CAN bus monitor. On the monitor, the students could check has to be given in the introductory course next term.
if they were sending their messages correctly. The general Another problem concerned the CPU time needed for a
function of the velocity measurement could be tested with compile run (synthesize, translate and fit) for the CPLDs. It
the simple frequency synthesizers. For testing the accuracy turned out to be much higher than the one needed for the
of the sent values a waveform generator was available. The MCUs (minutes instead of seconds). Thus, we will try to
successful communication between the MCU/CPLD and the improve the performance of our computers for the next term.
CAN controller could be checked by a special LED on the According to the longer compile runs and the less familiar
CAN board. software and hardware the groups which started with CPLDs
The students had to organize their work on their own and needed longer to finish their first implementation. Thus, we
to find the necessary information in the according data sheets. had to provide some extra time for this implementation. This
However, at least one instructor was available all the time to problem was solved by shifting the date of changing the groups
answer upcoming questions as well as to help if necessary. by one week and by offering an extra date. However, we are
Most of the answers given to one group during or after the planning to use more hardware sets in the next term to avoid
lab were made available via Email to the other students the the problem according to the need of changing the hardware
following day. in the middle of the course.
At the end of each implementation an acceptance test was At the end of the course, all of the students had to fill out
done in order to check the basic functionality. Each group also two questionnaires in order to evaluate the lab course. The first
had to hand in a documentation of their final versions (CPLD one is part of the university teaching evaluation and the second
and MCU). has been developed at our institute to improve the contents of
the lab course itself. Some of the results are presented in the
IV. E XPERIENCE WITH L AB C OURSE following chapter.
The first lab course has been finished successfully with 26
students by now. Almost all of the students managed to pass V. R ESULTS
the final acceptance test with both of their hardware implemen- In this chapter, the most interesting results of the evaluation
tations. During the introductory course most of the students will be presented. One of these results concerns the question of
learned very enthusiastically and showed strong motivation for how much the students have improved their knowledge in the
teaching themselves the necessary additional knowledge. This field of programming MCUs, CPLDs and interfacing external
knowledge included how to work with the integrated timers peripherals. According to the results presented in figure 1 most
(MCU), the hardware specific parts of the programming lan- improvements could have been gained in CPLD and peripheral
guage C (MCU) and the basics of the programming language programming. However, a small number of students stated
VHDL (CPLD). For both implementations the access to the that they had learned only very little in this field. Another
external CAN controller (SJA1000) and its correct use had to interesting point is the amount of external help the students
be understood. needed in order to solve their task (figure 3). In the case of the
According to the high number of possibilities in the field CPLD significantly more external help was needed. This result
of the SJA1000 initialization many problems have occurred corresponds well with figure 4 in which the amount of code

68
 External help for External help for
MCU CPLD in this field. The result presented in figure 7 represents in our
24,0% Medium 24,0% High
Low Medium opinion a good result for this first lab course. Since many
52,0% Low
76,0% results indicated that the programming of the CPLD needed
24,0%
more effort we will try to reduce this difference by giving a
more detailed introductory course in the next term.
Fig. 3. External help for different platforms.

developed at home is presented. In the case of the MCU about

76% of the students never have programmed at home, in the
case of the CPLD it only has been 32%. Figure 5 provides
some additional information about the CPLD programming Fig. 7. Reuse of knowledge.
done at home with respect to the fact if the groups started
with the MCU or the CPLD.
VI. A DVANTAGES OF DIVERSE PLATFORMS IN EMBEDDED
MCU code at CPLD code at
4,0% home home SYSTEMS LAB COURSES
0% 20,0% 0%
20,0%
32,0%
25%
50%
25%
50%
Lab courses always involve a lot of work before and during
76,0% 20,0% 75% the actual course, especially when a lot of hardware is used.
28,0%
However, we believe that they provide the best way to teach
the practical aspects of embedded systems. Especially the
Fig. 4. Programming done at home. use of diverse platforms turned out to be an ideal way to
clarify the differences between the different platforms used
in embedded systems. In our view, the results gained from
Treatment: MCU first Treatment: CPLD first this first lab course confirm this position. Additionally, a lab
CPLD code at CPLD code at
home 7,69% home
course could be used for collecting empirical data on many
25,0% 0%
25%
0%
25%
aspects of the embedded systems domain. In our case all
38,46%
58,33%
50% 38,46% 50% versions of software compiled during the lab course were
75%
16,67%
collected. We are planning to analyze these data in order
15,38%
to receive information about the differences between CPLDs
and MCUs according to non-functional qualities as reliability,
Fig. 5. CPLD programming done at home by starting group. safety, maintainability and changeability.
VII. C ONCLUSIONS AND FUTURE WORKS
Those who started with the CPLD did much more CPLD
programming at home than the group who started with the A. Conclusions
MCU. This could be interpreted in two different ways. First, In this paper, a way to teach embedded system design
the groups who had just started could have been more moti- with focus on the difference of diverse hardware platforms
vated and have thus worked more at home. Second, the first like CPLDs and MCUs and their according languages was
steps to solve the given task (understand the general ideas of proposed. In this context, the same task had to be solved
CAN communication, speed measurement, etc.) were harder to on a CPLD and a MCU each by every group in order to
realize in the case of the CPLD. In the next term an according demonstrate the differences. The biggest problem that occurred
question will be added in the questionnaire to clarify this point. during the lab was the inappropriate use of parallel and
Another aspect we will have to look closer at in the next term sequential structures, the limited resources in the case of the
is presented in figure 6. According to this figure some students CPLD and the problems in understanding the data sheet of the
(20%) have to improve their ability to distribute the work SJA1000. We are sure to meet these problems in the next term
within their group. Finally, the students were asked how useful by improving our introductory course and by using a larger
device. We also stated that lab courses like the one presented
Distribution of
4,0% work within in this paper are well suited for the collection of empirical
16,0% group
40,0% Very good data in the field of embedded systems.
Good
Bad
40,0% Very bad B. Future Works
As mentioned above, the lab course for the next term will
be improved by using different hardware and by extending the
Fig. 6. Distribution of work within a group.
introductory course in the fields where the problems occurred.
We are also planning to add some small additional tasks as
the knowledge gained in this lab course is to solve future tasks a simple user interface. This way, we hope to improve our

69
intention in clarifying the differences between reconfigurable
hardware and CPU based systems. We also plan to implement
a web page including the FAQs from the first lab course.
A further lab course is planned for the summer term 2006
based on Atmels FPSLIC Chip. According to the fact that
this chip includes an 8bit MCU and a 40k FPGA we hope
to demonstrate not only the differences between CPLDs and
MCUs but also possible approaches of HW/SW Co-Design in
the way that a single task is implemented on a combination
of both hardware. We plan to let the students solve a modified
task on three different hardware platforms. The first one would
be an MCU, the second an FPGA and the third a combination
of both (FPSLIC Chip).
C. Acknowledgments
We thank XILINX (www.xilinx.com) for providing us the
Spartan3 FPGA development boards we are going to use in the
next term. We thank ATMEL (www.atmel.com) for providing
us the FPSLIC development boards we plan to use in summer
term 2006.
R EFERENCES
[1] J. M. P. Cardoso. New challenges in computer science education. In
ITiCSE ’05: Proceedings of the 10th annual SIGCSE conference on
Innovation and technology in computer science education, 2005.
[2] N. Chang and I. Lee. Embedded system hardware design course track for
cs students. In Proceedings of the 2003 IEEE International Conference
on Microelectronic Systems Education, 2003.
[3] R. Hartenstein. The changing role of computer architecture
education within cs curricula. Invited talk, Workshop on
Computer Architecture Education (WCAE’04) at 31st International
Symposium on Computer Architecture. http://helios.informatik.uni-
kl.de/staff/hartenstein/lot/hartensteinwcae04.
[4] R. Hartenstein. The digital divide of computing. In Proceedings of the
ACM International Conference on Computing Frontiers, pages 357–362.
ACM press, 2004.
[5] A. R. Korwin and R. E. Jones. Do hands-on, technology-based activities
enhance learning by reinforcing cognitive knowledge and retention?
Journal of Technology Education, 1(2), 1990.
[6] Project:. Experimental vehicle for automotive software design.
http://www-i11.informatik.rwth-aachen.de/Versuchstre+Design&bl.html.
[7] Webpage:. Lab course programming embed-
ded hardware. http://www-i11.informatik.rwth-
aachen.de/Programmierung+Eingebetteter+Hardware.html.
[8] S. Wong, S. Vassiliadis, and S. Cotofana. Embedded processors: Charac-
teristics and trends. Technical report, Computer Engineering Laboratory,
Delft, The Netherlands, 2004.

70