Conference PaperPDF Available

Problem-based learning in an introductory computer engineering course

Authors:

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 "Is" 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 real-world 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.
Session F1G
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
F1G-7
PROBLEM-BASED LEARNING IN AN INTRODUCTORY COMPUTER-
ENGINEERING COURSE
Aaron Striegel1 and Diane T. Rover 2
1 Aaron Striegel, Department of Electrical & Computer Engineering, Iowa State University, Ames, IA 50010 adstrieg@iastate.edu
2 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.
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 real-
world 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.
Session F1G
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
F1G-8
TABLE I
LEARNING MODELS AND 3C5I
5I Learning
Steps Bloom’s Levels Problem-Based
Learning
Introduction
Illustration Problem,
Conceptualization
Instruction Knowledge
Comprehension Process Skills,
Subject Knowledge
Investigation Application
Analysis Active Learning,
Problem-Solving
Implementation Synthesis
Evaluation Creative Thinking,
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
The general learning objectives for the course include:
1. Enable the student to design software to interact
with real-world systems
2. Familiarize the student with interfaces between the
real-world and a digital system
3. Provide the student with information to work
effectively in the laboratory
4. Familiarize the student with typical engineering
activities
5. 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.
TABLE II
TRADITIONAL LAB ORGANIZATION
Lab Topic Concepts
1 TTL circuits Combinational logic,
breadboard wiring
2 Advanced TTL circuits Finite state machines
3 Introduction to C C programming
4 Turn Signal Embedded C programming
5 Elevator Embedded C programming
6 Keyboard Basic input/output,
assembly programming
7 Turn Signal Timing, assembly
8 Keyboard Advanced I/O, C
9 Real-Time Interrupt Interrupts in C
10 Real-Time Interrupt Interrupts in assembly
Lab Final Comprehensive
Session F1G
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
F1G-9
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, subject-
knowledge 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 real-
world 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, knowledge-
building 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
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.
FIGURE 1
P
OWER
B
OX
: P
OWER
PC-
BASED
P
LATFORM
Session F1G
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
F1G-10
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 exa mple.
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 bit-
masking 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 à Instruction/Investigation
Tri-stating:
210 à 211
Instruction decoding:
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.
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
FIGURE 2
CPRE PROGRAM: COURSE FLOWCHART RELATIVE TO CPRE 211
Session F1G
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
F1G-11
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 problem-
based learning in the laboratory. However, we also
emphasized cooperative learning in other class activities.
Session F1G
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 9, 2002, Boston, MA
32nd ASEE/IEEE Frontiers in Education Conference
F1G-12
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 real-
world 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 decision-
making (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.
... However, its essential elements, derived from the model developed at McMaster [15][16][17][18][19][20], have been retained. The application of PBL in engineering education has previous works based on the suitability of this teaching methodology for solving specific problems in different specialities: electrical, civil, mechanical, etc. [21][22][23][24][25][26][27][28][29]. As for the application of PBL in the teaching of architecture, it requires appropriate adaptation by specialists in its teaching, given the high weight acquired by the architectural project and where there are related methodologies, but with The theoretical bases of PBL in technical education can be summarised in the following points [30]: ...
Article
Full-text available
El aprendizaje basado en problemas (ABP) es un método de enseñanza que se utiliza cada vez más en la enseñanza técnica. Tanto en la enseñanza de la ingeniería como en la de la arquitectura, el ABP se ha evaluado y ha demostrado su eficacia para mejorar el rendimiento académico de los estudiantes. La necesidad de trabajar en grupo y la limitación del número de alumnos por sesión de ABP requieren el uso de técnicas estadísticas robustas en la evaluación estadística correspondiente. En el presente trabajo se aplicaron dos pruebas estadísticas robustas: la prueba de la mediana y la prueba de Wilcoxon-Mann-Whitney (WMW). Utilizando una muestra de 35 estudiantes del Máster en Ingeniería Industrial de la Universidad de Huelva, distribuidos en tres cursos académicos (2021-22, 2022-23 y 2023-24), se aplicaron dichas pruebas en relación con el rendimiento académico. Hubo un grupo experimental (19 alumnos) y un grupo control (16 alumnos). Se han aclarado los detalles de la aplicación de cada prueba, incluyendo las hipótesis nula y alternativa, los estadísticos respectivos de cada prueba, y se ha resuelto el caso utilizando R. Se demuestra que existe una diferencia significativa en el aprendizaje entre el grupo experimental y el grupo de control, basándose en las pruebas de la mediana y de Wilcoxon-Mann-Whitney (WMW).Problem Based Learning (PBL) is a teaching method that is increasingly being used in technical education. In both engineering and architecture education, PBL has been evaluated and shown to be effective in improving students' academic performance. The need to work in groups and the limitation of the number of students per PBL session require the use of robust statistical techniques in the corresponding statistical evaluation. In the present work, two robust statistical tests were applied: the median test and the Wilcoxon-Mann-Whitney (WMW) test. Using a sample of 35 students of the Master in Industrial Engineering at the University of Huelva, distributed over three academic years (2021-22, 2022-23 and 2023-24), the said tests were applied in relation to academic performance. There was an experimental group (19 students) and a control group (16 students). The details of the application of each test have been clarified, including the null and alternative hypotheses, the respective statistics of each test, and the case has been solved using R. It is shown that there is a significant difference in learning between the experimental group and the control group, based on median and Wilcoxon-Mann-Whitney (WMW) tests.
... Overall, this project can be classified with the efforts of employing the problem based learning (PBL) methodology for embedded systems education and computer engineering education in general [20][21][22] , where students are given a problem with a minimum of resources and direction and asked to analyze and solve the problem. ...
... Problem-based learning (PBL) is a pedagogical practice that has been shown to be effective in science and engineering courses for promoting student learning [1][2][3][4][5][6][7][8][9][10][11] . This approach is also gaining traction as a possible way to promote student motivation and retention in engineering programs [12][13][14] , although research within this regard is still limited. ...
... The application of problem-based learning in engineering education is not new and has been proven to be successful in many programs. 1,2,4,8,10,12 With the assignment described in this paper, we are attempting a form of problem-based learning by assigning a project during the first week of class. This project requires the application of the techniques and methodologies taught throughout the semester and is completed in small groups. ...
Article
Full-text available
As technology advances, curriculum and laboratories are challenged to keep pace. This is especially true in computer engineering, where the range of technologies is constantly broadening and diversifying, as computer-based systems take on many forms and functions in everyday life. The question is, how should a contemporary curriculum train computer-engineering students for the vast scope of embedded system solutions? In this paper, we specifically consider where to begin, and ask, can powerful tools empower students to learn? We describe steps taken at Iowa State University to upgrade a sophomore level laboratory in embedded systems. We migrated from the popular 8-bit Motorola 68HC11 microcontroller as the core for a hardware-software development platform to the emerging 32-bit PowerPC 555 microcontroller. The 68HC11 is used in labs at numerous universities across the country and is supported with textbooks and educational packages. Conversely, the PowerPC is new to the academic environment and comes with a rich set of features and development tools. In this paper, we examine the similarities and differences between the laboratory platforms and their impact on student learning. We also identify strengths and weaknesses of the new laboratory environment, based on our own perspective and student feedback.
Learning Enhancement Action/Resource Network)
  • Lea Project
  • Rn
Project LEA/RN (Learning Enhancement Action/Resource Network), Iowa State University, Feb. 2000, http://www.educ.iastate.edu/ess/learn.htm