EEE3074W: Embedded Systems





Outcomes and Syllabus Definitions Feedback

Scope: This document describes each component of the EEE3074W course design in detail.


EEE3074W is about designing and developing embedded systems. The aim of this course is to arm1 students with fundamental knowledge and experience to develop embedded systems, and to become an more productive member of an embedded system development team. The course is divided into three parts, namely: theory, practice, part participation. Each part involves important knowledge and experiential learning activities which are designed to educate students on industry practices and development methodologies used to produce professional, highly maintainable and robust systems. The main point of this course is for you to learn about embedded system development, and to do so following an active learning approach that encourages create thinking. My driving philosophy, in general, and for this course, can be summarized by my favorite mantra: Think, Try, Don't Fry.

This document describes each component of the different parts of the course. The final section discusses resources that will be available to students who register for the course.

Theory Component

The theory component comprises 31 lectures. The lectures run in parallel with the laboratory practicals, homework assignments, and the main project. This section is divided into 1) lectures, 2) the essay assignment (and its purpose), and 3) paper-based evaluation.


The lectures, laboratory practicals, and projects follow a parallel sequence. The bulk of the lectures (about 70%) are theory lectures which are not dependent on a specific type of embedded platform. A number of lectures relate to platform-dependent issues, but provide students a proper understanding of how a real embedded system is developed.

