การเปลี่ยนไปใช้ RTOS บน RP2040

 (blog.brixit.nl)
1 คะแนน โดย GN⁺ 2024-07-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การเปลี่ยนไปใช้ RTOS: ประสบการณ์บน RP2040

Martijn Braam

  • บทความของ Martijn Braam ผู้ทำงานด้านคอมพิวเตอร์
  • กำลังทำโปรเจกต์ไมโครคอนโทรลเลอร์หลายตัว
  • ใช้บอร์ด Raspberry Pi Pico เป็นหลัก และมีประสบการณ์การพัฒนาที่ดี

ภาพรวมโปรเจกต์

  • สร้างฮาร์ดแวร์คอนโทรลเลอร์สำหรับควบคุมอุปกรณ์วิดีโอ
  • ควบคุมกล้อง PTZ และอุปกรณ์สวิตช์วิดีโอ
  • คอนโทรลเลอร์เดิมมีประสิทธิภาพไม่ดี จึงจำเป็นต้องสร้างแผงควบคุมใหม่

การออกแบบฮาร์ดแวร์

  • มีปุ่ม RGB 9 ปุ่ม, จอยสติ๊กแบบอะนาล็อก และจอแสดงผล
  • ใช้โมดูลสื่อสาร RS-485 และ Ethernet
  • หลังจากแก้ไขฮาร์ดแวร์หลายครั้ง ก็ทำฟังก์ชันต่าง ๆ ได้ครบ

ซอฟต์แวร์ระยะแรก

  • เริ่มจากโปรเจกต์ cmake ที่ใช้ pico-sdk
  • จัดสรรคอร์ที่สองให้กับโมดูล Wiznet ส่วนคอร์แรกใช้จัดการ I/O ของส่วนติดต่อผู้ใช้
  • ความซับซ้อนเพิ่มขึ้นจากการต้องจัดการหลายงานพร้อมกัน

FreeRTOS

  • ใช้ FreeRTOS เพื่อประมวลผลงานหลายอย่างแบบขนาน
  • สร้างงาน (Task) หลายตัว: ปุ่ม, LED, เครือข่าย, DHCP, mDNS, ATEM, VISCA
  • ปัญหาของ FreeRTOS: ระบบค้างเมื่อใช้ printf และขาด hardware abstraction

Apache NuttX

  • ให้สภาพแวดล้อมคล้ายระบบ Unix
  • หลังตั้งค่าเริ่มต้นแล้วสามารถใช้งาน shell จริงได้
  • ตั้งค่าฮาร์ดแวร์ได้ผ่านระบบ menuconfig/Kconfig
  • ฟังก์ชันพื้นฐานไม่ทำงานเพราะปัญหาการตั้งค่า i2c bus
  • ไม่จำเป็นต้องมีพาธของไฟล์ระบบและ shell

Zephyr

  • มี Python utility สำหรับตั้งค่าโปรเจกต์
  • ต้องดาวน์โหลด git repository ขนาด 5GB
  • ต้องติดตั้ง Zephyr SDK แต่สามารถใช้ ARM toolchain เดิมได้
  • การรองรับ Raspberry Pi Pico ยังไม่ดีนัก จึงลองใช้บอร์ดอื่น
  • แม้จะแก้ build error และ warning แล้วก็ยังไม่ทำงาน

บทสรุป

  • สร้างบางแอปพลิเคชันได้สำเร็จด้วย FreeRTOS
  • จำเป็นต้องทำส่วนทดแทน printf
  • จะใช้ FreeRTOS ต่อไปเพื่อพยายามทำฟังก์ชันที่ต้องการให้ได้

สรุปโดย GN⁺

  • บทความนี้พูดถึงกระบวนการเปลี่ยนไปใช้ RTOS ในโปรเจกต์ไมโครคอนโทรลเลอร์
  • เปรียบเทียบข้อดีข้อเสียของ FreeRTOS, Apache NuttX และ Zephyr
  • สรุปว่า FreeRTOS เป็นตัวเลือกที่เหมาะสมที่สุด
  • ช่วยให้เข้าใจปัจจัยหลายอย่างที่ต้องพิจารณาเมื่อเลือก RTOS
  • โปรเจกต์ที่มีฟังก์ชันใกล้เคียงกันก็มี FreeRTOS และ Zephyr

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-07
ความคิดเห็นจาก Hacker News

  • ผู้เขียนคนนี้ดูเหมือนจะคาดหวังให้ RTOS ทำงานเหมือนกับสภาพแวดล้อม Arduino

    • Arduino หลายตัวใช้ mbed หรือ freertos
    • Zephyr ใช้งานง่ายและรองรับ Pi Pico ด้วย

  • สรุป RTOS แบบสั้น ๆ:

    • FreeRTOS: รองรับ SOC/อุปกรณ์ส่วนใหญ่ แต่ไดรเวอร์จะแตกต่างกันไปตาม SOC/อุปกรณ์แต่ละตัว
    • Zephyr: รองรับ hardware abstraction จริง ๆ และรองรับ SOC ส่วนใหญ่
    • NuttX: การรองรับไม่ค่อยดีนัก แต่ถ้าใช้งานได้ก็ยอดเยี่ยมมาก

  • การติดตั้ง toolchain ทั้งระบบตามแนวทาง UNIX แบบดั้งเดิมนั้นน่าปวดหัว

    • การใช้ Python เป็นเครื่องมือทำให้เกิดปัญหาเรื่องเวอร์ชัน
    • เครื่องมือควรเป็นไบนารีที่ลิงก์แบบสแตติก

  • PlatformIO กำลังเดินไปในทิศทางที่ถูกต้อง

    • ต้องจัดการทั้ง toolchain, SDK, ไลบรารี และการตั้งค่าโปรเจกต์
    • การบิลด์ควรทำซ้ำได้จากทุกที่

  • กำลังย้ายโปรเจกต์ RP2040 ไปใช้ Rust และ Embassy

    • Rust ทำความคุ้นเคยได้ยาก แต่ก็น่าพอใจ

  • Zephyr รองรับ Pi Pico ได้ 100%

    • เลยสงสัยว่าเขาไม่ได้ตรวจเอกสารหรือเปล่า

  • ThreadX เป็นโอเพนซอร์ส

  • อยากลองใช้ Hubris ในโปรเจกต์จริง

    • ต้องทนทุกข์กับ C มากขึ้น แต่คล้ายกับ Erlang/Elixir

  • คิดว่า microPython เป็นเส้นทางที่ง่ายกว่า

    • cooperative multitasking ที่อิงกับ async/await ทำงานได้ดี

  • เขียนตัวจับเวลา green thread แบบง่าย ๆ ขึ้นมาเอง

    • แม้จะไม่รองรับการจัดการโปรเซสจริง แต่สามารถไต่ถามเซนเซอร์ต่าง ๆ และจัดการสัญญาณได้

  • FreeRTOS โดยพื้นฐานแล้วคือมาตรฐานอุตสาหกรรม

  • Rust RTIC รองรับ rp2040 และมีน้ำหนักเบามาก