ประโยชน์ของ RTOS กับ Bare Metal สำหรับการเขียนโปรแกรม MCU?

11

โปรดทราบ:คำถามนี้กล่าวถึง RTOS สองตัวโดยเฉพาะ แต่มีความเป็นทั่วไปมากกว่าและใคร ๆ ก็สามารถตอบได้โดยเขียนรหัส C สำหรับ RTOSes แบบฝังตัวก่อนหน้านี้และให้ซอฟต์แวร์ทำงานโดยตรงบน MCU

ฉันสนใจที่จะเรียนรู้เพิ่มเติมเกี่ยวกับ RTOS แบบฝังและการเขียนแอปพลิเคชันสำหรับพวกเขา ฉันกำลังดูEmboxและRIOTเพราะพวกเขาเป็นโอเพ่นซอร์สที่ทันสมัยใช้งานได้และดูเหมือนจะมีเอกสารที่ยอดเยี่ยม เป้าหมายของฉันมีสองขั้นตอน: ระยะที่ 1 คือการหาวิธีการคอมไพล์และแฟลชระบบปฏิบัติการเหล่านี้ไปยัง MCU (อาจเป็น AVR หรือ ARM) ขั้นตอนที่ 2 คือเขียนโปรแกรม C อย่างง่าย (โดยทั่วไปคือ daemon ไร้หัว) ซึ่งจะพัฒนาไปตามเวลาเป็น "งานอดิเรก" จากนั้นฉันจะแฟลช / ปรับใช้โปรแกรมนี้กับ MCU เดียวกันดังนั้นจึงประสบความสำเร็จในการปรับใช้ appstack ซึ่งประกอบด้วย Embox / RIOT และแอพของฉันอยู่ด้านบนของมัน

ก่อนที่ผมจะไปลงถนนใด ๆ ที่ในที่สุดนำไปสู่การสิ้นสุดตายผมเจอบทความนี้ที่จะได้งานที่ดีงามของการอธิบายว่าทำไมปพลิเคชันแบบ real-time เขียนใน C / ประกอบและประกายเพื่อ MCUs ไม่ได้จริงๆ RTOSes ต้องอยู่ภายใต้ .

ดังนั้นตอนนี้ฉันสับสนจริงๆและกำลังตั้งคำถามกับความเข้าใจพื้นฐานของฉันเกี่ยวกับทฤษฎีการคำนวณ ฉันเดาว่าฉันกำลังพยายามตัดสินใจว่าจะใช้ Embox หรือ RIOT ตั้งแต่แรกหรือไม่:

อยู่ที่แน่นอนและไปกับ "แอปสแต็ค" บน MCU ของทั้ง OS + app; หรือ
ฟังคำเตือนของบทความและเพียงไปกับ MCU ที่รันแอพของฉัน "โลหะเปลือย"

เห็นได้ชัดว่าอดีตเป็นงานมากขึ้นและดังนั้นจึงมีเหตุผลที่ดีกว่า / ผลตอบแทนที่ดีสำหรับการไปเส้นทางนั้น ดังนั้นฉันจึงถาม: ประโยชน์ที่แท้จริงของ RTOS ที่ฝังตัว (และคล้ายกัน) เหล่านี้มีให้กับนักพัฒนาแอป MCU / C อย่างไร ฟีเจอร์เฉพาะใดที่แอพ C ของฉันจะได้รับประโยชน์ (บางทีอาจจะไม่ใช่การสร้างล้อใหม่) โดยใช้ RTOS สิ่งที่หายไปจากการทำ RTOS และไปทำโลหะเปลือย?

ฉันขอตัวอย่างที่เป็นรูปธรรมที่นี่ไม่ใช่สื่อโฆษณาที่คุณได้รับเมื่อคุณไปที่รายการวิกิพีเดียสำหรับ RTOSes ;-)

c operating-systems real-time arm

— smeeb
แหล่งที่มา

3

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

— whatsisname

ขอบคุณ @whatsisname (+1) - นั่นคือคำแนะนำที่ดีและฉันน่าจะนำคุณไปสู่ ฉันไม่คิดว่ามันเป็นมารยาทที่จะยังคงสนใจในสิ่งที่ RTOSes เสนอแม้ว่าฉันจะเป็นเดือน / ปีจากการต้องการพวกเขา ฉันเดาว่าฉันต้องการเห็นภาพรวมทั้งหมดในมุมมอง 30,000 ฟุต ขอบคุณอีกครั้ง!

