I’m teaching embedded systems programming for the first time this year.  The only other programming course I’ve taught used PLCs and a “ladder-logic” style language.  The students and I thought it was going well until most people bombed the mid-term.  I’m trying to improve on students’ ability to predict what a program will do in the hopes that it will help them make better design and debugging choices.

I start by issuing every student a PICDem 2 demo board (mostly for historical reasons — evaluating other embedded systems in a project for next summer, so feel free to throw your suggestions in the comments). C is not high my list for students who’ve never programmed before — especially not embedded C.  But there you have it.

On the first day, I started by handing out the boards and getting everyone to push all the buttons.  I hand out a worksheet that asks students to explore the board.

The worksheet asks students to

• Make a list of everything the demo board can do (to get them thinking about the feature set)
• Find some of the important hardware on both the PCB and on the schematic (to build fluency with switching between the two)
• Keep track of questions that come up while they do that (in a style slightly reminiscent of Cornell notes or Cris Tovani‘s double-entry diary technique for reading comprehension.  Is it fair to call this “reading” the board?)

When everyone had had a good time making shrill buzzer noises, I went around the room gathering every feature we could think of, and gathering questions too.    If you want to see what my students are curious about, take a look at our mind map (names removed) and click on the “Programmable Systems” section.  Highlights:

• How does the micro convert an analog voltage to 0s and 1s?  Does it add in tiny increments?  There’s gotta be some kind of estimating — it must round.
• What’s the other number shown on the LCD beside the voltage?  It goes from 0 when the pot’s turned all the way down, to 1023 when it’s turned all the way to 5V.  It’s 511 when the voltage is 2.5V.  So that’s got to be 1 byte of something.  [Bless the heart of the demo app designers who put the raw A/D count on the display — M.]
• How do you change the frequency of the buzzer?  Is it an LC circuit?
• Is it using a timer to control the time between the buzzer voltage transitions?
• What would happen if you changed the duty cycle?
• Is there a counter?  Where is it?
• So it doesn’t really know what time it is — it’s just counting oscillator transitions since it was turned on.

 

I love the way they’re making connections to their course work on digital systems (counters, timers, relationship between frequency and duty cycle, the significance of 1023) and AC circuits (LC oscillators).  They’re asking relevant questions, making significant observations, making supported inferences, and getting excited about figuring out “what makes it do that” (which might be my “mantra” for the program).  These questions will drive my approach to the next few weeks.