Mochi Devlog 01: Giai đoạn đầu phát triển

Devlog này nói về gì

Đây là bài devlog thật đầu tiên của Mochi. Bài giới thiệu trước đó đã nói vì sao Mochi tồn tại như một bài tập làm sản phẩm. Bài này nói về các quyết định thật ở giai đoạn đầu: câu hỏi phần cứng nào xuất hiện trước, firmware được chọn ra sao trước khi có gì được kiểm chứng, và những gì đã hỏng.

Chưa có gì ở đây gần với bản hoàn thiện. Lý do ghi lại ngay bây giờ là để giữ một bản ghi trung thực trước khi trí nhớ làm mờ đi những chi tiết chưa đẹp.

Nếu bạn cũng đang làm prototype đầu tiên, mình hy vọng các quyết định chưa hoàn hảo này sẽ giúp bạn nhận ra vài chỗ nên kiểm tra sớm.

Câu hỏi phần cứng ban đầu

Câu hỏi phần cứng đầu tiên không phải "Mochi cần cảm biến gì" — mà là "Mochi sẽ báo cho ai đó biết có gì đang sai như thế nào." Trước khi thêm bất kỳ cảm biến nào, mình muốn có một tín hiệu trạng thái hoạt động ngay cả khi mọi thứ khác không hoạt động: một LED nối thẳng vào một chân GPIO, không phụ thuộc vào thứ tự khởi tạo firmware.

Câu hỏi thứ hai là nguồn. Mochi cuối cùng sẽ chạy bằng pin, nhưng board đầu tiên được cấp nguồn qua USB trong lúc phát triển, có chủ đích. Debug lỗi nguồn và lỗi firmware cùng lúc làm cả hai khó tách ra hơn. Nguồn USB loại bỏ một biến số trong khi phần logic cốt lõi đang được làm cho ổn.

Câu hỏi thứ ba là chọn MCU, và quyết định dựa trên khả năng hỗ trợ debug sẵn có hơn là thông số kỹ thuật thuần túy. Một chip có UART logging tốt và luồng nạp firmware đơn giản tiết kiệm thời gian ở giai đoạn đầu nhiều hơn một chút hiệu năng cao hơn.

Quyết định firmware đầu tiên

Cột mốc firmware đầu tiên có chủ đích rất đơn giản: nhấp nháy LED trạng thái, in một dòng thông báo boot qua UART và xác nhận board reset sạch sẽ. Chưa có cảm biến, chưa có động cơ, chưa có logic. Nếu nền tảng này không đáng tin, mọi thứ xây trên nó cũng không thể tin được.

Từ đó, firmware được chia thành hai lớp thô ngay từ sớm: một lớp trừu tượng hóa phần cứng nhỏ cho chân và ngoại vi, và một lớp riêng cho bất cứ thứ gì giống hành vi. Cách chia này không tinh vi, nhưng đã giúp một việc dễ hơn ngay — khi có gì đó chạy sai, câu hỏi đầu tiên trở thành "đây là lỗi đọc phần cứng hay lỗi logic", và cấu trúc code khiến câu hỏi đó có thể trả lời được.

Ảnh prototype thật cho thấy việc bố trí dây và vị trí đầu nối vẫn cần sửa ở vòng thiết kế sau.

Những gì đã sai từ sớm

Cách nối LED trạng thái đúng trên giấy nhưng sai trong thực tế: nó dùng chung một chân với giao diện nạp firmware, nên board chỉ có thể được nạp hoặc hiển thị trạng thái, không thể làm cả hai cùng lúc. Đây là lỗi nhỏ, nhưng đúng kiểu lỗi mà ghi chú phần cứng giai đoạn đầu nên bắt được trước khi nó lặp lại ở bản board tiếp theo.

Riêng phần logging UART, lần thử đầu tiên dùng baud rate không khớp với mặc định của mạch debug, tạo ra output lỗi ký tự trông giống lỗi phần cứng lâu hơn mức cần thiết. Vấn đề thật sự chỉ là một dòng cấu hình không khớp.

Không có vấn đề nào nghiêm trọng. Cả hai đều là kiểu lỗi rõ ràng khi nhìn lại, nhưng rất dễ quên nếu không ghi lại.

Bước tiếp theo

Lần làm phần cứng tiếp theo sẽ chuyển LED trạng thái sang chân không xung đột với việc nạp firmware, và thêm một test point thứ hai gần đầu vào nguồn để có thể đo điện áp mà không phải chạm vào chân linh kiện. Về firmware, bước tiếp theo là một giao diện lệnh tối giản qua UART, chủ yếu để các devlog sau có thể báo cáo hành vi thật thay vì chỉ thông báo boot.

Mochi vẫn còn xa mới làm được điều gì thú vị. Mục tiêu của giai đoạn này là một nền board và firmware đủ nhàm chán để tin tưởng, để những quyết định thú vị hơn sau này có một nền tảng ổn định để đứng lên.

Đọc thêm liên quan

• Mochi là gì
• Phần cứng Mochi ESP32-S3
• Tài nguyên model 3D cho Mochi