FreeRTOS และ Zephyr RTOS เป็นระบบปฏิบัติการแบบเรียลไทม์ (RTOS) สองระบบที่ได้รับการนำไปใช้อย่างแพร่หลายมากที่สุดในอุตสาหกรรมระบบฝังตัว แต่ทั้งสองระบบตอบสนองความต้องการและมีแนวคิดการออกแบบที่แตกต่างกัน FreeRTOS ซึ่งสร้างขึ้นโดย Richard Barry ในช่วงแรกและปัจจุบันดูแลโดย Amazon Web Services เป็นเคอร์เนลที่มีน้ำหนักเบาและใช้ทรัพยากรน้อย โดยมุ่งเน้นที่การจัดตารางเวลางาน กลไกพื้นฐานสำหรับการซิงโครไนซ์ และการจัดการหน่วยความจำ FreeRTOS เป็นตัวเลือกมาตรฐานโดยพฤตินัยสำหรับไมโครคอนโทรลเลอร์ที่มีทรัพยากรจำกัดมานานกว่าสองทศวรรษ ส่วน Zephyr ซึ่งได้รับการสนับสนุนจาก Linux Foundation ใช้แนวทางที่ครอบคลุมมากกว่า โดยนำเสนอ RTOS ที่มีคุณสมบัติครบถ้วน พร้อมสแต็กเครือข่ายในตัว เฟรมเวิร์กสำหรับไดรเวอร์อุปกรณ์ ระบบบิลด์ที่มีประสิทธิภาพซึ่งใช้ CMake และ Kconfig รวมถึงการรองรับบอร์ดมากกว่า 600 รุ่นโดยตรง FreeRTOS มีประสิทธิภาพโดดเด่นเมื่อคุณต้องการตัวจัดตารางเวลาที่มีขนาดเล็กและมีโอเวอร์เฮดต่ำที่สุดบนอุปกรณ์ระดับ Cortex-M0/M3 ขณะที่ Zephyr เป็นตัวเลือกที่เหมาะสมกว่าสำหรับผลิตภัณฑ์ IoT ที่ซับซ้อนซึ่งต้องใช้สแต็กโปรโตคอล Bluetooth, Thread หรือ Matter

ความแตกต่างหลักด้านสถาปัตยกรรมคืออะไร?

FreeRTOS มีสถาปัตยกรรมเคอร์เนลแบบโมโนลิทิก (Monolithic Kernel) โดยมีขนาดโค้ดเล็กมาก ซึ่งมักใช้พื้นที่แฟลชน้อยกว่า 10 KB โดยมีองค์ประกอบพื้นฐาน ได้แก่ ทาสก์ คิว เซมาฟอร์ มิวเท็กซ์ ตัวตั้งเวลา และกลุ่มเหตุการณ์ ตัวเคอร์เนลเองไม่มี HAL (Hardware Abstraction Layer) โมเดลไดรเวอร์ หรือสแต็กเครือข่าย โดยองค์ประกอบเหล่านี้จัดเตรียมผ่านไลบรารีแยกต่างหาก เช่น FreeRTOS+TCP และ FreeRTOS+CLI ในทางตรงกันข้าม Zephyr ใช้สถาปัตยกรรมแบบโมดูลาร์ที่มีโมเดลระบบย่อยซึ่งมีความสามารถสูง เคอร์เนลรองรับเธรด คลาสการจัดตารางเวลา (แบบร่วมมือและแบบแย่งสิทธิ์) คิวงาน และชุดกลไกการซิงโครไนซ์ที่หลากหลาย รวมถึงตัวแปรเงื่อนไข (Condition Variables) Zephyr ผสานรวมโมเดลไดรเวอร์อุปกรณ์อย่างครบถ้วน พร้อมรองรับ Device Tree (ซึ่งนำแนวคิดมาจาก Linux) ชั้น HAL และสแต็กเครือข่าย Bluetooth, USB และระบบไฟล์อย่างครบถ้วน

ระบบบิลด์มีความแตกต่างกันอย่างไร?

