ASEE NCS Conference 2019

Full Program »
PDF File
View File

Communicating Microcontroller Communications to Students

Communicating Microcontroller Communications to Students


Teaching Embedded Systems is becoming more complex. Microntroller systems are smaller in size, incorporate more advanced functionalities, and include lower power options modes. Functions are becoming more depended on each other, especially, in the inter-processor communications. The student has to know about setup code, register initialization, clock timing and synchronization along with maintaining low noise hardware connections. Two non-traditional approaches are presented in this article to help students to work more efficiently with these advanced embedded system.

The traditional method to teach microcontroller functions involves lecture and a lab. First, the function is presented in a lecture. This will typically involve some background and review of dependent modules (such as clock and input/output (I/O) setup registers).

Next, the function is incorporated into a lab where the students follow a set procedure to get the function demonstrated to show full understanding. Sometimes the instructions are followed without regard to how or why the systems function like they do. Even experienced designers can just “plug and chug” just to finish the exercise.

Two non-traditional approaches to teaching an embedded system feature are presented which can be applied to all of the embedded system features, one for lecture, and one for lab. The first approach involves more than providing information on a white board or power point, and is easier than requiring the entire class to perform an exercise (similar to another lab). This updated approach incorporates all the students as one big exercise. In the case of processor intercommunications, one processor is the “master’ while all other modules are the “slaves”. By “wiring” up the class with a set of twisted pair wires and several switches, an I2C communication bus can be created with the professor as the master- allowing communication to/from each student.

The second approach targets the lab. An I2C communication lab may involve a processor and another I2C compatible device, like a real-time-clock module. Most students can get this to work by following a well-defined procedure. The key to get real understanding is incorporating the fundamental idea behind I2C communication into another lab- without duplicating the previous lab, or sacrificing a new lab. An example may include a second lab where the processor must drive a DC motor. Instead, the lab can include driving a DC motor, but the command for which direction the motor must turn comes over I2C from a second “master” controller. This way, lessons from a previous lab, can be incorporated into a new lab, where most of the focus is on driving the DC motor. This idea can propagate from lab to lab and reinforce the more complicated ideas in embedded system design.

Brian Krug
Grand Valley State University
United States

Nabeeh Kandalaft
Grand Valley State University
United States


Powered by OpenConf®
Copyright©2002-2018 Zakon Group LLC