ระบบปฏิบัติการแบบเรียลไทม์ (RTOS) และแอปพลิเคชัน

RTOS คืออะไร

ระบบปฏิบัติการแบบเรียลไทม์ (RTOS) เป็นระบบปฏิบัติการขนาดเล็กที่ใช้เพื่อลดความสะดวกในการทำงานหลายอย่างและรวมงานในการออกแบบที่ จำกัด ทรัพยากรและเวลาซึ่งโดยปกติจะเป็นกรณีในระบบฝังตัว นอกจากนี้คำว่า“ เรียลไทม์” ยังบ่งบอกถึงความสามารถในการคาดการณ์/การกำหนดในเวลาดำเนินการมากกว่าความเร็วดิบดังนั้น RTOS จึงสามารถพิสูจน์ได้ว่าตอบสนองความต้องการแบบเรียลไทม์ที่ยากเนื่องจากปัจจัยกำหนด

แนวคิดหลักของ RTOS คือ:

งาน

งาน (อาจเรียกอีกอย่างว่า กระบวนการ/เธรด) เป็นฟังก์ชันอิสระที่ทำงานในลูปแบบไม่มีที่สิ้นสุดโดยปกติแล้วแต่ละฟังก์ชันจะรับผิดชอบต่อคุณลักษณะ งานกำลังดำเนินไปอย่างอิสระในเวลาของตัวเอง (การแยกชั่วคราว) และสแต็กหน่วยความจำ (การแยกเชิงพื้นที่) สามารถรับประกันการแยกเชิงพื้นที่ระหว่างงานด้วยการใช้หน่วยป้องกันหน่วยความจำฮาร์ดแวร์ (MPU) ซึ่ง จำกัด ขอบเขตหน่วยความจำที่สามารถเข้าถึงได้และเรียกใช้ข้อผิดพลาดเกี่ยวกับการละเมิดการเข้าถึง โดยปกติอุปกรณ์ต่อพ่วงภายในจะมีการแมปหน่วยความจำดังนั้นจึงสามารถใช้ MPU เพื่อ จำกัด การเข้าถึงอุปกรณ์ต่อพ่วงได้เช่นกัน

งานอาจอยู่ในสถานะที่แตกต่างกัน:

• ถูกบล็อก - งานกำลังรอเหตุการณ์ (เช่นการหมดเวลาล่าช้าความพร้อมใช้งานของข้อมูล/ทรัพยากร)
• พร้อม - งานพร้อมที่จะทำงานบน CPU แต่ไม่ทำงานเนื่องจาก CPU ถูกใช้งานโดยงานอื่น
• กำลังทำงาน - งานถูกกำหนดให้ทำงานบน CPU

เครื่องมือจัดกำหนดการ

ตัวกำหนดตารางเวลาใน RTOS จะควบคุมว่างานใดที่จะรันบน CPU และอัลกอริทึมการตั้งเวลาที่แตกต่างกันจะพร้อมใช้งาน โดยปกติพวกเขาคือ:

• Pre-emptive - การสั่งงานอาจถูกขัดจังหวะหากงานอื่นที่มีลำดับความสำคัญสูงกว่าพร้อม
• Co-operative - การสลับงานจะเกิดขึ้นก็ต่อเมื่องานที่กำลังรันอยู่ให้ผลตอบแทน

การจัดกำหนดการล่วงหน้าช่วยให้งานที่มีลำดับความสำคัญสูงกว่าสามารถขัดจังหวะงานที่ต่ำกว่าเพื่อตอบสนองข้อจำกัดแบบเรียลไทม์ แต่ต้องเสียค่าใช้จ่ายมากขึ้นในการสลับบริบท

การสื่อสารระหว่างงาน (ITC)

โดยปกติงานหลายอย่างจะต้องแบ่งปันข้อมูลหรือเหตุการณ์ซึ่งกันและกัน วิธีที่ง่ายที่สุดในการแบ่งปันคือการอ่าน/เขียนตัวแปรส่วนกลางที่แชร์ใน RAM โดยตรง แต่สิ่งนี้ไม่เป็นที่พึงปรารถนาเนื่องจากความเสี่ยงของข้อมูลเสียหายที่เกิดจากสภาวะการแข่งขัน วิธีที่ดีกว่าคือการอ่าน/เขียนตัวแปรคงที่ที่กำหนดขอบเขตไฟล์ซึ่งสามารถเข้าถึงได้โดยฟังก์ชัน setter และ getter และเงื่อนไขการแข่งขันสามารถป้องกันได้โดยการปิดใช้งานอินเทอร์รัปต์หรือใช้อ็อบเจ็กต์การแยกซึ่งกันและกัน (mutex) ภายในฟังก์ชัน setter/getter วิธีที่สะอาดกว่าคือใช้อ็อบเจ็กต์ RTOS ที่ปลอดภัยต่อเธรด เช่นคิวข้อความเพื่อส่งผ่านข้อมูลระหว่างงาน