โดยทั่วไป FreeRTOS จะถูกรวมเข้ากับ IDE ที่ผู้ผลิตจัดเตรียมไว้ เช่น STM32CubeIDE, MCUXpresso หรือ MPLAB X กระบวนการบิลด์ประกอบด้วยการเพิ่มไฟล์ซอร์สของ FreeRTOS ลงในโปรเจกต์และกำหนดค่า FreeRTOSConfig.h ความเรียบง่ายนี้เป็นทั้งจุดแข็งและข้อจำกัดของระบบ ส่วน Zephyr ใช้ระบบบิลด์เฉพาะที่เรียกว่า West ซึ่งทำงานบนพื้นฐานของ CMake และ Kconfig แม้จะมีช่วงการเรียนรู้ที่ยากกว่า แต่ก็มีคุณสมบัติที่ทรงพลัง เช่น การกำหนดบอร์ดภายนอกโครงสร้างซอร์สหลัก (Out-of-tree Board Definitions) การซ้อนทับ Device Tree เฉพาะสำหรับแอปพลิเคชัน และการบิลด์ที่สามารถทำซ้ำได้อย่างสม่ำเสมอ ระบบบิลด์ของ Zephyr ยังรองรับชุดเครื่องมือคอมไพเลอร์หลายประเภท รวมถึง Zephyr SDK, GNU ARM Embedded และ LLVM

# โครงสร้างโปรเจกต์ Zephyr
west build -b nrf52840dk_nrf52840 samples/hello_world
west flash

# การรวม FreeRTOS เข้ากับโปรเจกต์โดยทั่วไป
# 1. เพิ่มซอร์ส FreeRTOS ลงในโปรเจกต์
# 2. กำหนดค่า FreeRTOSConfig.h
# 3. บิลด์ด้วย IDE หรือ Makefile

/* การสร้างทาสก์ใน FreeRTOS */
xTaskCreate(vTaskFunction, "Task1", 256, NULL, 1, &xHandle);
vTaskStartScheduler();

/* การสร้างเธรดใน Zephyr */
K_THREAD_DEFINE(my_thread, 1024, thread_entry, NULL, NULL, NULL, 7, 0, 0);

RTOS ใดรองรับฮาร์ดแวร์ได้ดีกว่ากัน?

FreeRTOS รองรับไมโครคอนโทรลเลอร์แทบทุกชนิดที่มีคอมไพเลอร์ภาษา C และพอร์ตเลเยอร์ โดยมีพอร์ตอย่างเป็นทางการสำหรับ ARM Cortex-M, RISC-V, Xtensa, PIC, AVR และสถาปัตยกรรมอื่น ๆ อย่างไรก็ตาม การพัฒนาไดรเวอร์ยังคงเป็นหน้าที่ของนักพัฒนาหรือ SDK ของผู้ผลิต ส่วน Zephyr รองรับบอร์ดมากกว่า 600 รุ่นโดยตรง พร้อม API ของไดรเวอร์ที่เป็นมาตรฐาน ซึ่งครอบคลุม GPIO, SPI, I2C, UART, PWM, ADC, CAN และอื่น ๆ การเพิ่มการรองรับบอร์ดใหม่ใน Zephyr ทำได้โดยสร้างคำอธิบาย Device Tree และไฟล์กำหนดค่าบอร์ดตามกระบวนการที่มีเอกสารอธิบายไว้อย่างชัดเจน

แล้วด้านเครือข่ายและการเชื่อมต่อล่ะ?

นี่คือจุดที่ Zephyr มีข้อได้เปรียบอย่างชัดเจน Zephyr มาพร้อมกับ Bluetooth LE ที่มีคุณภาพพร้อมใช้งานในผลิตภัณฑ์จริง ทั้งส่วน Host และ Controller, Bluetooth Mesh, OpenThread, การรองรับโปรโตคอล Matter, Wi-Fi, 6LoWPAN, LwM2M และสแต็ก TCP/UDP/IP ที่ครบถ้วน FreeRTOS มี FreeRTOS+TCP รวมถึงไลบรารี coreMQTT และ coreHTTP ผ่านการผสานรวมกับ AWS IoT แต่สำหรับ Bluetooth หรือ Thread โดยทั่วไปแล้ว คุณต้องพึ่งพาสแต็กที่ผู้ผลิตจัดเตรียมไว้โดยเฉพาะ เช่น SoftDevice ของ Nordic หรือสแต็ก Bluetooth ของ Silicon Labs

ควรเลือก FreeRTOS หรือ Zephyr เมื่อใด?

ใช้กรอบการตัดสินใจต่อไปนี้เพื่อช่วยในการเลือก:

• เลือก FreeRTOS เมื่อ: คุณต้องการตัวจัดตารางเวลาที่มีขนาดเล็กที่สุด MCU ของคุณมีหน่วยความจำแฟลชน้อยกว่า 64 KB คุณกำลังทำงานภายใน IDE ของผู้ผลิต หรือโปรเจกต์ของคุณไม่จำเป็นต้องใช้เครือข่ายที่ซับซ้อน
• เลือก Zephyr เมื่อ: คุณต้องการสแต็ก BLE/Thread/Matter ในตัว ต้องการรองรับ Device Tree ต้องการประสบการณ์การพัฒนาที่คล้ายกับ Linux หรือกำลังพัฒนาผลิตภัณฑ์ IoT ที่ซับซ้อน
• พิจารณาทั้งสองระบบเมื่อ: องค์กรของคุณมีผลิตภัณฑ์หลายกลุ่มที่มีระดับความซับซ้อนแตกต่างกัน โดยใช้ FreeRTOS สำหรับเซนเซอร์แบบง่าย และใช้ Zephyr สำหรับอุปกรณ์เกตเวย์
• สิทธิ์การใช้งาน: FreeRTOS ใช้สัญญาอนุญาต MIT ส่วน Zephyr ใช้ Apache 2.0 ทั้งสองเป็นสัญญาอนุญาตแบบเปิดที่มีข้อจำกัดน้อยและเหมาะสำหรับผลิตภัณฑ์เชิงพาณิชย์

ข้อสรุปสำคัญ: เลือก FreeRTOS สำหรับการจัดตารางเวลาที่มีน้ำหนักเบาบน MCU ที่มีทรัพยากรจำกัดและมีหน่วยความจำแฟลชน้อยกว่า 64 KB พร้อมการผสานรวมกับ IDE ของผู้ผลิต เลือก Zephyr สำหรับผลิตภัณฑ์ IoT ที่ซับซ้อนซึ่งต้องใช้สแต็ก BLE, Thread หรือ Matter ในตัว การจัดการฮาร์ดแวร์ผ่าน Device Tree และประสบการณ์การพัฒนาที่คล้ายกับ Linux โดยใช้การกำหนดค่าระบบบิลด์ CMake และ Kconfig

การย้ายจาก FreeRTOS ไปยัง Zephyr ในการใช้งานจริงมีลักษณะอย่างไร?

เมื่อเราพัฒนาตัวควบคุมระบบไฟส่องสว่างแบบ BLE Mesh ให้กับลูกค้ารายหนึ่งที่ EmbedCrest ในช่วงแรกเราได้สร้างต้นแบบบน FreeRTOS โดยใช้สแต็ก BLE SoftDevice ของ Nordic บน nRF52840 อย่างไรก็ตาม เมื่อข้อกำหนดของผลิตภัณฑ์ขยายไปถึงการรองรับเครือข่าย Thread และโปรโตคอล Matter เราจึงย้ายไปใช้ Zephyr RTOS ผ่าน Nordic nRF Connect SDK การย้ายระบบใช้เวลาประมาณสามสัปดาห์สำหรับทีมวิศวกรสองคน การเรียกใช้ฟังก์ชันสร้างทาสก์ (xTaskCreate) ถูกแทนที่ด้วยแมโคร K_THREAD_DEFINE ของ Zephyr คิวของ FreeRTOS เปลี่ยนเป็นคิวข้อความ k_msgq ของ Zephyr และเซมาฟอร์ถูกแทนที่ด้วยองค์ประกอบที่เทียบเท่ากันอย่าง k_sem งานที่ใช้ความพยายามมากที่สุดคือการปรับระบบบิลด์จากโปรเจกต์ Makefile แบบแบนไปเป็นโครงสร้าง west/CMake/Kconfig ของ Zephyr และเขียนโค้ดเข้าถึงฮาร์ดแวร์ใหม่ให้ใช้ API ของ GPIO และ SPI ใน Zephyr ที่อิงกับ Devicetree หลังการย้ายระบบ เราได้รับการรองรับ BLE Mesh, Thread และ Matter โดยตรงโดยไม่ต้องใช้ไลบรารีจากบุคคลที่สามเพิ่มเติม ทำให้จำนวนไลบรารีภายนอกที่ต้องพึ่งพาลดลงจาก 12 ไลบรารีเหลือ 3 ไลบรารี

ข้อผิดพลาดที่พบบ่อยในการเลือก RTOS มีอะไรบ้าง?

