Now that the classes are winding down, I want to write up some internet-accessible notes about the embedded systems unit I designed and taught for EGR199 this semester. The unit went well, and I can see basically the same materials being reused, so having a nice content dump for me or any other instructor to use is worth the effort. Long winded version after the fold.
A little background on the course: UK has restructured their general studies requirements a bit, and our old one hour EE101 professions seminar was “not well regarded” by students or faculty, so the department took this as an opportunity, and is experimentally offering an EGR199 “Creativity and Design in Electrical & Computer Engineering” course, which is a three credit course replaces the old EE101 and additionally satisfies a humanities requirement under the new system. The course web page (in the primary instructor’s hosting) is here. Because I was known to be a competent TA, I have experience with embedded projects, and I inquired about something interesting to do this semester, I was brought onboard. While arranging the course, I expressed interest in having a little more involvement than a typical TA, so in addition to grading, I also got free reign over a three class (spread out over three weeks) unit on embedded systems.
The class is intended for students early in the program, so the objective of the unit was largely about fun and exposure to working in embedded systems, without being too hard. Teaching them some genuinely useful skills was secondary but desirable. Because the students experience ranged from first semester to third year, I chose to take a “if some of this goes over your head it’s OK – you’ll see it again later” approach with a lot of the content – I always preferred to be treated that way as an undergrad, and I’ve not seen it cause too much panic as long as you are clear about the intention. The slides I used are available here CC-BY-SA basis, as pdf. They aren’t really free standing, as I brought LOTS of gadgets and dev boards as examples, and did as much actual Arduino work in the IDE onscreen as possible, but as a list of important topics I think they’re solid.
Hardware wise, every group got a kit with an Arduino (Mixture from Diecimilia through UnoR2 boards), USB cable, a mini-breadboard, and pouch with resistors (100Ω, 1KΩ, 10KΩ), LEDs, buttons, and a potentiometer. We also had a pool of “neat” parts (Buzzers, 7-segment displays, RGB LEDs, )One thing I was very insistent about was that that the students got to keep their parts kits for the duration of the unit, so they could play with them. I kept the kit cost intentionally minimal, and the other instructors and department were on-board with that plan, so we made it happen to good effect. The Arduino environment will run almost anywhere (except occasionally when it doesn’t get along with a Java version), so students used their own laptops as development environments.
I broke the topic into three discrete units for the three class periods – the first day was a general introduction to and history of embedded systems, the second was digital interfaces, and the third was analog interfaces.
The first lecture started with a quick hand-wavy introduction to number systems, since familiarity with binary and hex were not givens, while another instructor issued Arduinos to groups of students. The rest of the class was largely spent talking about example embedded systems to introduce concepts. I brought in a wide variety of consumer devices and development boards, and talked about why the particular uC used in the design was good for that application. I tried to coach things in terms of device families and common tools, and talked about accessibility of platforms. In the background of the first lecture, I had them download and install the Arduino environment, then spent the end of class getting them acclimated with the Arduino – explaining the hardware, and making sure every group succeeded in making the hardware and software work with the IDE-provided Blink code. As an end of class + homework assignment, they were asked to do Limor Fried’s Arduino Lesson 2 exercises.
I opened the second class with the concept to product cycle information, especially fabrication issues which are not well covered elsewhere in the program. Everything from breadboard best practices, through CAD tools/wire wrap/board etching/etc. It would be nice to get them to actually build something permanent with soldering and such, but the time and resources aren’t there. The remainder of the class was about digital interfaces – first buttons, switches, pull up/down, bounce, etc. and simple Serial and parallel examples for the remainder. The protocols stuff was mostly conceptual – I talked about 1284 parallel, RS232 and I2C as examples, but the concept of different protocols, with different speed/complexity/robustness was more important than any specifics. To break up the lecture and check comprehension, I had students try the “Debounce” and “DigitalReadSerial” examples during class. As homework, each group was asked to build a tally counter that read from a button and printed to the serial interface, avoiding things like counting as long as the button is held or bounces. Most groups seemed to get it.
The third lecture was about analog I/O. The basic concept of digital v. analog signals, ADC, DAC, and the different implementations and metrics for each each. I think the technical level of this lecture may have been a little much, but the signals content will be easier later with context, so I’m not sure that it should have been lighter. As in the other lectures, I stopped for a while to have every group implement the “AnalogInOutSerial” example in class, and everyone seemed to at least understand the mechanics and how it fit in to devices they had been exposed to. The final homework/project was for them to “Build something cool with what you learned.” They had one week, and access to the cache of parts plus anything they wanted to add. Every group was asked to come up with a concept based on the parts list, and make a nonbinding request for the the parts they planned to use as a sanity check.
Some of the final projects were really neat – anticipation and reflex games, simple color organ like devices, a toy that “argued” with the user over serial based on frequency and number of button presses, and all kinds of other simple but fun gadgets. Embedded systems is one of the ECE areas where it is easiest to go wild creativley, and Arduinos were designed with that aspect in mind, so this exercise
Several groups also built Arduino gadgets for their class final project, which were in the same vein. Several other final projects used Arduinos to “shim” some problem they had with their design, which is probably the most practical lesson I could have taught them – every engineer should have a go-to microcontroller for building custom tools and testing ideas. I was pleased to hear a lot of students talking about ordering their own Arduino/kit or asking for them as holiday gifts, so clearly I did something right.
We also had them read the (timely) Spectrum article for background and context.
To handle reactions in a carefully FERPA-compliant way, I’m just going to talk about numbered sections reactions. I did it with three sections of the class, two in parallel a couple hours apart, and one after the other two had finished. One section stared at me like dead-eyed zombies, but that seems to be their response to most stimulus. Another section had a mixture of looking at me like I might hurt them and being excited about the toy. The last section, who tend to be the most dynamic in other lessons, were already building their own designs before I was done with the first lecture. There is a certain amount of class variation (for those who have never taught: classes do indeed have personalities) to explain it, but some minor variations in teaching style contributed.
Because I was already aware of the the class variation, I ended up building 60-minute core lessons with two additional 15-minute modules that I could swap in. For example, at the end of the digital lesson, one class got a demonstration at the end of the digital/serial lesson of taking a Bus Pirate and interacting with a Wii Nunchuck over I2C so there was something useful to do with the extra time – another group asked enough questions that we barely got through the base lesson.
A couple useful lessons learned:
- Doing embedded systems as “Let’s play with Arduinos!” really does work.
- Pass out the full kits of components at the start, and let students keep them. – we handed out parts as needed in some sections, and all at once in others, and the “all at once” sections reacted better.
- Inter-class variation is a bitch – as above, the content covered varied by about 30% between sections, just based on classroom personality.
- As quickly as possible, try to transfer the idea that “This is a toy block. You build neat things out of it” via examples. – The latter section got kits with the old code/circuits left on the boards from previous groups, and it really helped.
Overall, student reactions seemed to be positive, I had a good time running the lessons, and I’m pretty sure everyone walked away with useful new skills and knowledge, so, as education endeavors go, a great success.
