Overview

Module này tập trung vào 3 thứ làm firmware “sống được” ngoài đời: (1) mô hình task/scheduling rõ ràng để trace được, (2) đồng bộ đúng để không tự giết mình bằng race/deadlock, (3) đo latency như đo ngân sách (budget) chứ không phải “cảm giác mượt”.

Trong thực chiến, RTOS không cứu bạn khỏi thiết kế tệ. Nó chỉ làm lỗi xuất hiện dưới dạng hiếm gặp hơn, khó tái hiện hơn, và đắt hơn để debug.

Prerequisites

• Nắm vững driver/peripheral ở mức đọc register map, hiểu DMA/IRQ, và biết tách “policy vs mechanism”.
• Hiểu tối thiểu về concurrency: critical section, mutual exclusion, priority inversion (không cần thuộc lý thuyết, nhưng phải hiểu triệu chứng).
• Có thói quen đo đạc: timestamp, cycle counter, logic analyzer, trace hooks (ít nhất biết dùng 1 công cụ).

Learning outcomes

• Thiết kế một task model có ownership rõ (ai sở hữu buffer, ai được phép mutate).
• Chọn primitive đồng bộ phù hợp (mutex/semaphore/queue/event group) dựa trên data-flow, không dựa trên thói quen.
• Viết ISR “an toàn để ship”: bounded time, không block, không allocate, biết handoff sang task.
• Thiết lập baseline đo latency/jitter và trình bày kết quả theo budget (P50/P95/worst-case).

Lesson map

• Tasks & Scheduling (advanced) — Xây task model dựa trên workload, xác định critical path, và đặt policy scheduling có lý do. Kết thúc bài, bạn có sơ đồ task + timing assumptions đủ để review.
• Synchronization & ISR Safety (advanced) — Đồng bộ theo nguyên tắc “data ownership trước, primitive sau”. Đi qua ISR handoff, priority inversion, và các pattern queue/notify chuẩn để tránh deadlock kiểu production.
• Latency & Profiling (advanced) — Đo latency/jitter bằng số liệu: trace points, timestamping, và cách đọc kết quả. Mục tiêu là ra quyết định tối ưu dựa trên budget, không dựa trên cảm giác.

Pitfalls & Anti-patterns

• “RTOS = multi-threading cho vui”: tạo task cho mọi thứ, không có ownership rõ → race + heisenbug.
• ISR làm quá nhiều việc (parse protocol, memcpy lớn, logging) → starvation và mất deadline ngẫu nhiên.
• Dùng mutex như “bùa hộ mệnh”, khóa rộng và lâu → priority inversion + throughput collapse.
• Polling trong task thay vì event-driven (queue/notify) → jitter tăng, pin CPU, khó đo.
• Dùng delay() như cơ chế đồng bộ → timing phụ thuộc load; bug xuất hiện khi system bận.
• Không có timeout/telemetry cho wait path → deadlock xảy ra mà không ai biết “kẹt ở đâu”.
• Chia sẻ buffer không protocol (không versioning/ownership) → data corruption im lặng.

Deep Tech Insight

• Realtime “đúng nghĩa” là bounded: bounded ISR time, bounded blocking time, bounded memory behavior. Nếu bạn không chứng minh được bound (dù gần đúng), bạn đang làm best-effort chứ không phải realtime.
• Primitive đồng bộ là symptom-level. Root-cause thường là thiết kế data-flow: ai sở hữu dữ liệu, lifecycle của buffer, và điểm handoff giữa interrupt-context ↔ task-context. Fix đúng chỗ là đổi ownership/flow, không phải đổi mutex thành semaphore.

Practice plan

:::quiz Quiz: RTOS sanity-check (ship/không ship)

1. ISR có được phép gọi API có thể block không? Vì sao?
2. Khi nào dùng queue thay vì shared buffer + mutex?
3. Priority inversion là gì, và “triệu chứng” thường thấy trong log/trace?
4. Một latency budget tối thiểu nên báo cáo những percentile nào để review quyết định tối ưu?

Đáp án kỳ vọng (ngắn):

• (1) Không; ISR phải bounded và không được phụ thuộc scheduler.
• (2) Khi cần handoff ownership theo message, giảm shared state.
• (3) Task priority cao bị kẹt do tài nguyên do task priority thấp giữ; thấy spike latency và chain wait.
• (4) Ít nhất P50/P95 và worst-case (hoặc max quan sát được) + điều kiện đo. :::

:::parsons Parsons: ISR handoff đúng chuẩn (conceptual)

Sắp xếp các bước theo flow an toàn (ISR ngắn, handoff sang task). Mục tiêu là không block trong ISR và không truy cập shared buffer “tùy hứng”.

• A) ISR đọc trạng thái tối thiểu, clear interrupt flag
• B) ISR push event/message (queue/notify) sang task xử lý
• C) Task nhận event, parse/validate dữ liệu, cập nhật state ứng dụng
• D) Task thực hiện xử lý nặng (protocol, copy lớn, logging), có timeout/telemetry :::

Next steps

• Sang module tiếp theo: Production & Safety — biến realtime code thành thứ có thể certify/ship: testing, secure boot/OTA, và kỷ luật safety.