The first set of lectures, and the first essay, are focused on providing the student with an introduction to embedded systems in which basic terminology, the lifecycle of an embedded systems, and basic elements of embedded system design are covered. The lectures become more focused on specific design and development issues, such as how to select hardware architectures, and the process of partitioning a system between software and hardware (which is by no means an easy task nowadays. System Modeling and the use of RT-UML is covered in depth in the second semester, together with an introduction to the theories of co-design, simulation environments and sophisticated debugging hardware solutions. Lectures prior to exams recap important aspects that are likely to come up in the exam. The three final lectures are specially organized to encourage students to continue their interest in embedded systems once the course is completed: the third-last lecture is given by an guest lecture (or industry representative) who discusses the South Africa Embedded System industry and is happy to answer questions relating to industry issues and employment. The second-last lecture looks at possible future technologies and trends in embedded system design. The final lecture involves an opportunity for students to give feedback on their experience of the course, to hear the lecturer's vision of an ideal course, to make suggestions for how future courses can be improved, and to fill out evaluation forms.

Table 1 provides an overview of each, individual lecture.

Table1: Description of Individual Lectures





Lecture 01: Introduction

Welcome to the students. Introduction of the lecturer(s). Definition of what en embedded system is, with pictures and physical examples.


Lecture 02: History & ANSI C

A look at the history leading towards the development of the (arguably) first embedded system. Explanation of why so many embedded systems are developed using standard ANSI C, and the increasing popularity of embedded C++.


Lecture 03: UML Basics

Starting out with UML. Benefits of using UML models in embedded system design. Applying UML at the system level. A look at the important modeling notations and related terminology. Class activity involving UML modeling.


Lecture 04: AOD & GST

An AOD is a specialized UML model. AOD stands for Artifact Organization Diagram. This is used in the labs to tell you where things are located and how they are related. GST (General Systems Thinking) is a methodology well suited to thinking about embedded system design at a high-level.


Lecture 05: Embedded System Design Lifecycle

A broad look at general embedded system development, from the product specification phase, to maintenance, upgrade, and finally retirement.


Lecture 06: ? Discussion of Project???

-- TBD --


Lecture 07: Requirements, Specification, and Selection Process

A closer look at the first phases of the embedded system design lifecycle.


Lecture 08: The Selection Process (Continued)

Context of Selection Process, where it fit into the Life cycle. Selection process activities. Important issues. Strategies and guidelines.


Lecture 09: The Partitioning Decision

How to separate the implementation of functionality between software and hardware components, and reasons why you might build in redundency by implementing certain functionality in both software and hardware..


Lecture 10: The Development Environment (CH4)

Hardware and software tools use in developing an embedded system in relation to general embedded system platforms.


Lecture 11: CH4 (cont) and Introduction to the CSB337

The development environment for use in the lab pracs and project.


Lecture 12: Boot loaders and Boot Monitors

Programs that are initially executed at system startup, and are used to load an application programs (boot monitors provide more features).


Lecture 13: Advanced RISC Machines (ARM)

Overview of the ARM architecture.


Lecture 14: ARM Programming

Introduction to programming an ARM-based microprocessors. Addressing modes, using memory maps, etc.


Lecture 15: ARM Assembly Language

Writing a simple ARM assembly language program. Types of instructions, their mnemonics. Using GCC-ELF-AS, macros, labels, etc.


Lecture 16: Special Software Techniques

Using memory mapped peripherals. In-line assembly. Bitwise operations and their C operators and ARM instructions. Volatile variables in C. Speed and code density. Use of interrupts vs. polling. Implementing interupt service routines.


Lecture 17: Revision

Recap of important topics. Q&A.



Lecture 18: Exam 1 feedback, Semester 2 Planning

Welcome back to students. Feedback on Exam 1 (identify common mistakes, suggestions for improvement). Way ahead for semester 2.


[Lecture 19: Project 3 and Conceptualization]


[Lecture 20: Project 3 and Concept Presentation]


[Lecture 21: Concept Design Class Activity]


Lecture 22: Intro to Design Methodology and Basic Toolset

The Dataquest study. Motivation for design methodologies. Estimation. Growth of projects size and complexity, the need to establish procedures. Informal and formalized procedures.


Lecture 23: Basic Toolset Continued

ROM Emulator. Logic Analyzer. Oscilloscope.


Lecture 24: Real-Time Aspect of Embedded Systems

Recap definition of real-time and real-time systems. Logical and temporal requirements. Introduction to Real-time UML.


Lecture 25: RT UML and Interface Control Documents

Real-Time UML Use Cases, sequence diagrams, messages. Interface Control Document (ICD).


Lecture 26: Dynamic Behavior and 1-wire Protocol

Real-Time UML class and object diagrams, statechart. Manchester encoding. A general-purpose half-duplex communication protocol for RF communication implementation or simulation using Manchester encoding.


Lecture 27: UML Timing Diagrams

Real-Time UML Timing Diagrams. RT UML modeling class activity.


Lecture 28: On-chip Debugging Standards, BDM

Previously, looked at debug kernel implemented in firmware. Now look at on-chip debugging facilities, their advantages and disadvantages. BDM was the first on-chip debugging solution.


Lecture 29: JTAG, Nexus and ICE

Abut the JTAG and Nexus on-chip debugging standards. A look at In Circuit-Emulators (ICE).


Lecture 30: Testing

Strategies for testing embedded systems, and details of the Factory Acceptance Test (FAT).


[Guest Lecture]

Industry representative talks about local embedded systems industry in South Africa; common difficulties that they experience; demonstrates products (e.g. video footage of products they develop); local employment prospects and what employers like to see.


Lecture 31: The Future (CH10) and Exam Syllabus

What embedded system products, and their design may be like in the future.


What's Your Ideal Course? (Course Evaluation)

Lecturer presents own ideas of an ideal course structure for this type of engineering course (if a massive budget was available). Students are encouraged to comment and make suggestions. Time is provided for formal course evaluation forms to be completed.

Essay Assignment

The essay assignment is handed out near the middle of the first semester, once students have grasped some of the fundamental concepts and terminology related to embedded system development. The essay is an initial step that leads towards the subsystem prototype project, in which students form groups to devise a system concept, for which they will prototype a small component of the system (see next section for further details).

For this assignment, the student needs to write a short essay on one of the latest technologies which has application to embedded system development. The technology does not necessarily have to have broad application to embedded systems in general -- in fact, students are recommended to look at a specialized technology that they find particularly interesting. The essay can can also focused on a particular application domain, such as high-end military systems, avionics, commercial multimedia products, etc. In writing the essay, the student is not required to have a perfectly detailed understand how the technology works; rather the student should focus on demonstrating a general understand of what the technology is, and give examples of it use, in addition to figures. The essay must be between 3 and 10 pages (including diagrams). Language, grammar, and writing style count towards the essay mark. The Table 2 gives suggested essay topics.

Table2: Technology Examples

Systems On a Chip (SOCs)

Reconfigurable hardware

Real-time embedded operating system

(e.g. WinCE, Embedded Linux, etc)

A new COTS product

(commercially off the shelf complete subsystems)


A new type of engineer-friendly emulator

New type of microprocessors/microcontrollers

Latest Palmtops

A new kind of hardware component (e.g. a new kind of ultra high capacity capacitor)

New design strategies (such as model integrated computing)

Paper-based Evaluation

Paper-based evaluation strategies for this course are split into three parts: class quizzes, practical assignment solution sheets, and end-of-semester examinations.

Class Quizzes

The class quizzes will be announced a lecture before it is given. The quizzes will be done in the first 10 to 15 minutes of the lecture on the days they are scheduled (Note: extra time will not be given to students who arrive late, as this is disruptive to the lecture). Although the quizzes are not a DP requirement, everyone is recommended to complete them. Quizzes do not count towards the final mark, but may be used by the lecturer and external examiner to decide whether a borderline student should pass or fail.

Practical Assignment Solution Sheets (PASSes)

Each laboratory practical has an accompanying practical assignment sheet (or PASS). Students can work on laboratory practicals either in a team of one (i.e. individually), or in a team of two. The PASS is used to answer questions asked in the laboratory assignment. Each team must submit one (and only ONE) PASS with their student numbers filled in on it. The answers filled in on the PASS counts a small percent of the final mark, and are used mainly to prove that a certain student has completed all practicals.

Written Examinations

Two 1˝ hour, examinations will be given; these will comprise the following structure:

  1. Short questions: calculations, filling out a table, connecting dots, short paragraph answers.

  2. Multiple choice: select one of five options (A to E)

  3. Long question(s): complex calculations, UML model, debugging an algorithm, writing code, short essay (e.g. explaining benefits and drawbacks of certain debugging tools, etc).

Practical Component

The plan for this course is to have a single project which is broken into multiple milestones that need to be submitted by a specific due date. The laboratory practicals are intended to provide support and enabling knowledge which students will build on, in work done on the main project.

Laboratory Practicals

There are six official laboratory practicals. These practicals are intended to provide students with new capabilities to solve implementation problems encountered during project work. The practicals can be done individually, or in groups of two. The lab facilitator will ask random individuals to demonstrate how certain problems are solved; this tactic is used to discourage cheating. Each laboratory has a corresponding Practical Assignment Solution Sheet (PASS) that students must fill out during the laboratory exercises, and this must be submit to the laboratory facilitator at the end of the laboratory. The PASS forms are used to determine which students attended the laboratory.

The first practical, and the first part of the project, are focused on using the Embedded System Artifact Organization and Adaptation (ESAOA) framework to develop a simple application for the host (i.e. for a PC). The second prac introduces the CSB337 Evaluation Board from Cogent, and involves developing a simple ANSI C program using the ESAOA framework, and compiling, upload and executing the application on the CSB337. The third practical involves controlling on-board peripherals. The fourth practical involves writing ARM assembly language. The fifth prac involves interrupts and wiring an ISR to handle interrupts assignment generated by an on-board peripheral. The sixth, and final, practical involves setting up uCLinux (a version of embedded linux) on the CSB337 evaluation board. An optional seventh prac, which does not count for the DP, involves using a uCLinux device driver to control an on-board peripheral under Linux. Table 3 provides details of what each practical involves.

Table 3: Laboratory Practicals




Prac01: Getting Started With GCC and ESAOA on Linux

1) Basic Linux commands, 2) ESAOA framework, 3) ANSI C, 4) X on Windows (Kdevelop IDE and ESAOA), 5) GNU development tools (GCC compiler, linker, etc), 6) building projects, and debugging programs.


