Labs
Ten labs, one board
Each lab puts one or two modules to work on your board. You work in pairs at one station. For labs 1 to 8, each of you writes your own report: what you did, what you measured, and one problem you met and how you solved it. Labs 9 and 10 are the final project.
The labs
Parts are what the lab adds to your station's board, power supply, boot media and breadboard. The hand-in column is a summary; each lab's page has the full list, with your own report for labs 1 to 8.
| Lab | Modules | What you do | Parts added | You hand in |
|---|---|---|---|---|
| 1. First boot | 0 | Write a verified image, wire the serial console, capture the whole boot log, log in over serial and SSH | USB-to-UART adapter; phone or bench PC | The image's SHA-256 and source; the raw boot log, kept for labs 3–5 |
| 2. Board anatomy and power rails | 1, 2 | Find every major part on the board and in its layout, trace each rail, measure the rails and the board's current | USB power meter; bench multimeter | A labelled board photo; a rail table; a current chart with its axis from zero; a paragraph on why the rails come up in sequence |
| 3. Boot ROM and the SRAM stage | 3, 4 | Annotate the boot ROM's lines, change the boot order, start the board over USB, and boot a first stage you built yourself | Phone or bench PC; libretech-builder-simple on the bench PC | The boot order as observed; the annotated lines; your build's console output; a paragraph on what the first stage had to do |
| 4. Memory and the bootloader | 5, 6 | Change the memory clock in the open first stage and see the effect; boot a kernel by hand from the U-Boot prompt | Bench PC with libretech-builder-simple | The memory change and its effect; the commands that booted the kernel; a memory map |
| 5. UEFI and Linux boot | 7, 8 | Boot a stock distribution through UEFI, annotate every remaining line of the log, time the boot, write a systemd service | Your station's spare boot media | The fully annotated boot log; a boot-time breakdown; the service unit |
| 6. Device tree and GPIO | 9, 10 | Write an overlay that binds a kernel driver; light an LED within the pin's limits and switch a motor through a MOSFET; read a button with libgpiod, measuring latency | LEDs, resistors, button, DS3231, the motor set; bench logic analyser and multimeter | Overlay source and before/after listings; GPIO code; the LED current against your calculation; the motor circuit and why it needs a MOSFET; a latency histogram; a paragraph on why Linux is not hard real time; the project proposal |
| 7. I2C and SPI | 10 | Read a clock's registers by hand from its datasheet, drive an OLED, read sensors through an SPI ADC | SSD1306, MCP3008, potentiometer, sensor | Decoded I2C and SPI captures; the time on the OLED; a calibrated sensor reading |
| 8. UART and a driver | 10, 11 | Exchange messages over a UART at two baud rates; write a tested userspace driver for the ADC; stretch: a kernel module | None: reuses the MCP3008 and the USB-to-UART adapter | A UART capture with its framing errors explained; the library, tests and tool; the library and kernel-driver readings compared |
| 9. Project build and recovery | 12 | Build your project; break the boot on spare media on purpose and recover over USB | Your project's parts | A working subsystem; your design document; a recovery runbook |
| 10. Project demo | 12 | Demonstrate the project and answer questions about it | Your project's parts | The demo; then your report and repository |
Final project
With your partner, build a small system that uses at least two of the course's buses (I2C, SPI and UART count; GPIO and PWM can be part of it but do not count toward the two), starts on boot as a service, survives having its power pulled, and has a README another student could rebuild it from. Examples: a data logger that reads the SPI ADC, timestamps each reading from the I2C clock and shows its status on the I2C OLED; a sensor node that reads the SPI ADC and sends its readings over a UART link to the bench PC; or a fan or pump controller that reads a temperature through the SPI ADC, shows it on the I2C OLED and switches a small motor through a MOSFET.
Hand in a one-page proposal with your lab 6 report, in the week of lab 7: what you will build, which buses it uses and which parts you need. The proposal is your project's design document: keep it up to date as the project changes. Lab 9 ends with a checkpoint, and lab 10 is the demo. After the demo, the pair hands in a project report (the design and what you measured) and the repository with its README, by the date your instructor sets.