นอกเหนือจากการแบ่งปันข้อมูลแล้วอ็อบเจ็กต์ RTOS ยังสามารถซิงโครไนซ์การเรียกใช้งานเนื่องจากงานสามารถถูกบล็อกเพื่อรอให้อ็อบเจ็กต์ RTOS พร้อมใช้งาน RTOS ส่วนใหญ่มีวัตถุเช่น:

• คิวข้อความ
  • First-in-first-out (FIFO) คิวเพื่อส่งผ่านข้อมูล
  • ข้อมูลสามารถส่งโดยการคัดลอกหรือโดยการอ้างอิง (ตัวชี้)
  • ใช้เพื่อส่งข้อมูลระหว่างงานหรือระหว่างการขัดจังหวะและงาน
• สัญญาณ
  • สามารถถือเป็นตัวนับอ้างอิงเพื่อบันทึกความพร้อมใช้งานของทรัพยากรเฉพาะ
  • สามารถเป็นสัญญาณไบนารีหรือการนับ
  • ใช้เพื่อป้องกันการใช้ทรัพยากรหรือซิงโครไนซ์การดำเนินงาน
• Mutex
  • คล้ายกับสัญญาณไบนารีโดยทั่วไปใช้เพื่อป้องกันการใช้ทรัพยากรเดียว (MUTual EXclusion)
  • FreeRTOS mutex มาพร้อมกับกลไกการสืบทอดลำดับความสำคัญเพื่อหลีกเลี่ยงปัญหาการผกผันลำดับความสำคัญ (เงื่อนไขเมื่องานที่มีลำดับความสำคัญสูงจบลงด้วยการรองานลำดับความสำคัญต่ำกว่า)
• กล่องจดหมาย
  • ตำแหน่งที่จัดเก็บอย่างง่ายเพื่อแบ่งปันตัวแปรเดียว
  • ถือได้ว่าเป็นคิวองค์ประกอบเดียว
• กลุ่มกิจกรรม
  • กลุ่มเงื่อนไข (ความพร้อมใช้งานของเซมาฟอร์คิวแฟล็กเหตุการณ์ ฯลฯ)
  • งานสามารถถูกปิดกั้นและสามารถรอให้เงื่อนไขการรวมที่เฉพาะเจาะจงสำเร็จได้
  • มีให้ใน Zephyr เป็น Polling API ใน FreeRTOS เป็น QueueSets

ระบบติ๊ก

RTOS ต้องการฐานเวลาในการวัดเวลาโดยปกติจะอยู่ในรูปแบบของตัวแปรตัวนับขีดระบบที่เพิ่มขึ้นในการขัดจังหวะตัวจับเวลาฮาร์ดแวร์เป็นระยะ ด้วยการติ๊กระบบแอปพลิเคชันสามารถรักษาบริการตามเวลาได้มากกว่า (ช่วงการดำเนินงานการหมดเวลารอการแบ่งเวลา) โดยใช้ตัวจับเวลาฮาร์ดแวร์เพียงตัวเดียว อย่างไรก็ตามอัตราติ๊กที่สูงขึ้นจะเพิ่มความละเอียดฐานเวลาของ RTOS เท่านั้น แต่จะไม่ทำให้ซอฟต์แวร์ทำงานได้เร็วขึ้น

เหตุใดจึงต้องใช้ RTOS

องค์กร

แอปพลิเคชันสามารถเขียนด้วยวิธี bare metal ได้เสมอ แต่เมื่อความซับซ้อนของโค้ดเพิ่มขึ้นการมีโครงสร้างบางอย่างจะช่วยในการจัดการส่วนต่างๆของแอปพลิเคชันทำให้แยกส่วน ยิ่งไปกว่านั้นด้วยวิธีการพัฒนาที่มีโครงสร้างและภาษาการออกแบบที่คุ้นเคยสมาชิกในทีมใหม่จะสามารถเข้าใจโค้ดและเริ่มมีส่วนร่วมได้เร็วขึ้น RFCOM Technologies ได้พัฒนาแอปพลิเคชันโดยใช้ไมโครคอนโทรลเลอร์ที่แตกต่างกัน เช่น อุปกรณ์จาก Texas Instruments Hercules, จาก Renesas RL78และ Rxและ จาก STMicroelectronics STM32 บน RTOS อื่น ๆ รูปแบบการออกแบบที่คล้ายกันช่วยให้เราสามารถพัฒนาแอปพลิเคชันบนไมโครคอนโทรลเลอร์ที่แตกต่างกันและแม้แต่ RTOS ที่แตกต่างกัน

