Lưu trữ website trên thuốc lá điện tử dùng một lần

 (bogdanthegeek.github.io)
28 điểm bởi GN⁺ 2025-09-16 | Chưa có bình luận nào. | Chia sẻ qua WhatsApp
  • Một dự án thử nghiệm chạy web server bằng cách tận dụng vi điều khiển ARM Cortex-M0+ hiệu năng thấp tích hợp trong thuốc lá điện tử dùng một lần
  • Phân tích chip PY32F002B của PUYA với 24KiB flash và 3KiB RAM, triển khai kết nối mạng theo kiểu SLIP
  • Sử dụng Semihosting, giao thức SLIP và stack TCP/IP uIP để port chức năng HTTP server cùng giao tiếp TCP/IP qua tty ảo
  • Ban đầu rất chậm, nhưng sau khi tối ưu bộ đệm và cải thiện xử lý dữ liệu thì tốc độ phản hồi và tải trang được cải thiện đáng kể
  • Hiện thực cả việc chạy mã máy chủ động và cung cấp endpoint API ngay cả trong môi trường bộ nhớ cực thấp
  • Mã nguồn đã được phát hành, có thể lưu trữ thực tế nhưng bị giới hạn lớn về tài nguyên như bộ nhớ

Mở đầu

  • Trước hết, bài viết này nói rõ rằng nội dung không thực sự được phục vụ trực tiếp từ web server chạy trên thuốc lá điện tử dùng một lần, mà cùng nội dung đó đang được cung cấp từ một máy chủ riêng biệt
  • Có thể xem ví dụ hoạt động thực tế tại http://ewaste.fka.wtf/

Bối cảnh

  • Trong vài năm qua, tác giả đã thu thập thuốc lá điện tử dùng một lần từ người quen với mục đích tái sử dụng pin
  • Gần đây, tác giả chú ý đến việc các thiết bị thuốc lá điện tử dùng một lần ngày càng được nâng cấp, bắt đầu có USB-C và pin sạc lại
  • Trong lúc tháo dỡ, tác giả phát hiện một vi điều khiển ARM Cortex-M0+ tích hợp flash mang tên PUYA, vốn là dòng chip nổi tiếng ở phân khúc vi điều khiển giá rẻ
  • Tác giả đã thu thập các vi điều khiển này từ nhiều mẫu khác nhau, và việc chúng có nhãn chân debug giúp phân tích dễ dàng hơn

Phần cứng sử dụng

  • Ký hiệu trên chip là PUYA C642F15, nhưng được suy đoán thực tế thuộc họ PY32F002B
  • Thông số chính:
    • Nhân Cortex-M0+ 24MHz
    • 24KiB flash
    • 3KiB RAM
    • Có nhiều thiết bị ngoại vi nhưng không dùng trong dự án này
  • So với smartphone thông thường thì hiệu năng thấp, nhưng trong môi trường nhúng vẫn hoàn toàn có thể xây dựng web server đơn giản

Kết nối mạng

  • Dù không phải là ý tưởng đầu tiên, tác giả đã nảy ra ý tưởng chạy web server khi thử nghiệm khái niệm semihosting
  • Semihosting là một cách mô phỏng syscall trên ARM nhúng
    • Khi đặt giá trị/con trỏ vào thanh ghi rồi gọi breakpoint, debugger sẽ diễn giải và xử lý hành động tương ứng
    • Thông thường nó được dùng để gửi log, nhưng cũng có thể giao tiếp dữ liệu hai chiều
  • Các thiết bị serial USB hỗ trợ giao thức SLIP (Serial Line Internet Protocol), nên tác giả tận dụng nó như một giao diện mạng
  • Trên Linux (và một phần macOS), có thể dựng môi trường mạng SLIP qua tty ảo bằng slattach, socat và các công cụ tương tự 
    pyocd gdb -S -O semihost_console_type=telnet -T $(PORT) $(PYOCDFLAGS) &  
socat PTY,link=$(TTY),raw,echo=0 TCP:localhost:$(PORT),nodelay &  
sudo slattach -L -p slip -s 115200 $(TTY) &  
sudo ip addr add 192.168.190.1 peer 192.168.190.2/24 dev sl0  
sudo ip link set mtu 1500 up dev sl0
  • Tác giả chọn uIP làm stack TCP/IP vì nó rất nhỏ gọn, không cần RTOS và dễ port
  • Từ ví dụ HTTP server của uIP, tác giả đã port phần mã SLIP cho phù hợp với semihosting và khởi động web server thành công
  • Do có vấn đề căn chỉnh 16-bit trên kiến trúc ARM, tác giả đã chỉnh sửa script tạo filesystem và chuyển đổi xử lý bằng Perl

Tối ưu tốc độ

  • Ở trạng thái ban đầu, hệ thống cho ping 1,5 giây, mất gói 50%, và tải trang mất hơn 20 giây nên phản hồi cực kỳ chậm
  • Nguyên nhân là do overhead rất lớn của I/O theo từng byte
  • Tận dụng tối đa 3KiB RAM, tác giả thêm ring buffer và cải thiện cấu trúc để cấp dữ liệu theo lô cho các hàm SLIP
  • Ghi dữ liệu cũng được chia lô để xử lý truyền tải, giúp dọn dẹp nhanh hơn
  • Sau tối ưu, đạt được ping 20ms, không mất gói, tải trang 160ms
  • Mức sử dụng tổng RAM và flash:
    • Flash: 5.116B trên 24KB (20,82%)
    • RAM: 1.380B trên 3KB (44,92%)
  • Dung lượng này đủ để phục vụ toàn bộ nội dung blog mà không gặp khó khăn, đồng thời cũng có thể chạy mã C phía máy chủ

Các chức năng khác và phần kết

  • Tác giả tự triển khai endpoint API, trả về số lần yêu cầu trang chính và unique ID của vi điều khiển
  • Đây là một thử nghiệm hiện thực cả web server động lẫn API với phần cứng cấu hình cực thấp và lượng bộ nhớ tối thiểu

Tham khảo

Bài viết liên quan

Chưa có bình luận nào.

Chưa có bình luận nào.