Lecture 03: LED control & timing

A GPIO pin is a voltage source that software can switch.

A very good switch. A mediocre clock.

When timing matters, move it out of the Python loop.

Labs 1–2: the hardware decided.

From Lab 3: software decides. One line of Python changes a voltage.

The catch: Linux plus Python is a poor timekeeper. Measuring how poor is half the lab.

General-purpose: no fixed job. Input or output, your program decides.

As an output: push–pull. A 1 is 3.3 V, a 0 is 0 V.

pinout                 # labelled diagram of this board
pinctrl get 17         # function and level of BCM 17
pinctrl set 17 op dh   # drive BCM 17 high
pinctrl set 17 op dl   # ...and low again

LED dark? Run pinctrl set 17 op dh first.

Lights: the bug is in software. Still dark: the bug is in the circuit.

Red, $V_F = 2.0$ V, 3.3 V pin:  $470\ohm \rightarrow 2.8\mA$,  $330\ohm \rightarrow 3.9\mA$.

1. Set up: numbering scheme, which pins are outputs.

2. Drive: HIGH or LOW, usually in a loop with delays.

3. Clean up: release the pins when the program ends.

import RPi.GPIO as GPIO
from time import sleep
GPIO.setmode(GPIO.BCM)             # 1. set up
GPIO.setup(17, GPIO.OUT)
try:
    for i in range(10):            # 2. drive
        GPIO.output(17, GPIO.HIGH); sleep(1.0)
        GPIO.output(17, GPIO.LOW);  sleep(0.5)
finally:
    GPIO.cleanup()                 # 3. clean up, even on Ctrl+C

range(1, 10) runs nine times, not ten.

• How many pins? What does each setup line look like?
• Per loop pass: how many output calls, in what order, so exactly one LED is lit?
• Where do the sleep calls go? Predict the period before measuring it.
• Put the delay in a named constant. Task 4d sweeps it.

Overhead only ever adds. The measured period is always longer.

Roughly constant in absolute terms, so it matters more as you go faster:

2 ms on 1.5 s is 0.1 %. 2 ms on 1 ms is 200 %.

• Linux is not real-time: the scheduler can pause you at any moment
• sleep() guarantees a minimum, not an exact delay
• every GPIO.output() is Python before it is hardware
• garbage collection pauses, unpredictably
• the desktop, the network, the SD card all steal CPU

Name them in your report. “The Pi is slow” is not an explanation.

Scope: Period measurement, then Statistics on.

Infinite persistence, trigger on a rising edge: the most convincing screenshot.

Task 4 table: requested delay, expected $f$, measured $f$ and $T$, jitter pk–pk and RMS, jitter as % of $T$.

Loop written for 1 kHz. Over 500 cycles: $T_{\text{mean}} = 1.213$ ms, $T_{\min} = 1.140$, $T_{\max} = 1.760$, $\sigma_T = 46\us$.

Period error and frequency error differ. RMS small, pk–pk large: the scheduler’s signature.

Above roughly 50–90 Hz the LED stops flashing and looks dimmer.

The retina integrates over 10–20 ms and reports the average.

That is the bridge to PWM: switch faster than the eye, control the fraction.

Note where you stop seeing flicker; the scope still shows pulses.

GPIO.PWM() is always software: a thread toggles the pin, the scheduler can move every edge.

The Pi also has PWM peripherals on BCM 12, 13, 18, 19: a counter in silicon, no CPU per edge.

Task 7d: compare period statistics of your Task 4 loop and your PWM at the same frequency.

$T$ = ?   $t_{\text{on}}$ = ?   $V_{\text{avg}}$ = ?

Now 500 Hz at 30 %: what changes, what does not?

A DMM on DC volts across the pin reads $V_{\text{avg}}$: a free cross-check.

Before you leave: copy your work off, then delete it.

1. BCM name of physical pin 11?

2. Red LED, $V_F = 1.9$ V, 470 $\Upomega$, 3.3 V pin: current?

3. 0.5 ms high, 0.5 ms low requested; scope reads 1.31 ms. Overhead? Frequency error?

4. 200 Hz at 35 %: period, on-time, average voltage?