ข้อผิดพลาดที่พบบ่อยที่สุดคือการเลือก RTOS โดยพิจารณาจากความนิยมมากกว่าความต้องการของโปรเจกต์ FreeRTOS มักถูกเลือกเป็นค่าเริ่มต้นเนื่องจากมีการใช้งานอย่างแพร่หลาย แต่หลังจากนั้นทีมพัฒนากลับต้องใช้เวลาหลายเดือนในการผสานรวมสแต็กเครือข่าย เฟรมเวิร์กไดรเวอร์ และระบบบิลด์แยกต่างหาก ซึ่ง Zephyr มีให้พร้อมใช้งานตั้งแต่ต้น ในทางกลับกัน การเลือก Zephyr สำหรับโหนดเซนเซอร์แบบง่ายที่มีอุปกรณ์ต่อพ่วง SPI เพียงตัวเดียวและไม่มีการเชื่อมต่อเครือข่าย จะเพิ่มความซับซ้อนโดยไม่จำเป็น ข้อผิดพลาดอีกประการหนึ่งคือการประเมินช่วงการเรียนรู้ต่ำเกินไป โดยวิศวกรที่คุ้นเคยกับ IDE ของผู้ผลิตและ FreeRTOS อาจต้องใช้เวลา 2–4 สัปดาห์ในการทำความคุ้นเคยกับ Devicetree, Kconfig และเครื่องมือ West ของ Zephyr ควรประเมินความพยายามในการผสานรวมทั้งหมด ไม่ใช่พิจารณาเฉพาะตัวเคอร์เนล หากผลิตภัณฑ์ของคุณต้องใช้ BLE หรือ Thread การเลือก Zephyr จะช่วยลดเวลาการผสานรวมสแต็กได้ 2–3 เดือน แต่หากผลิตภัณฑ์ของคุณเป็นเพียงเซนเซอร์พื้นฐานที่ส่งข้อมูลผ่าน UART การใช้ FreeRTOS หรือแม้แต่การพัฒนาแบบ Bare-metal จะเหมาะสมกว่า

ขนาดหน่วยความจำที่ใช้แตกต่างกันอย่างไรในการใช้งานจริง?

ในเฟิร์มแวร์สำหรับผลิตภัณฑ์จริง ความแตกต่างของขนาดหน่วยความจำที่ใช้ถือว่ามีนัยสำคัญสำหรับอุปกรณ์เป้าหมายที่มีทรัพยากรจำกัด แอปพลิเคชัน FreeRTOS ขั้นต่ำ (ตัวจัดตารางเวลา ทาสก์สองรายการ คิวหนึ่งชุด และเซมาฟอร์หนึ่งตัว) เมื่อคอมไพล์ด้วย GCC โดยใช้การปรับแต่ง -Os จะใช้หน่วยความจำแฟลชประมาณ 6–9 KB และ RAM 1–2 KB บน Cortex-M4 ส่วนแอปพลิเคชัน Zephyr ที่เทียบเท่ากัน (เคอร์เนล เธรดสองรายการ คิวข้อความหนึ่งชุด และเซมาฟอร์หนึ่งตัว) จะใช้หน่วยความจำแฟลช 12–18 KB และ RAM 4–6 KB อย่างไรก็ตาม เมื่อเพิ่มการเชื่อมต่อ BLE ความแตกต่างนี้จะลดลงอย่างมาก โดย FreeRTOS ร่วมกับ Nordic SoftDevice และ NimBLE จะใช้หน่วยความจำแฟลช 200–280 KB ขณะที่ Zephyr ซึ่งมี BLE Host และ Controller ในตัวจะใช้หน่วยความจำแฟลช 180–250 KB สำหรับแอปพลิเคชัน Matter over Thread แบบเต็มรูปแบบ สแต็กที่ผสานรวมอยู่ใน Zephyr จะใช้หน่วยความจำแฟลชรวม 450–600 KB ในขณะที่ระบบที่เทียบเท่ากันบน FreeRTOS ต้องนำ OpenThread, Matter SDK และสแต็ก BLE สำหรับการตั้งค่าเริ่มต้นของอุปกรณ์มาประกอบเข้าด้วยกันแยกต่างหาก ซึ่งมักใช้หน่วยความจำเกิน 550 KB และมีความซับซ้อนในการผสานรวมมากกว่า โปรเจกต์ที่มีข้อจำกัดด้านหน่วยความจำและใช้ MCU ที่มีหน่วยความจำแฟลชไม่เกิน 64 KB ควรเลือก FreeRTOS เป็นหลัก ส่วนโปรเจกต์ที่ใช้ MCU ซึ่งมีหน่วยความจำแฟลชตั้งแต่ 512 KB ขึ้นไปและมีข้อกำหนดด้านเครือข่าย จะได้รับประโยชน์จากแนวทางการผสานรวมองค์ประกอบต่าง ๆ ของ Zephyr