Note: “codebook” entries below are verbatim pasting of all of the code we used in class. It’s possible they may not compile (i.e. may have errors) if we left things unresolved, or were writing pseudocode, etc.

Tuesday, Aug. 30th: Intro

  • Welcome to class!
  • Quick introductions: students in random pairs each answer a few questions about each other:
    1. Their name and pronouns
    2. What they’re studying and what year they’re in
    3. What brings them to this class
    4. Something fun/interesting/exciting/great/awful they did over summer
  • Review course Canvas site briefly
  • Review main course site (the one you’re reading this on) briefly, going over the various sections listed in the navigation bar on the left
  • Quick IDeATe walking tour
  • Phys Comp Lab tour
  • Handing out individual Arduini, and beginning of board tour
  • Homework 1 assigned

Thursday, Sep. 1st: Technical learning

  • Going over technical questions asked on the asynchronous lecture discussion board
  • Homework 2 assigned

Tuesday, Sep. 6th: Technical learning, Project 1 assigned

codebook: a bad way of building a toggle switch out of a button

// make a variable to hold the maintained state
int switchState;

const int LEDPIN = 6;

void setup() {
  pinMode(LEDPIN, OUTPUT);

void loop() {

  // if button is pressed right now
  if (digitalRead(BUTTONPIN) == HIGH) {
    switchState = !switchState;

  digitalWrite(LEDPIN, switchState);

Thursday, Sep. 8th: Project 1 discussion

  • Asynchronous questions addressed during class
  • const int is preferred for naming variables that won’t change, like pin assignment numbers
  • See codebook below for some fiddling-around we did looking at the #define command, which is a “preprocessor directive”
  • Most of class is spent talking with Project 1 groups about their ideation submissions

codebook: #define vs. const int, among other things

Note: this was left super incomplete! In class we discussed how our in-class style prefers using const int for naming pin numbers


int thingToChange = 8;

void setup() {


  thingToChange = 10;


codebook: finding the position of a servo motor (but not actually)

This code includes the command, which looks like it might talk to the servo motor, find what its current position is, and report that back to the Arduino. Actually, that’s not what it does—it simply reports back whever the servo motor was last told to go. It doesn’t know if it’s gotten there yet!

int value = 1082;

Servo doorMotor;

void setup() {
  // put your setup code here, to run once:


void loop() {
  int position =; // this probably doesn't do what you think!

Tuesday, Sep, 13th: Variable types and event loop programming

  • Different data types for variables in the Arduino environment:
    • bool: true or false
    • int: whole number in range –32,268 to 32,767
    • unsigned int: the same number of values as int, but starting at 0, so: range is 0 to 65,535
    • long: whole number in range approximately –2.1 billion to 2.1 billion
    • unsigned long: the same number of values as long, but starting at 0, so: range is 0 to about 4.3 billion
    • float: “floating point” number, meaning something with a decimal in it like 1.543 or –10493.25, but with limits (a float has 6 or 7 digits of precision, so it wouldn’t store 9872.19886757275). Range is about –3.4 × 1038 to 3.4 × 1038
    • char: short for “character,” things like a, Q, ?, or even 8 (as a character, not the value 8)
    • String: a “string” of characters put together, like "Abracadabra!" she yelled. or 735 (that last one is not a number—it’s a String so it has no numerical value)
    • Read lots more details at this section of the main Arduino reference page
  • How to juggle multiple events on different timers, without using delay(): the event-loop programming model (see below)
  • Remainder of day is a work session

codebook: basic outline of event loop programming

This software structure will allow you to juggle a variety of different events on different schedules, so that you can run more complicated sketches without needing long delay()s (which are almost always the wrong way to do things).

For a more complete example and further explanation, see the “Blink Without Blocking” section of the Code Bytes page.

unsigned long eventTimer = 0;
unsigned long LCDtimer = 0;

void setup() {
  // put your setup code here, to run once:


void loop() {

  find the pos. of the pot.

  // event-loop programming

  if (millis() - eventTimer >= 333) {
    turn the LED on or off;
    // reset the timer!
    eventTimer = millis();

  if (millis() - LCDtimer >= 100) {
    send info. back to the user
    LCDtimer = millis();

Thursday, Sep. 15th: Debugging techniques

  • Handed out and briefly demonstrated: multimeter
    • measure voltages to make sure things are getting or sending power
    • measure resistance to confirm correct resistance between points in your circuit
    • measure continuity to make sure that things are connected as you expect
  • Reading resistor color codes to know their values
  • Code notes (fixing a piece of sample code with problems)
  • General recommended code structure—in your loop:
    1. find information about the world
    2. process that information however you’d like
    3. change/drive/actuate outputs
    4. report information back to the user
  • Remainder of class is work time
  • Project 1 is due in one week
    • Reminder: take pictures as you go!

codebook: faulty sketch that we fixed

const int POTPIN = A1;
int potVal = -10;
const int led_pin = A3;
bool LEDVal = false;

void setup() {
  pinMode(led_pin, OUTPUT);

void loop() {
  //1. read data
  potVal = analogRead(POTPIN);

  //2. calculate or make decisions
  if (potVal > 100) {
    LEDVal = true;
  else {
    LEDVal = false;

  digitalWrite(led_pin, LEDVal);

  Serial.println((String)"potVal = " + potVal
                 + "; LEDVal = " + LEDVal);


Tuesday, Sep. 20: Project 1 work day

  • Debugging by functional unit-level analysis—get known-working subsystems and put them together to make your bigger system piece by piece
  • Remember to take pictures as you go!

Thursday, Sep. 22: Project 1 presentations

  • Teams present in transduction-chain order for ~10 minutes (with Q&A)
  • A glorious and somewhat-successful assembly of the final transducer at the end!