Session
PROBLEM-BASED LEARNING IN AN INTRODUCTORY COMPUTERENGINEERING COURSE
Aaron Striegel1 and Diane T. Rover 2
Abstract  As systems increase in complexity and
technology advances, curriculum and laboratories are
challenged to keep pace. This is especially true in computer
engineering, which has seen dramatic growth in the scope
and diversity of computer-based systems. One of the key
challenges is developing the educational context for the new
technologies, which are being encountered earlier and
earlier in a student's program of study. Problem-based
learning has been central to engineering education, and it is
particularly relevant to the integration of new system design
concepts and technologies into introductory courses. In this
paper, we describe steps taken at Iowa State University to
revitalize a sophomore level course in embedded systems by
addressing the type and extent of problem-based learning
used in the course. Our goal was to develop a more
interesting and relevant integrated classroom/laboratory
experience for the students. We present the revisions in
terms of the "3C5I" model, which creates an educational
context based on Concepts within Courses within a
Curriculum (3C), and in each, progressing along the five
"I's" of Introduction, Illustration, Instruction, Investigation,
and Implementation. Problem-based learning may extend
through to either Investigation or Implementation, and in
each case, to differing degrees, depending on the scope of
the problem. In the revised class, we use both, with a realworld theme guiding weekly labs that culminate as parts of a
final project. We examine student learning and experiences
with the thematic labs as well as the effects of several other
changes such as competitive programming exercises and
alternative evaluation methods.
Index Terms  problem-based learning, learning
objectives, computer engineering education, embedded
systems, theme laboratory.
INTRODUCTION
As systems increase in complexity and technology advances,
curriculum and laboratories are challenged to keep pace.
One of the key challenges in computer-engineering
education is developing the educational context for the new
technologies, which are being encountered earlier and earlier
in a student's program of study. Problem-based learning has
been central to engineering education, and it is particularly
relevant to the integration of new system design concepts
and technologies into introductory courses. In this paper, we
describe steps taken at Iowa State University to revitalize a
sophomore level course in embedded systems by addressing
the type and extent of problem-based learning used in the
course. Our goal was to develop a more interesting and
relevant integrated classroom/laboratory experience for the
students.
A starting point for thinking about learning in the
classroom is Bloom’s Taxonomy [1, 2], which categorizes
learning objectives and outcomes into six levels:
• Knowledge – recalling previously learned
information;
• Comprehension – understanding the meaning;
• Application – solving problems using information;
• Analysis – examining information and making
inferences;
• Synthesis – creatively applying or integrating prior
knowledge; and
• Evaluation – making judgements about information
and ideas.
Problem-based learning (PBL) aligns with this taxonomy,
but goes farther by having a problem drive the learning.
Before students learn some knowledge they are given a
problem. The problem is posed so that the students discover
that they need to learn some new knowledge before they can
solve the problem. [3] For example, in guided design, a case
is posed, and small groups work cooperatively using
structured problem-solving to make decisions. Activities are
structured in advance, and feedback is given after each
activity. PBL often includes many principles that improve
learning, such as active learning, cooperation, prompt
feedback, diverse learning styles, and student empowerment
and accountability.
We have introduced a model called 3C5I that
incorporates both Bloom’s levels and PBL. The 3C5I model
creates an educational context based on Concepts within
Courses within a Curriculum (3C), and in each, progressing
along the five “I’s” of Introduction, Illustration, Instruction,
Investigation, and Implementation. Table I lists the 5I
learning steps and their relationship to the Bloom and PBL
learning models. Problem-based learning may extend
through to either Investigation or Implementation, and in
each case, to differing degrees depending on the scope of the
problem. In our embedded systems course, we use both
Investigation and Implementation with a real-world theme
guiding weekly labs that culminate as parts of a final project.
1
Aaron Striegel, Department of Electrical & Computer Engineering, Iowa State University, Ames, IA 50010 adstrieg@iastate.edu
Diane T. Rover, Department of Electrical & Computer Engineering, Iowa State University, Ames, IA 50010 drover@iastate.edu
This work was supported in part by the National Science Foundation under grant no. ACR-9624149.
2
0-7803-6669-7/01/$10.00 © 2002 IEEE
November 6 - 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
1
Session
The general learning objectives for the course include:
TABLE I
LEARNING MODELS AND 3C5I
5I Learning
Bloom’s Levels
Problem-Based
Steps
Learning
Introduction
–
Problem,
Conceptualization
Illustration
–
Instruction
Knowledge
Process Skills,
Comprehension
Subject Knowledge
Investigation
Application
Active Learning,
Analysis
Problem-Solving
Implementation Synthesis
Creative Thinking,
Evaluation
Critical Thinking
COURSE OVERVIEW
The introductory computer engineering course on embedded
systems, CprE 211– Introduction to Microcontrollers, was
reviewed by the department during preparations for its Fall
2000 ABET accreditation review under EC2000 [4].
Beginning Fall 2000, a small team of faculty, staff, and
graduate and undergraduate students began a project to
upgrade the laboratory for the course [5, 6, 8]. In
coordination with this, changes also were underway to
transition the course from a traditional to a more active
learning environment.
CprE 211 has the following course description:
Logic families. Documentation standards.
Implementation and testing of combinatorial and
sequential systems and subsystems. Introduction to
microcontrollers. Microprocessor registers, memory,
and programmable input/output devices. Interrupts.
Single chip controllers. Design and testing of software
for microcontrollers. Hardware/software design
tradeoffs and issues. Individual design projects.
Prerequisites include introductory programming and digital
logic. The class meets three hours every week. The
laboratory meets once weekly for two hours. By the end of
the CprE 211 course, students should be able to:
•
•
•
•
•
•
•
Demonstrate knowledge of a microcontroller and
how it operates
Program in C and assembly code
Understand how C is converted to assembly code
Understand basic concepts of microcontrollers
Understand basic computing concepts such as
interrupts, interrupt service routines, and
input/output (I/O) subsystems
Perform basic hardware and software debugging
Work with and design basic embedded systems
1.
2.
3.
4.
5.
Enable the student to design software to interact
with real-world systems
Familiarize the student with interfaces between the
real-world and a digital system
Provide the student with information to work
effectively in the laboratory
Familiarize the student with typical engineering
activities
Provide students with the interactive skills needed
to work in groups
Traditional Learning/Laboratory Model
CprE 211 was not unlike most courses in the department,
having a traditional, subject-based learning environment.
Delivery was to large lectures (80-120 students) in typical
lecture format.
Instructor-student and student-student
interaction during a lecture was typically in the form of
questions regarding the material, and the class would follow
various examples on the board. Homework or optional
exercises were given to reinforce concepts covered in
lecture. The course webpage listed the syllabus, required
readings, homework exercises, and labs.
Course concepts were also covered in the two-hour
weekly laboratory. Each week, students were assigned a
prelab that involved writing pseudocode or code for the lab.
The prelab was due at the beginning of the laboratory
session. During the lab session, students implemented,
tested, and debugged their prelab solution and demonstrated
a final solution to the lab instructor (a graduate or
undergraduate teaching assistant). The lab topics consisted
of self-contained labs mirroring concepts covered in the
course lectures. In most cases, students would see concepts
in lecture at least two class periods before working with it in
the lab. Table II lists a set of topics representative of a
traditional laboratory organization for CprE 211.
Lab
1
2
3
4
5
6
7
8
9
10
TABLE II
TRADITIONAL LAB ORGANIZATION
Topic
Concepts
TTL circuits
Combinational logic,
breadboard wiring
Advanced TTL circuits Finite state machines
Introduction to C
C programming
Turn Signal
Embedded C programming
Elevator
Embedded C programming
Keyboard
Basic input/output,
assembly programming
Turn Signal
Timing, assembly
Keyboard
Advanced I/O, C
Real-Time Interrupt
Interrupts in C
Real-Time Interrupt
Interrupts in assembly
Lab Final
Comprehensive
0-7803-6669-7/01/$10.00 © 2002 IEEE
November 6 - 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
2
Session
Although such a lab-oriented course is by nature a
hands-on learning experience for the students, the course
model was not leveraging the full range of active learning,
especially problem-based learning.
Improving the Course Model
The traditional model – lecture presentation, subjectknowledge acquisition, hands-on laboratory – provided
students with the basic knowledge required for the course.
However, in terms of engaging the students and
incorporating contemporary learning principles, the model
fell short. Thus, our goal was to develop a more interesting
and relevant integrated classroom/laboratory experience for
the students. Extensive work on learning in the educational
community, as well as Iowa State University’s decade-old
Project LEA/RN [7], served as a basis for our developments.
We decided to target four elements of the course model
for improvement:
• Classroom learning environment: The lecture
component should use active learning, cooperative
learning, and problem-solving to engage students,
spanning the four “I’s” from Introduction to
Investigation.
• Laboratory experience: The laboratory component
should be organized along a real-world theme, making
weekly labs more cohesive and relevant. A thematic lab
starts with a problem and supports all five “I’s” as part
of problem-based learning.
• Real-world examples: The course should introduce realworld examples as the basis for further investigation and
implementation, giving students an opportunity to
explore actual systems, devices, and applications.
• Course website: The course website should be an
informative and connective resource for students,
including course notes, FAQs, assignments, knowledgebuilding resources, skill-building resources, assessment
tools, etc.
These elements are addressed in the following sections in the
context of the 3C5I model and problem-based learning.
3C5I MODEL
We present a representative set of revisions to CprE 211 in
terms of the 3C5I model, i.e., considering different
perspectives of Course, Concept, and Curriculum (3C) as
well as steps ranging from Introduction and Illustration to
Instruction, Investigation, and Implementation (5I).
Course Perspective
One perspective from which to view a learning environment
is the spectrum of the course, especially in meeting its
educational objectives. For example, one of the general
learning objectives for CprE 211 is to enable the student to
design software to interact with real-world systems. This
objective corresponds to one of the elements that we targeted
for improvement: real-world examples.
Real-world
examples should motivate students to develop a deeper
understanding of practical issues in embedded programming.
Although we incorporated real-world examples in
several ways, we discussed examples in the classroom from
day one. After defining a microcontroller and introducing
the platform to be used in the course, MPC555 (PowerPC
microprocessor core, or CPU, central processing unit),
students were asked to find an application that uses a
PowerPC CPU. One application that was identified is the
Nintendo GameCube™. Another is a Motorola driver
information system called mobileGT. These types of
examples beg the question, how does a microcontroller
support the functions and features of these systems? Starting
with a real-world introduction and illustration leads the way
into the subject matter of embedded programming for the
PowerPC.
The course continued with instruction on programming
the PowerPC microprocessor, and students investigated
topics through in-class activities and homework and
laboratory exercises. Thus, the flow of the course used a
series of 5I steps. Later in the course, students were
surveyed to rate how well each of the learning objectives has
been covered. Often this reflects how frequently and how far
the 5I steps have been followed in relation to a particular
objective.
Concept Perspective
FIGURE 1
POWERBOX: POWER PC-BASED PLATFORM
Another perspective from which to view a learning
environment is at the level of a concept. For example, one of
the important concepts in CprE 211 is input/output (I/O) and
how a microcontroller interfaces to the real-world, whether
reading keystrokes by a user or temperature from a sensor.
This concept is addressed in the classroom using cooperative
learning techniques that step through to Investigation; and it
is also emphasized in the laboratory with both Investigation
and Implementation. Here we take a look at the classroom
approach.
0-7803-6669-7/01/$10.00 © 2002 IEEE
November 6 - 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
3
Session
As shown in Table II, the keyboard is a means to study
I/O. Two keyboards are shown in Figure 1, a photo of the
platform used in the laboratory. The keyboard example
demonstrates how we improved the integration between the
classroom and laboratory. First, while reviewing C
programming, we provided one page of C code that sets up a
keyboard interface. The keyboard code included
programming constructs such as pointer and array data
types, control flow using bit-testing, and function calls. This
became the problem: how does software read a keyboard?
Then we used the keyboard interface to guide a cooperative
learning lesson covering both programming and I/O. Base
groups were used, consisting of 2-3 pairs of laboratory
partners (i.e., 4-6 students); these also facilitated skill
development for a group project in the laboratory.
Using the keyboard example as an illustration, we
introduced a device’s programming interface consisting of
status and data registers. But before focusing on the I/O
interface, we used the example to learn about embedded
programming in C. More specifically, base groups
completed the following tasks:
• Read the code and mark the constructs as known,
being studied, or not yet covered.
• Draw a diagram of the keyboard layout.
• Browse class notes on a specific embedded
programming topic. Five topics were listed:
pointers, functions, control flow, I/O, and compiler
directives.
• Discuss as a group the topic in relation to the
keyboard example.
• Answer a question on the topic and be prepared to
share the answer.
• Listen and contribute to class discussion.
As the base groups worked on answering the question, often
additional questions were raised, which led to deeper as well
as broader coverage of the programming and interfacing
issues than would have resulted from a traditional lecture.
The students reached an investigative level of learning, as
oppposed to simply instruction.
This learning was then reinforced and extended through
subsequent course activities, including writing code for a
keyboard in the laboratory (and dealing with complex
hardware-software interfacing issues such as debouncing),
seeing the keyboard code on exams, and studying assembly
programming via the same example.
Curriculum Perspective
A third perspective from which to view a learning
environment is within a curriculum. For example, the
prerequisite structure between courses in a program reflects
linkages. CprE 211 is part of a “learning pipeline,” as shown
in Figure 2. Students will engage in different levels of
learning at each stage of the pipeline.
Courses in the pipeline include:
1) ComS 227: Introduction to Computer
Programming (not shown)
2) CprE 210: Introduction to Digital Design
3) CprE 211: Introduction to Microcontrollers
4) CprE 305: Computer Organization
5) CprE 308: Software Systems (Operating
Systems)
6) Senior-level design courses (electives and
capstone) (not shown)
For example, one of the paths – 227, 211, 308 – takes
students from programming to embedded programming to
systems programming. Along this path, a subject such as bitmasking is first introduced in 227, with instruction and
investigation in 211. A more advanced subject, such as
multitasking, is introduced in 211, with subsequent steps or
levels of learning in 308. Another path – 210, 211, 305 –
takes students from digital logic to digital systems to
computer system architecture. Subject flows can be
identified here as well:
Introduction/Illustration
Tri-stating:
210
Instruction decoding:
211
à
Instruction/Investigation
à
211
à
305
The senior-level design courses typically provide some form
of implementation experience for advanced subject matter.
Obviously, CprE 211 serves specific functions to help
students learn across the curriculum. Recognizing the role
of a particular course as well as the relationships between
courses in terms of the 5I model is one means to improve
the learning environment.
FIGURE 2
CPRE PROGRAM: COURSE FLOWCHART RELATIVE TO CPRE 211
PROBLEM-BASED LEARNING IN THE
LABORATORY
In addition to upgrading the laboratory facilities for CprE
211, we focused on improving the laboratory experience, in
particular by enhancing the problem-based learning. We
organized the laboratory along a real-world theme, making
weekly labs more cohesive and relevant. A thematic lab
starts with a problem and supports all five I’s as part of
problem-based learning.
A real-world theme is selected for the laboratory project
each semester. Recent themes in the CprE 211 laboratory
have included an alarm system, vehicle dashboard system,
and a police cruiser information system. With the theme
0-7803-6669-7/01/$10.00 © 2002 IEEE
November 6 - 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
4
Session
approach, the theme is introduced as the background for a
series of weekly laboratories, each of which has its own
objective, deliverables, and evaluation criteria. However,
each of the individual labs is developing student interest,
knowledge, and skills, and resources to be applied to a final
lab project. For example, the weekly labs for the police
cruiser information system were:
Lab 1. Introduction to CodeWarrior/PowerPC
Lab 2. Digital Logic & I/O Interfaces
Lab 3. Car Odometer
Lab 4. Glove Compartment Lock
Lab 5. Police Cruiser Light Control
Lab 6. Introduction to Assembly on the
CodeWarrior/PowerPC Platform
Lab 7. 7-Segment Display Decoder
Lab 8. Police Cruiser Communications: Serial
Query/Response Terminal
Lab 9. Police Cruiser Speed Radar: A/D I/O
Lab 10. Real-Time Interrupts
Labs 3, 4, 5, 8, and 9 were explicitly tied to the police
cruiser and students were informed that these lab
components would be re-used and integrated into a final
project. About halfway through the labs, students were
formally introduced to the project, including resources on
effective teaming and group-building activities in the
classroom and laboratory (e.g., peer review of code).
The lab project was divided into two parts: System
Integration (required) and System Innovation (optional).
System Integation involved combining previous labs from
the semester to implement a multi-function cruiser
information system. This required the base groups to use at
least one code module from each lab partner pair in the
group. System Innovation added new functionality with
features to customize or enhance the system above and
beyond the required System Integration part. The optional
part of the project was included to challenge students.
During the first offering of the course with a thematic
project, the students were given a strict list of requirements
for the implementation. While the checklist approach
worked well to evaluate proficiencies, it did not set a very
high bar for creative thinking and problem-solving. Thus, in
subsequent offerings, we adapted the grading criteria for the
project to include both required and optional parts. The
project base grade (70%) corresponded to the required
System Integration part. The remainder of the grade (30%)
corresponded to the System Innovation part. Groups could
choose not to complete the System Innovation part of the
project, resulting in a maximum grade of 70% out of a
possible 100%. For the System Innovation part, groups
would deliver the features they deemed necessary to merit
the extra 30% of the grade. In addition, groups were
rewarded for early completion of the project and penalized
for late submissions.
The optional part of the project allowed the students to
experience real-world engineering. Groups were given a list
of potential features to use as a starting point but were not
given a specific number of features to implement. In
addition, groups could explore topics without the overhead
of implementing all features to completion. The objective of
the so-called “dazzle me” part of the lab was to motivate
students to try something new, to differentiate their solution
from other solutions, and to challenge themselves. The
ambiguity of the optional component was key to
accomplishing this. Rather than strictly assigning points to
features, the students needed to justify to the instructor or
TA why certain features are worth certain points. Thus, the
project adapted to address the diverse abilities of students
and provide opportunities for higher levels of learning.
The thematic lab approach has provided other benefits
as well. Integrating earlier labs forces students to think about
issues of code re-use, rather than designing with a
write/throw-away mentality. It also makes a larger software
project feasible, which introduces students to issues in
project management and software engineering found in later
courses.
The thematic projects have met with resounding
success. With the option to specify features for an “A”
grade, students challenged themselves to deliver quality
work, rather than simply jumping through the required
hoops. Student self-assessment of their work proved to be a
useful learning experience in itself, especially in estimating
the value of their efforts and outcomes. In addition, the
innovation was often impressive. Examples of innovative
features include:
• Games/screen-savers on a 2x20 LCD screen
• New LCD drivers in assembly code with optimization
of refresh/clear operations
• Multi-threaded operating system for the vehicle
dashboard system
• Interface to a flashing light (actual police light) through
digital output and to siren sound through an audio chip
and speaker for the police cruiser information system
Despite the increased workload, many students rated the
final project as highly valuable and satisfying. Students
stated that the project helped bring the class together.
Several students indicated that they discussed the project in
job interviews as well.
The following considerations were important to
managing a thematic lab. Facilities, equipment and staffing
must be set up to support the project, as student demands
will be greater than for a traditional lab. Second, student
nature is to leave the project to the last minute. Reserving
lab time for project work was not sufficient, as students
often used the time to finish other labs or classwork.
Specifying milestones and deliverables with deadlines as
well as early completion bonuses were more effective.
SUPPORT FOR ACTIVE LEARNING
Cooperative learning was an important element of problembased learning in the laboratory. However, we also
emphasized cooperative learning in other class activities.
0-7803-6669-7/01/$10.00 © 2002 IEEE
November 6 - 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
5
Session
An example lesson plan was already presented in the section
on Concept Perspective. In addition, students were
encouraged to use their base groups, or groups of the
students’ choice, on homework and programming exercises.
The turn-to-your-neighbor technique was commonly used in
the classroom.
Problem-solving in the laboratory was complemented
with knowledge- and skill-building via programming
exercises (longer homework problems). Although to a lesser
extent, we tried to emulate aspects of the lab in the
programming exercises, such as the use of real-world
examples and performance incentives.
For example, students were given a real-world problem
specification and asked to write the code using either C or
assembly. Examples included a simplified IP router and a
serial HART protocol. In addition to writing the code,
students also prepared a short executive summary based on
their own research into the topic. This approach to
programming exercises served two purposes. First, the realworld problem kept the work interesting and relevant, letting
students apply basic concepts and skills to actual
applications. Second, the research aspect of the assignment
allowed students to explore information technology more
broadly.
In addition to using alternative grading criteria in the lab
project, we experimented with a competitive grading scheme
on programming exercises. For example, on an assembly
programming problem, we used grading criteria based on the
performance (code size/speed) of the group’s solution.
Groups were graded 80% on correctness of the solution and
20% on relative performance. For each of the two criteria
(code size, code speed), the groups were ranked against one
another and sorted into percentile blocks. For example, a
group in the top bracket of code speed and the second
bracket of code size scored 18% for the competitive
component. We also awarded bonuses of 5% to the top
teams.
The results of the competitive grading on programming
exercises were quite fascinating. Within a group, the
students rallied around a common mission, thus heightening
team spirit. Between groups, students protected their
intellectual property. For example, during one three-week
programming exercise, groups avoided sharing solutions and
comparing benchmarks with one another. However, the
instructor-student interaction was substantial, since students
frequently asked for feedback on their performance results.
In the end, the groups produced a wide variety of solutions
and were able to meet or exceed the performance marks of
the instructor’s solution. The competitive nature of the
exercise helped students in a number of ways: built
teamwork skills, highlighted design tradeoffs and decisionmaking (e.g., code size/speed tradeoff), provided in-depth
study of assembly code, and motivated the need for
assessment.
Finally, experience and feedback have shown that the
course website is an important element of the learning
environment. We have focused on the following needs and
improvements.
• Post class notes in advance. Since a cooperative
learning model is used, expectations for class attendance
have already been established. Having notes in hand
lets students think rather than write. We’ve also noticed
that it is especially helpful to international
undergraduate students.
• Maintain a Frequently-Asked-Questions (FAQs) page,
with answers to common questions. This requires
moderate maintenance and may seem trivial, but
students find it informative and re-assuring.
• List all due dates.
• Keep website current. This requires daily maintenance,
which is difficult.
• Make feedback forms available. These may be
distributed at selected times during a semester. They
remind students about learning objectives and provide
feedback on the learning environment.
IN SUMMARY
This paper describes several practical approaches to
incorporate problem-based learning in an introductory
computer engineering course on embedded systems. It is an
account based on our observations and instructor-student
interactions. Our goal was to integrate classroom/laboratory
experiences and bring new system design concepts and
technologies into an introductory course. We targeted four
elements of the course for improvement: classroom learning
environment, laboratory experience, real-world examples,
and course website. We used the 3C5I model as a context for
presenting the practices applied to support the learning
environment.
REFERENCES
[1]
B. Bloom and D. Krathwohl, editors, Taxonomy of Educational
Objectives: The Classification of Educational Goals, Handbook I:
Cognitive Domain, by a committee of college and university
examiners, New York, Longmans, Green, 1956.
[2]
L. Anderson and D. Krathwohl, A Taxonomy for Learning, Teaching
and Assessing: A Revision of Bloom's Taxonomy of Educational
Objectives, New York, Longman, 2001.
[3]
D. R. Woods, Problem-based Learning: Helping your students gain
the most from PBL, Waterdown, Canada, 1995. See also
http://chemeng.mcmaster.ca/pbl/pbl.htm
[4]
CprE 211 website, http://class.ee.iastate.edu/cpre211/01fall/, Fall 2001
[5]
ISU EE/CpE Senior Design website, http://seniord.ee.iastate.edu/
[6]
Cpr E 211 Senior Design website,
http://seniord.ee.iastate.edu/dec0104/, Fall 2001
[7]
Project LEA/RN (Learning Enhancement Action/Resource Network),
Iowa State University, Feb. 2000,
http://www.educ.iastate.edu/ess/learn.htm
[8]
A. Striegel and D. Rover, “Enhancing Student Learning in an
Introductory Embedded Systems Laboratory”, Proc. 32nd ASEE/IEEE
Frontiers in Education Conference, Boston, Nov. 2002.
0-7803-6669-7/01/$10.00 © 2002 IEEE
November 6 - 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
6