Prac02: CSB337 & MicroMonitor

1) Set up the Cogent CSB337 evaluation board, 2) Compile a simple “Hello World” program, 3) Linker script and memory maps, 4) upload executable to CSB337, and 4) run program.


Prac03: AT91RM9200 PIO

1) Set-up peripherals, 2) Configure Power Management Controller (PMC), 3) Program parallel input and output lines, 4) flash LEDs depending on pushbuttons used.


Prac04: ARM assembly

1) Simple assembly function, 2) Assembling modules (using arm-elf-as), 3) Integrating assembly module and C modules, 4) Using the GCC in-line assembler, 5) Implement accurate pause function in assembly.

Prac05: Interrupts

1) About interrupts on the AT91RM9200, 2) Setting up the Advanced Interrupt Controller (AIC) and changes to the Power Management Controller (PMC). 3) Writing an assembly ISR that makes a call to a C ISR.4) Entering and returning from interrupts. 5) Writing a ticker interrupt-based routine.

Prac06: uCLinux

1) Setting up the uCLinux kernel (requires lots of disk space!! Maybe just follow the motions, not the compile). 2) Modifications to MicroMonitor to net-boot uCLinux. 3) Net-booting uCLinux, 4) Compiling and running a simple “Hello World” application on uCLinux.

Prac07: uCLinux and Peripherals *

1) About the memory driver, 2) using the memory driver with ESAOA, 3) installing the driver on uCLinux, 4) writing code to control peripherals using the memory driver, 5) testing.

* Optional, not for marks, practical for those using uCLinux to implement subsystem prototypes.

The Project