ความเป็นโมดูลาร์

แบ่งและพิชิต ด้วยการแยกคุณสมบัติในงานที่แตกต่างกันทำให้สามารถเพิ่มคุณสมบัติใหม่ ๆ ได้อย่างง่ายดายโดยไม่ทำลายคุณสมบัติอื่น ๆ โดยมีเงื่อนไขว่าคุณลักษณะใหม่นี้จะไม่โอเวอร์โหลดทรัพยากรที่ใช้ร่วมกันเช่น CPU และอุปกรณ์ต่อพ่วง การพัฒนาโดยไม่ใช้ RTOS โดยปกติจะอยู่ในลูปขนาดใหญ่ที่ไม่มีที่สิ้นสุดซึ่งคุณลักษณะทั้งหมดเป็นส่วนหนึ่งของลูป การเปลี่ยนแปลงคุณสมบัติใด ๆ ภายในลูปจะส่งผลกระทบต่อคุณสมบัติอื่น ๆ ทำให้ซอฟต์แวร์แก้ไขและบำรุงรักษาได้ยาก

กองการสื่อสารและไดรเวอร์

ไดรเวอร์หรือสแต็กเพิ่มเติมจำนวนมากเช่น TCP/IP, USB, BLE stacks และไลบรารีกราฟิกได้รับการพัฒนา/พอร์ตสำหรับ/ไปยัง RTOSs ที่มีอยู่ นักพัฒนาแอปพลิเคชันสามารถมุ่งเน้นไปที่เลเยอร์แอปพลิเคชันของซอฟต์แวร์และลดเวลาในการทำตลาดได้อย่างมาก

เคล็ดลับ

การจัดสรรแบบคงที่

การใช้การจัดสรรหน่วยความจำแบบคงที่สำหรับอ็อบเจ็กต์ RTOS หมายถึงการสำรองหน่วยความจำสแต็กใน RAM สำหรับอ็อบเจ็กต์ RTOS แต่ละตัวในช่วงเวลาคอมไพล์ ตัวอย่างของฟังก์ชันการจัดสรรแบบคงที่ใน freeRTOS คือ xTaskCreateStatic() สิ่งนี้ช่วยให้มั่นใจได้ว่าสามารถสร้างอ็อบเจ็กต์ RTOS ได้สำเร็จช่วยประหยัดความยุ่งยากในการจัดการการจัดสรรที่ล้มเหลวที่เป็นไปได้และทำให้แอปพลิเคชันมีความมุ่งมั่นมากขึ้น

ในแง่ของการกำหนดขนาดสแต็กที่จำเป็นสำหรับงานนั้นสามารถรันงานด้วยขนาดสแต็กที่ใหญ่กว่า (มากเกินพอ) จากนั้นสามารถตรวจสอบการใช้งานสแต็กในรันไทม์เพื่อกำหนดเครื่องหมายน้ำสูง มีเครื่องมือวิเคราะห์สแต็กแบบคงที่พร้อมใช้งานเช่นกัน

เลเยอร์นามธรรมของระบบปฏิบัติการ (OSAL) และนามธรรมที่มีความหมาย

เช่นเดียวกับ Hardware Abstraction Layer (HAL) การใช้ชั้นนามธรรม RTOS ช่วยให้ซอฟต์แวร์แอปพลิเคชันโยกย้ายไปยัง RTOSs อื่น ๆ ได้อย่างง่ายดาย คุณสมบัติของ RTOSs นั้นค่อนข้างคล้ายกันดังนั้นการสร้าง OSAL จึงไม่ควรซับซ้อนเกินไป ตัวอย่างเช่น:

การใช้ freeRTOS API โดยตรง:

