| 課程大綱 Syllabus |
學生學習目標
Learning Objectives |
單元學習活動
Learning Activities |
學習成效評量
Evaluation |
備註
Notes |
序
No. | 單元主題
Unit topic |
內容綱要
Content summary |
| 1 | Course Introduction, Platform Safety, and Trixie Baseline |
1. Embedded-system characteristics; MCU, MPU, and SBC classification; host and target
2. Raspberry Pi 5 platform roles: BCM2712, RP1, Camera Module 3, and AI HAT+ 2
3. 3.3 V I/O, ESD, power, cooling, power-off reconfiguration, and golden-image recovery
4. Trixie boot media, shell, SSH/SCP, permissions, APT, Git, and baseline inventory |
1. Classify MCU-, MPU-, and SBC-based systems and identify Raspberry Pi 5 as an SBC.
2. Set up and access the Trixie system safely.
3. Produce a system block diagram and a reproducible baseline and recovery record. |
講授
|
|
|
| 2 | Raspberry Pi 5 Hardware Architecture and System Inventory |
1. BCM2712, Arm Cortex-A76, cache, and memory
2. RP1 I/O controller and the internal BCM2712-to-RP1 PCIe 2.0 x4 link
3. microSD, USB, Ethernet, MIPI, 40-pin header, EEPROM, power, and cooling
4. Read-only Linux inventory with lscpu, free, lsblk, lspci, lsusb, ip, uname, and vcgencmd |
1. Explain the roles of BCM2712, RP1, memory, and board I/O.
2. Map hardware components to Linux inventory evidence.
3. Distinguish the internal RP1 link from the external PCIe expansion interface. |
講授
實作
|
|
|
| 3 | AArch64, MMU/MMIO, Device Tree, and the Driver Access Model |
1. Virtual and physical addresses, page tables, TLBs, and page faults
2. RAM versus memory-mapped I/O (MMIO)
3. Device Tree properties: compatible, reg, interrupts, status, and pinctrl
4. Driver matching, Linux subsystems, device nodes, and read-only resource tracing |
1. Explain the path from application to API/device node, driver, MMIO, and hardware.
2. Trace hardware resources through read-only Linux interfaces.
3. Explain why introductory user-space labs do not write registers directly or use /dev/mem. |
講授
|
|
|
| 4 | C on Linux, Processes, and Diagnostic/Deployment Basics |
1. GCC, Make, ELF, ABI, host, and target
2. Return values, errno, resource release, signals, timeouts, and logging
3. GDB, file, readelf, and reproducible build/test/debug records
4. Native builds as the core workflow; cross-compilation as a controlled comparison |
1. Compile, run, and diagnose an introductory Linux C program.
2. Implement error checking, safe termination, and resource cleanup.
3. Use ELF and ABI evidence to distinguish host and target builds. |
上機實習
講授
|
|
|
| 5 | GPIO Hardware, Pull Bias, and Edge Events |
1. Physical pins, GPIO numbers, lines, gpiochips, and the 3.3 V limit
2. Floating inputs, internal/external pull resistors, and active levels
3. Pin multiplexing, pads, drive strength, Schmitt inputs, and switch bounce
4. libgpiod v2 LED, push-button, edge-event, and debounce lab |
1. Wire and operate an LED output and a push-button input safely.
2. Compare no pull, an internal pull, and an external 10 kOhm pull.
3. Capture edge events and explain switch bounce from measurement evidence. |
講授
實作
|
|
|
| 6 | UART Hardware and the Linux Interface |
1. 3.3 V TTL UART versus RS-232 electrical levels
2. TX, RX, GND, baud rate, frame format, and logic levels
3. termios, timeouts, serial aliases, and console conflicts
4. Raspberry Pi 5 debug UART/UART10 and an approved USB-to-TTL loopback or peer |
1. Complete a UART connection and loopback test under the 3.3 V safety rules.
2. Configure frame format, baud rate, and timeouts with termios.
3. Diagnose incorrect baud rate, disconnection, and truncated messages from logs or waveforms. |
講授
實作
|
|
|
| 7 | I2C Hardware and the Linux Interface |
1. Open-drain signaling, bus pull-ups, and equivalent pull-up resistance
2. Addresses, ACK/NACK, registers, clock stretching, and arbitration concepts
3. Module pull-up inspection, 3.3 V compatibility, and i2c-dev
4. Controlled scan, chip identification, register read, and fault injection |
1. Explain the I2C open-drain and pull-up electrical model.
2. Identify the adapter and device address, then read a sensor register.
3. Verify failure handling with an incorrect address or a disconnected device. |
講授
實作
|
|
|
| 8 | SPI, External ADC, PWM/Interrupt Hierarchy, and Midterm Preparation |
1. SPI signals, chip select, CPOL/CPHA, modes, and full-duplex transfer
2. spidev and MCP3008; sampling, quantization, and decoupling
3. PWM frequency, period, duty cycle, hardware/software generation, and jitter
4. Edge event to kernel IRQ and interrupt-controller hierarchy; midterm proposal |
1. Configure SPI mode, speed, and chip select and acquire ADC samples.
2. Explain the hardware-to-Linux hierarchy of PWM and interrupts.
3. Submit a proposal for one GPIO, UART, I2C, or SPI midterm project. |
講授
實作
|
|
|
| 9 | Midterm Practical Oral Report I |
1. First group of GPIO, UART, I2C, or SPI demonstrations
2. English oral report with hardware-to-Linux layer diagram and wiring evidence
3. Source code, test logs, fault injection, recovery, and technical Q&A |
1. Demonstrate a reproducible user-space implementation in English.
2. Justify the design with the electrical model, Linux interface, and test evidence.
3. Answer technical questions and present an executable recovery procedure. |
討論
心得發表
個別或小組指導
|
|
|
| 10 | Midterm Practical Oral Report II |
1. Second group of practical demonstrations and English oral reports
2. Comparison of pull/open-drain/push-pull behavior, polling/events, and addressing/framing
3. English peer feedback and individual reflection; no new technical content |
1. Complete the remaining midterm demonstrations and technical defenses.
2. Compare the electrical, data-format, and Linux access characteristics of the four interfaces.
3. Improve technical explanations and evidence organization through peer feedback. |
討論
心得發表
個別或小組指導
|
|
|
| 11 | pthreads and Shared State |
1. Thread lifecycle, shared state, and race conditions
2. Mutexes, condition variables, and a bounded producer-consumer design
3. Signals, orderly shutdown, and resource cleanup
4. Two-thread I/O or simulated-input lab with fault injection |
1. Build a basic producer-consumer program.
2. Protect shared state with a mutex and condition variable.
3. Reproduce a race condition and verify orderly shutdown with test evidence. |
講授
實作
|
|
|
| 12 | TCP/UDP, systemd, and the Final Project Proposal |
1. TCP/UDP, message framing, timeouts, disconnection, and retry
2. systemd service lifecycle, least privilege, journaling, and restart policy
3. Final project tracks, minimum viable system, roles, test plan, and fallback
4. Data transfer between processes or hosts and deployment as a service |
1. Exchange device data with either TCP or UDP.
2. Create a systemd service that can be started, stopped, observed, and recovered.
3. Submit an English proposal with architecture, tests, risks, roles, and fallback. |
講授
實作
|
|
|
| 13 | CSI-2 Camera Data Flow and Controlled AI HAT+ 2 Inference |
1. IMX708, CSI-2, RP1 CSI receiver, DMA, ISP front end, buffers, and metadata
2. Camera Module 3 capture with libcamera/rpicam-apps; RAW versus processed output
3. Safe power-off transition to AI HAT+ 2; PCIe, Hailo-10H, DKMS, HailoRT, and model I/O
4. Instructor-validated post-processing example; image/video fallback; BRIO 100 as supplementary comparison |
1. Explain the camera-to-memory/application data path and distinguish RAW, processed output, and metadata.
2. Run a controlled capture or inference example and record the model, I/O, latency, and limitations. |
講授
實作
|
|
|
| 14 | Integration, Performance, and Recovery Checkpoint |
1. End-to-end data path, threads, queues, network, and service integration
2. Latency, CPU/memory use, dropped data, and log evidence
3. Version lock, soak testing, known limitations, and recovery drills
4. Minimum viable demonstration, test matrix, and final scope freeze |
1. Explain performance, failures, and limitations with measurements and logs.
2. Verify version control, service recovery, and restoration of the I/O or AI hardware configuration. |
講授
實作
|
|
|
| 15 | Final Project Presentation I |
1. First group of integrated demonstrations and English technical defenses
2. Requirements, architecture, source code, test matrix, logs, and recovery
3. Version evidence, known limitations, and individual contributions |
1. Synthesize requirements, hardware, Linux software, and test evidence.
2. Explain design trade-offs, failure handling, and recovery in English.
3. Verify individual contributions through source, logs, and version records. |
討論
心得發表
個別或小組指導
|
|
|
| 16 | Final Project Presentation II and Course Review |
1. Second group of integrated demonstrations and English technical defenses
2. Review of requirements, hardware, driver/API, program, service, test, and recovery
3. Archive source code, README, test report, reflection, and final evidence; no new features |
1. Evaluate the system and its limitations through the complete engineering chain.
2. Identify next steps in Embedded Linux, driver development, or Edge AI. |
討論
心得發表
個別或小組指導
|
|
|
|