Metatransformer report
Timers, deadlines, and PWM
Practice · 60 minutes · Use hardware timebases and PWM duty cycle to schedule work and choose a switching rate that controls average power without confusing frequency with resolution.
Text report: images and diagrams are omitted, and links to project files are inactive. Keep the exported project alongside this PDF for wiring diagrams, models, and linked files.
Learning outcomes
- Calculate timer periods and PWM duty cycles, implement rollover-safe periodic work, and explain what a PWM output does and does not control.
Prerequisites
- mcu-gpio
Concepts
A timer counts clock ticks so firmware can act at useful intervals without staring at a wall clock. The same idea coordinates a screen refresh, a sensor sample, or a motor-control pulse. If a counter advances at f_tick ticks per second, one tick lasts T_tick = 1/f_tick, and N ticks span N/f_tick seconds. Hardware compare units can change a pin or request service when the count reaches a chosen value.
Pulse-width modulation switches an output repeatedly. Duty cycle D = t_on/T is the fraction of each period that is on, while PWM frequency f = 1/T says how often periods repeat. For an ideal 12 V source at 25% duty, the time-average switched voltage is 3 V, but the instantaneous motor-terminal waveform still alternates between approximately 0 V and 12 V. Motor inductance and inertia smooth current and speed; an LED averages brightness to the eye. This is not an adjustable DC supply for every load.
Timer resolution and frequency trade off when a fixed clock supplies the counter. With a 1 MHz timer and 100-count period, PWM is 10 kHz with 101 possible compare positions if endpoints are included. A larger period permits finer duty steps but lowers frequency. Choosing 20 kHz for a small motor can move switching above much of human hearing, yet driver losses and MCU limits must be checked. That frequency choice is a build decision, not folklore.
Common errors include confusing 50% duty with half speed, assuming duty directly sets torque under every load, and writing delay-based schedules that drift. For periodic work, advance the deadline by the intended period rather than setting it to “now plus period” after variable work. Counter rollover is normal; use the platform’s documented difference arithmetic rather than comparisons that fail once the counter wraps. The associated simulation is a bounded scheduling model, not a reproduction of a particular timer peripheral.
Worked example
Problem
An 8 MHz timer uses a prescaler of 8 and counts 0 through 199 for PWM. Find frequency and the compare value nearest 30% duty.
Steps
- Timer tick frequency = 8 MHz / 8 = 1 MHz, so each tick is 1 µs.
- The inclusive 0…199 period has 200 ticks, so T = 200 µs and f = 1/200 µs = 5 kHz.
- Thirty percent of 200 ticks is 60 on-ticks, so configure the platform’s compare semantics for 60 high ticks.
Result
The PWM frequency is 5 kHz and 60 of 200 ticks produces 30% duty under the stated edge convention.
Sanity check
5,000 periods/s × 200 ticks/period = 1,000,000 ticks/s, matching the prescaled timer clock.
Check your understanding
A periodic task should run every 10 ms. Its work sometimes takes 3 ms. Which update best avoids accumulating phase drift?
A. After the work, set next = current_time + 10 ms every time B. When due, advance next = next + 10 ms and handle any documented missed-period policy C. Insert a fixed 10 ms blocking delay before every check D. Increase PWM duty until the task catches up
Your answer: ______________________________
Reasoning:
Answer key
ANSWER KEY — check only after attempting the question.
B. When due, advance next = next + 10 ms and handle any documented missed-period policy
Advancing from the prior deadline preserves the intended time grid; a clearly defined overrun policy handles missed periods. Scheduling from completion adds variable work time to every interval. Blocking delays worsen responsiveness, and PWM duty is unrelated to software scheduling.
Hands-on lab
Goal
Measure PWM timing and compare non-blocking periodic scheduling with a drifting completion-based schedule.
Equipment
- Microcontroller with PWM
- LED and 330 Ω resistor
- logic analyzer or oscilloscope if available
- serial console
Procedure
- Configure an LED PWM output near 1 kHz and command 25%, 50%, and 75% duty; log requested values.
- If an instrument is available, measure high time and period at one setting; otherwise use a slow 2 Hz test waveform and timestamp edges in software.
- Schedule a status print every 100 ms by advancing the stored deadline from its prior value.
- Introduce a deliberate fault by scheduling from task completion and adding 20 ms of simulated work; compare timestamp drift, then restore deadline-based scheduling.
- Document timer frequency, resolution, and whether the output polarity inverts the numeric duty.
What to observe
- Expected: nominal high time at 1 kHz and 25% duty is 0.25 ms; actual measured period and high time must be recorded separately.
- Expected: deadline-based timestamps remain near multiples of 100 ms, while completion-based scheduling accumulates the added work time.
- Record actual jitter and instrument resolution rather than interpreting requested duty as measured duty.
Transfer challenge
Choose a PWM frequency and initial duty limit for a transistor-driven miniature fan, stating what motor/driver documentation you would verify before testing.
Cautions
- Drive only the resistor-limited LED directly; a fan or motor requires a suitable driver and separate current-path analysis.
Evidence record
Learner: ____________________ Date: ____________________
Evidence artifact or file: ____________________________________________
| Item | Record |
|---|---|
| Prediction or expected result | |
| Actual observation or measurement | |
| Conditions and tools used | |
| Difference from expectation | |
| Next decision or follow-up |
Notes: