Milestone map
Milestone map
4 milestones
C for microcontrollers, switches and LEDs
about 3 weeks (about 10 hrs/week)
Read Valvano chapters 1–4 and Fiore chapters 3–12 (C) and 15–24 (I/O). Valvano's examples target the TM4C123; write your versions for the ATmega328P and run them in Wokwi or SimulIDE. Then solve the Valvano checkpoints in chapters 1–4 and Fiore's C exercises in chapters 3, 4, 7, 8, 10 and 12. Self-check: Embedded Controllers Using C and Arduino, Appendix B: Answers to Selected Problems. Free tools only.
Proof required
Link the public repo with the Valvano checkpoints in chapters 1–4 and Fiore's C exercises in chapters 3, 4, 7, 8, 10 and 12 written up (a typeset PDF, LaTeX source or notebook), and show the self-check: which answers matched and how you fixed the ones that did not.
What gets checked
- Bitwise register operations are explained line by line.
- Switch and LED code runs in Wokwi or SimulIDE.
- Answers are checked against Fiore's Appendix B and Valvano's checkpoint answers.
Common mistakes
- Answers copied from a solution with no working.
- Missing units, or a sign or factor-of-2π slip left unexplained.
Powstik Guide
A public write-up of the Valvano checkpoints in chapters 1–4 and Fiore's C exercises in chapters 3, 4, 7, 8, 10 and 12, with the self-check shown.
Steps
- Study the linked course material.
- Solve the problems on your own first.
- Check them against the self-check and rework the misses.
- Typeset the write-up (LaTeX or a notebook) in a public repo.
- Ask someone who knows the subject to check it.
Template
README ECE 10: Embedded Systems, unit 1: C for microcontrollers, switches and LEDs Problems: Self-check result (matched / reworked): What I got wrong first and why:
What gets sent back
- No working shown.
- The self-check result is missing.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Bitwise register operations are explained line by line.
- Switch and LED code runs in Wokwi or SimulIDE.
- Answers are checked against Fiore's Appendix B and Valvano's checkpoint answers.
- Is the engineering right, not just the final number?
You'll sign in first, then come straight back here.
Finite state machines, interrupts, timers and conversion
about 3 weeks (about 10 hrs/week)
Read Valvano chapters 5–8 and Fiore chapters 25–29. Then solve the Valvano checkpoints in chapters 5–8. Self-check: Introduction to Embedded Systems (Jonathan Valvano, UT Austin, free ebook). Free tools only.
Proof required
Link the public repo with the Valvano checkpoints in chapters 5–8 written up (a typeset PDF, LaTeX source or notebook), and show the self-check: which answers matched and how you fixed the ones that did not.
What gets checked
- The FSM is a table in code, not nested ifs.
- Interrupt latency and timer periods are worked out from the clock.
- Checkpoint answers are checked, and misses are reworked.
Common mistakes
- Answers copied from a solution with no working.
- Missing units, or a sign or factor-of-2π slip left unexplained.
Powstik Guide
A public write-up of the Valvano checkpoints in chapters 5–8, with the self-check shown.
Steps
- Study the linked course material.
- Solve the problems on your own first.
- Check them against the self-check and rework the misses.
- Typeset the write-up (LaTeX or a notebook) in a public repo.
- Ask someone who knows the subject to check it.
Template
README ECE 10: Embedded Systems, unit 2: Finite state machines, interrupts, timers and conversion Problems: Self-check result (matched / reworked): What I got wrong first and why:
What gets sent back
- No working shown.
- The self-check result is missing.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- The FSM is a table in code, not nested ifs.
- Interrupt latency and timer periods are worked out from the clock.
- Checkpoint answers are checked, and misses are reworked.
- Is the engineering right, not just the final number?
You'll sign in first, then come straight back here.
Serial communication and system design
about 3 weeks (about 10 hrs/week)
Read Valvano chapters 9–10 and the matching chapters of the Real-Time Interfacing ebook. Then solve the Valvano checkpoints in chapters 9–10. Self-check: Introduction to Embedded Systems (Jonathan Valvano, UT Austin, free ebook). Free tools only.
Proof required
Link the public repo with the Valvano checkpoints in chapters 9–10 written up (a typeset PDF, LaTeX source or notebook), and show the self-check: which answers matched and how you fixed the ones that did not.
What gets checked
- UART frames and baud-rate error are computed.
- The system design states its requirements and tests.
- Checkpoint answers are checked, and misses are reworked.
Common mistakes
- Answers copied from a solution with no working.
- Missing units, or a sign or factor-of-2π slip left unexplained.
Powstik Guide
A public write-up of the Valvano checkpoints in chapters 9–10, with the self-check shown.
Steps
- Study the linked course material.
- Solve the problems on your own first.
- Check them against the self-check and rework the misses.
- Typeset the write-up (LaTeX or a notebook) in a public repo.
- Ask someone who knows the subject to check it.
Template
README ECE 10: Embedded Systems, unit 3: Serial communication and system design Problems: Self-check result (matched / reworked): What I got wrong first and why:
What gets sent back
- No working shown.
- The self-check result is missing.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- UART frames and baud-rate error are computed.
- The system design states its requirements and tests.
- Checkpoint answers are checked, and misses are reworked.
- Is the engineering right, not just the final number?
You'll sign in first, then come straight back here.
Firmware for a small device, with a demo
about 3 weeks (about 10 hrs/week)
Make firmware for a small device (for example a traffic-light FSM, or a thermometer that reads an ADC and reports over a serial link) in a public repo, running in Wokwi or SimulIDE. Write the requirements, the FSM table and the interrupt plan. Implement and test them in the simulator. Measure interrupt and loop timing with the simulator's logic analyser and compare with your predictions in a table. Add a short demo video and the simulator link. Optional, costs money: a development board (Arduino, Raspberry Pi Pico or TI LaunchPad) powered over USB. Safety: 12 V DC or less, from AA, AAA or 9 V batteries or USB only. Never mains power, never a lithium-polymer pack or loose lithium cell, and never a home-made battery charger. Wear eye protection when soldering or cutting leads. Under 18? Use the simulator, or build and solder with an adult present.
Proof required
Link the public repo with the firmware, the simulator link or build steps, the timing table and a short demo video, and a README that says how to rerun it and what limits the result.
What gets checked
- The simulator link (or build steps) runs the firmware from the repo.
- Predicted and measured interrupt and loop timing agree within 10%, or each gap is traced to a cause.
- The demo shows every requirement working.
Common mistakes
- A result that nobody else can rerun from the repo.
- A table with no explanation of the gaps.
Powstik Guide
Firmware for a small device (for example a traffic-light FSM, or a thermometer that reads an ADC and reports over a serial link) in a public repo, running in Wokwi or SimulIDE, in a public repo.
Steps
- Write down what you expect before you start.
- Write the requirements, the FSM table and the interrupt plan. Implement and test them in the simulator. Measure interrupt and loop timing with the simulator's logic analyser and compare with your predictions in a table. Add a short demo video and the simulator link.
- Fill the predicted-vs-measured table.
- Explain every gap with a cause someone can check.
- Write the README and ask someone who knows the subject to rerun it.
Template
README ECE 10: Embedded Systems — Firmware for a small device, with a demo What I expected: How to rerun it: Predicted vs measured: Why they differ:
What gets sent back
- It does not run from the repo.
- No predicted-vs-measured table.
- Mains power, a lithium pack or loose cell, a home-made charger, or more than 12 V DC.
Resources
Foundationstart here
What a verifier looks for
- The simulator link (or build steps) runs the firmware from the repo.
- Predicted and measured interrupt and loop timing agree within 10%, or each gap is traced to a cause.
- The demo shows every requirement working.
- Rerun it from the repo: does it run, and do the numbers match the table?
- The build uses 12 V DC or less from AA, AAA or 9 V batteries or USB; nothing touches mains, and there is no lithium pack, loose cell or home-made charger.
You'll sign in first, then come straight back here.
Part of