— smeeb

11

โปรแกรมไมโครคอนโทรลเลอร์ประกอบด้วยจำนวนของงาน สมมติว่าคุณต้องการติดตั้งกล้องควบคุมด้วยคอมพิวเตอร์ งานจะเป็น:

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

นี่เป็นชุดงานที่ค่อนข้างทั่วไปสำหรับบางสิ่งที่คุณจะใช้ไมโครคอนโทรลเลอร์และค่อนข้างง่ายในการจัดการด้วยลูปไม่ จำกัด เช่น:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

หากคุณยังคงเพิ่มและเพิ่มคุณสมบัติในที่สุดคุณก็จะเริ่มพบกับปัญหาทั่วไปที่คุณต้องการสร้าง abstractions ให้เช่น:

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

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

อย่างไรก็ตามจากประสบการณ์ของฉันบรรทัดที่คุณต้องการ RTOS นั้นอยู่ใกล้กับบรรทัดที่คุณต้องการไมโครโปรเซสเซอร์แทนไมโครคอนโทรลเลอร์ หากคุณคาดว่าเฟิร์มแวร์ของคุณจะมีความซับซ้อนนั้นโดยปกติแล้วจะเป็นการดีกว่าที่จะไปเส้นทางไมโครโปรเซสเซอร์ตั้งแต่เริ่มต้น

— Karl Bielefeldt
แหล่งที่มา

นี่คือการวิเคราะห์ที่ยอดเยี่ยมและทำให้ฉันชัดเจนจริงๆ ฉันเห็นด้วยกับสิ่งที่คุณพูด แต่ฉันเห็นด้วยกับคำตอบจาก @Atsby มากขึ้น โดยเฉพาะถ้าเป้าหมายคือการเรียนรู้ / พัฒนาทักษะของตัวเอง ในระบบการผลิตอาจดีกว่าด้วยผลิตภัณฑ์ COTS หรือ RTLinux แต่เพื่อให้สามารถแก้ไขข้อบกพร่องในระดับต่ำได้เมื่อเกิดข้อผิดพลาดฉันจะต้องเขียนโค้ดที่ทำหลายครั้งในรายการดังกล่าว เป็นไปได้

— Sam Hammamy

7

ฉันเขียนไลบรารีมัลติเธรดแบบร่วมมือของตัวเองสำหรับ ARM Cortex-M0

มันเป็นโค้ดไม่กี่หน้าและรุ่นแรกนั้นใช้เวลาในการเขียนและดีบักไม่เกินหนึ่งวัน

ข้อได้เปรียบที่สำคัญของการม้วนตัวคุณเองคือคุณรู้รหัสและคุณสามารถนำไปใช้กับชิปที่ RTOS อาจไม่รองรับ นอกจากนี้คุณใช้เวลาคิดคำถามน้อยลงเช่น "ฉันจะลองใช้คุณสมบัติ A และ B พร้อมกันหรือไม่" เมื่อคุณเขียนรหัสคุณก็รู้คำตอบ

การทำเกลียวเป็นสิ่งสำคัญที่คุณได้รับจาก RTOS และกลายเป็นว่าไม่ใช่เรื่องใหญ่อะไรที่จะทำให้สำเร็จ หายากที่คุณต้องการคุณสมบัติมากมายของ RTOS แต่ถ้าคุณกระทืบความต้องการของคุณและมันกลายเป็นว่าคุณทำแล้วให้ใช้ RTOS

— Atsby
แหล่งที่มา

ขอบคุณ @Atsby! คำตอบนี้ช่วยให้ฉันตัดสินใจได้ว่าจะคุ้มค่ากับการลงทุนเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับ Bare Metal หรือไม่ ฉันได้เขียนสิ่งที่เป็นจำนวนมากในห้องสมุด GPIO ในโลหะเปลือยสำหรับ Pi และฉันคิดว่าตอนนี้ถึงเวลาที่จะก้าวไปอีกขั้นหนึ่งหรือสองขั้น ขอบคุณ!

— Sam Hammamy