The project runs for the length of the course, and it is divided into three parts, each part involving additions to the previous parts. The projects count for 50% of the course mark, but the three parts of the projects increase in order of complexity. The first part is quite simple, and involves developing a simple, packet-based communications which will initially run on the PC, and later be used to transmit and receive data between a host application and an embedded application. This part involves writing a PC-based user-interface, and a PC-based processing application (that simulated the embedded application). These two applications communicate using an ESAOA channel.

The second part involves porting the first part to the CSB337 evaluation board. This may sound trivial, but believe me, it is not.... for this it is necessary to develop an RS232 channel driver to replace socket driver used on the PC. In addition, the LEDs and pushbuttons on the board need to be controlled.

The third part is significantly more involved. During the first semester, the students start a conceptualization process, in order to come up with a hypothetical product that they, as a virtual company, could develop. Although they need to come up with a complex product idea, they do not need to develop the product, only produce: 1) a selection of use-cases, 2) high-level UML design including one class diagram and one statechart, and 3) a (rough-and-ready) subsystem prototype (e.g. using an ADC to sample a signal from a signal generator, some processing code, and display/control via user interface). The third part of the product is essential intended to follow the embedded system lifecycle from the conceptualization/brainstorming phase, through RT-UML modeling and implementation to (simulated) acceptance testing. Students are recommended to reuse code developed in the previous parts (parts 1 and 2 are intended for students to experience design reuse).

The students will present their product concept to the class in a series of short presentations. Slides and a digital poster of the concept must be submitted to the lecturer to be placed on the web. Students are required to include references in both slides and poster. The students are required to use the CSB337 as the target to develop the subsystem prototype. Additional hardware is limited to that which has been set aside for the course, and includes periphrals such as ADCs, DACs, and IR transceivers (although students are welcome to purchase and use their own components in their system, or submit requisition requests to the lecturer, pending the lecturer's approval).

Each part of the project is divided into milestone (MS) deliveries. The parts of the project, and the milestones for each part are described in the Table 4. The prac column in the table indicates which practical needs to be completed in order to complete a particular milestone.

Table 4: Parts of The Project and Milestones






Part1: Algorithm and Packet Protocol.

Students are given a problem and need to develop an algorithm to solve it. Sample data is provided. Program can be tested using different data. Individual work.


ESAOA provides a channel abstract module. This can be used to send and receive raw data. For the first milestone, they need two programs, one reads the sample data from a text file, send it through a pipe. The second application reads the data from the pipe, adds all the bytes received, and sends the result of the addition through a second channel to the first application for display.



The algorithm needs to be implemented and replaces the adding method used in MS1.1. A simple packet protocol needs to be devised with header STX, code, ETX to do a checksum.


Part2: Port to CSB337

Students need to port the applications developed in MS1.2 to run on the CSB337. They also need to make the LEDs and pushbuttons operate as required.


Data processing application running on CSB337, user-interface application running on Windows/Linux PC.



PIO is being used in the project to flash LEDs and handle pushbuttons.



Part 3: Subsystem Prototype

Students need to undergo the conceptualization process and come up with a system design. The essay is intended to start them looking for interesting topics. They are then required to post a system idea on the Concepts Forum. The concepts forum is used to decide how to form groups, and accept ideas. Students then develop slides and posters for the concepts. Then they decide on a subsystem to implement. Then they develop designs, a rough prototype and then demonstrate the prototype in a simulated Factory Acceptance Test (FAT).


Post initial concepts


Finalize groups of three


Submit use-cases and block diagram, decide which subsystem to prototype. Start implementation of prototype.

4, 5, 6


Submit high-level design and initial schematic, focusing on subsystem chosen.


Factory acceptance test and final hand-in.

Note RE Part 3: The implementation of the prototype should be started as early as possible, allowing the developers to refine the design from an early stage. Ideally, the three members of the group should each be responsible for specific tasks, such as member 1 does the high-level design (and signal processing methods), member 2 does the circuit (and device driver), and member 3 works on the user-interface and communications. As the students get through more of the practicals, their ability to use the CSB337 and tools will grow, and they can incrementally refine the prototype implementation based on these growing capabilities.


Lecture nodes will be available on the website. Two remotely accessed Linux server will be available to students. Ports of the ESAOA framework, development tools, and other software will be installed on these machines. Students may also install this software on their own machines. Windows-based software has been set up in the Daimler Chrysler lab in order to connect to the Linux server, and to interact with the CSB337 boards.

1Excuse the pun on Advanced Risk Machine

Navigation: [Start]

Copyright (c) 2006, S. Winberg, University of Cape Town. Site maintained by: S. Winberg, Department of Electrical Engineering, University of Cape Town.