if( xSemaphoreTake( spiMutex, ( TickType_t ) 10 ) == pdTRUE ) { //dosomething }

การรวม RTOS API ลงใน OSAL:

if( osalSemTake( spiMutex, 10 ) == true) { //dosomething }

การใช้เลเยอร์นามธรรมในการสื่อสารระหว่างงานเพื่อทำให้โค้ดอ่านง่ายขึ้นและลดขอบเขตของอ็อบเจ็กต์ RTOS:

if( isSpiReadyWithinMs( 10 ) ) { //doSomething }

นอกจากนี้สิ่งที่เป็นนามธรรมยังอนุญาตให้โปรแกรมเมอร์เปลี่ยนอ็อบเจ็กต์ RTOS ที่ใช้ด้านล่าง (เช่นจาก mutex ไปจนถึงการนับเซมาฟอร์) หากมีโมดูล SPI มากกว่าหนึ่งโมดูล OSAL และเลเยอร์นามธรรมอื่น ๆ ช่วยในการทดสอบซอฟต์แวร์เช่นกันโดยลดความซับซ้อนของการแทรกฟังก์ชันจำลองระหว่างการทดสอบหน่วย

เลือกช่วงเวลา

ตามหลักการแล้วอัตราติ๊กที่ต่ำจะดีกว่าเนื่องจากมีค่าใช้จ่ายน้อยกว่า ในการเลือกอัตราติ๊กที่เหมาะสมผู้พัฒนาสามารถระบุข้อ จำกัด ด้านเวลาของโมดูลในแอปพลิเคชัน (ช่วงเวลาการทำซ้ำระยะเวลาการหมดเวลา ฯลฯ ) หากมีโมดูลผิดปกติบางโมดูลที่ต้องการช่วงเวลาเล็ก ๆ การมีการขัดจังหวะตัวจับเวลาเฉพาะสามารถพิจารณาได้สำหรับโมดูลที่ผิดปกติแทนที่จะเพิ่มอัตราติ๊ก RTOS หากฟังก์ชันความถี่สูงสั้นมาก (เช่น เขียนลงทะเบียนเพื่อเปิด/ปิด LED) สามารถทำได้ภายใน Interrupt Service Routine (ISR) มิฉะนั้นจะใช้การจัดการการขัดจังหวะที่เลื่อนออกไปได้ การจัดการอินเตอร์รัปต์รอการตัดบัญชีเป็นเทคนิคในการเลื่อนการคำนวณอินเทอร์รัปต์ไปเป็นงาน RTOS โดย ISR จะสร้างเหตุการณ์ผ่านอ็อบเจ็กต์ RTOS จากนั้นงาน RTOS จะถูกยกเลิกการปิดกั้นโดยเหตุการณ์และทำการคำนวณ

การป้องกันการติ๊กสำหรับการใช้พลังงานต่ำ

ไม่ได้ใช้งานแบบไร้ขีดจำกัดจะปิดใช้งานการขัดจังหวะการทำเครื่องหมายเมื่อระบบไม่ได้ใช้งานเป็นเวลานานขึ้น วิธีหนึ่งที่สำคัญสำหรับเฟิร์มแวร์ในตัวเพื่อลดการใช้พลังงานคือทำให้ระบบอยู่ในโหมดพลังงานต่ำให้นานที่สุด ไม่ได้ใช้งานแบบไม่ต้องใช้งานโดยการปิดใช้งานการขัดจังหวะติ๊กเป็นระยะจากนั้นตั้งค่าตัวจับเวลานับถอยหลังเพื่อขัดจังหวะเมื่องานที่ถูกบล็อกถึงกำหนดดำเนินการ หากไม่มีงานที่รอการหมดเวลาการขัดจังหวะติ๊กสามารถปิดใช้งานได้โดยไม่มีกำหนดจนกว่าจะมีการขัดจังหวะอื่นเกิดขึ้น (เช่น กดปุ่ม) ตัวอย่างเช่นในกรณีของสัญญาณบลูทูธพลังงานต่ำ (BLE), MCU สามารถเข้าสู่โหมดสลีประหว่างช่วงเวลาโฆษณาได้ ดังแสดงในรูปที่ 1 สัญญาณเตือนจะเข้าสู่โหมดหลับลึกเป็นเวลาเกือบตลอดเวลาโดยใช้พลังงานเป็นสิบ ๆ µA

รูป 1: การใช้สัญญาณ BLE ในปัจจุบัน (แหล่งรูปภาพ: RFCOM)

สรุป

RTOS มีคุณสมบัติเช่นตัวกำหนดตารางเวลางานและอ็อบเจ็กต์ RTOS การสื่อสารระหว่างงานตลอดจนสแตกการสื่อสารและไดรเวอร์ ช่วยให้นักพัฒนาสามารถมุ่งเน้นไปที่เลเยอร์แอปพลิเคชันของซอฟต์แวร์ฝังตัวและออกแบบซอฟต์แวร์มัลติทาสก์ได้อย่างง่ายดายและรวดเร็ว อย่างไรก็ตามเช่นเดียวกับเครื่องมืออื่น ๆ ต้องใช้อย่างถูกต้องเพื่อให้เกิดมูลค่ามากขึ้น ในการสร้างซอฟต์แวร์ฝังตัวที่ปลอดภัยปลอดภัยและมีประสิทธิภาพ นักพัฒนาควรทราบว่าเมื่อใดควรใช้คุณสมบัติ RTOS และวิธีกำหนดค่า RTOS