ฉันได้เขียนโค้ดโลหะเปลือยมากมายสำหรับโปรเซสเซอร์ PIC และ x86 มีคนบอกฉันได้อย่างไรว่าจะต้องใช้ระบบปฏิบัติการและเมื่อไร ในทางกลับกันแอพพลิเคชั่นหรือสถานการณ์ใดบ้างที่สามารถจัดการกับหรือไม่มีระบบปฏิบัติการด้วย
ฉันได้เขียนโค้ดโลหะเปลือยมากมายสำหรับโปรเซสเซอร์ PIC และ x86 มีคนบอกฉันได้อย่างไรว่าจะต้องใช้ระบบปฏิบัติการและเมื่อไร ในทางกลับกันแอพพลิเคชั่นหรือสถานการณ์ใดบ้างที่สามารถจัดการกับหรือไม่มีระบบปฏิบัติการด้วย
คำตอบ:
กฎง่ายๆของฉันคือคุณควรพิจารณาระบบปฏิบัติการหากผลิตภัณฑ์ต้องการสิ่งใดสิ่งหนึ่งต่อไปนี้: สแต็ก TCP / IP (หรือสแต็กเครือข่ายที่ซับซ้อนอื่น ๆ ), GUI ที่ซับซ้อน (อาจเป็นระบบที่มีวัตถุ GUI เช่นหน้าต่างและเหตุการณ์ ) หรือระบบไฟล์
หากคุณทำการเขียนโค้ดโลหะเปลือยแล้วคุณอาจคุ้นเคยกับสถาปัตยกรรมของโปรแกรมการวนรอบสูง หากความต้องการเฟิร์มแวร์ของผลิตภัณฑ์นั้นง่ายพอที่จะนำไปใช้กับซุปเปอร์ลูปที่สามารถบำรุงรักษาได้ (และหวังว่าจะขยายได้ค่อนข้างมาก) คุณอาจไม่จำเป็นต้องใช้ระบบปฏิบัติการ
เมื่อความต้องการซอฟต์แวร์เพิ่มขึ้นซุปเปอร์ลูปจะซับซ้อนมากขึ้น เมื่อความต้องการซอฟต์แวร์มีจำนวนมากจนซุปเปอร์ลูปซับซ้อนเกินไปหรือไม่สามารถทำตามข้อกำหนดแบบเรียลไทม์ของระบบได้ดังนั้นถึงเวลาพิจารณาสถาปัตยกรรมอื่นแล้ว
สถาปัตยกรรม RTOS ช่วยให้คุณสามารถแบ่งข้อกำหนดของซอฟต์แวร์ออกเป็นงานต่างๆได้ หากทำอย่างถูกต้องสิ่งนี้จะช่วยให้การปฏิบัติงานแต่ละอย่างง่ายขึ้น และด้วยการจัดลำดับความสำคัญของงาน RTOS สามารถทำให้ตอบสนองความต้องการตามเวลาจริงได้ง่ายขึ้น อย่างไรก็ตาม RTOS ไม่ใช่ยาครอบจักรวาล RTOS จะเพิ่มความซับซ้อนของระบบโดยรวมและทำให้คุณมีข้อบกพร่องประเภทใหม่ (เช่นการหยุดชะงัก) เป็นอีกทางเลือกหนึ่งสำหรับ RTOS คุณอาจพิจารณาและสถาปัตยกรรมสถานะของเครื่องตามเหตุการณ์ (เช่นQP )
หากผลิตภัณฑ์ของคุณมีระบบเครือข่าย GUI ที่ซับซ้อนและระบบไฟล์คุณอาจถึงจุดที่คุณควรพิจารณาระบบปฏิบัติการที่มีคุณสมบัติครบถ้วนเช่น VxWorks, Windows หรือ Linux ระบบปฏิบัติการที่มีคุณสมบัติครบถ้วนจะมีไดรเวอร์สำหรับรายละเอียดในระดับต่ำและช่วยให้คุณสามารถมุ่งเน้นไปที่แอปพลิเคชันของคุณ
มันขึ้นอยู่กับคำจำกัดความของคุณของ 'ระบบฝังตัว' อาจมีบางคนที่อ้างว่าถ้าไม่ใช่การเขียนโปรแกรมโลหะเปลือยมันไม่ได้ฝัง (ซึ่งห้ามคำถามของคุณ) แต่ฉันไม่เห็นด้วยกับสิ่งนั้น - ฉันจะเถียงว่าระบบใด ๆ ที่ออกแบบมาเพื่อทำหน้าที่เดียวเท่านั้น คือเพื่อเรียกใช้ 'แอปพลิเคชั่น' หนึ่งตัวเท่านั้นอาจเรียกว่าระบบฝังตัว
ที่กล่าวมามันควรจะค่อนข้างง่ายที่จะจินตนาการถึงสถานการณ์ที่จะได้รับประโยชน์จากบริการต่างๆของระบบปฏิบัติการเต็มรูปแบบ ตัวอย่างเช่นที่ฉันทำงานมันเป็นเรื่องธรรมดามากที่จะหาคนกำลังสร้างอุปกรณ์ทดสอบที่ด้านบนของชุดเครื่องมือออกแบบที่ทำงานอยู่ด้านบนของหน้าต่าง ระบบเหล่านี้ได้รับการกำหนดค่าให้บูตเข้าสู่การกำหนดค่าสถานีทดสอบและล็อคการใช้งานทั่วไป (เพื่อป้องกันความเสียหายของสถานี) และดังนั้นจึงเป็นระบบฝังตัว
อย่างไรก็ตามเพียงแค่ซื้อโมดูล I / O ที่ไม่ได้วางจำหน่ายแล้วเสียบเข้ากับแร็คพีซีและการกำหนดค่าใน GUI อาจล้มเหลวในการมีคุณสมบัติเหมือนการออกแบบระบบฝังตัวสำหรับบางคน สำหรับสถานการณ์นอกชั้นเรียนให้พิจารณาตัวควบคุมกระบวนการที่กำหนดเองด้วย FPGA ซึ่งคุณต้องการบันทึกข้อมูลแฟนซี คุณอาจฝังระบบตัวประมวลผลแบบ soft-core (ด้วย BSP ที่มีอยู่แล้ว) และเรียกใช้ linux แบบเรียลไทม์เพื่อเรียกใช้เครือข่ายสแต็ก (สำหรับการบันทึกและ NTP ของคุณเป็นต้น) และทำทุกอย่างเป็นตรรกะ
กฎหัวแม่มือ (คลุมเครือ) ของฉันคือถ้าคุณต้องการมากกว่าหนึ่งเธรดการควบคุม (พูดอย่างน้อยหนึ่งอุปกรณ์ที่เกี่ยวข้องกับโพรโทคอลหรือเครื่องสถานะรวมทั้งสิ่งอื่นที่ต้องทำ) จากนั้นซอฟต์แวร์ OSish บางตัวจะทำให้ชีวิตของคุณง่ายขึ้น
switch
-based เครื่องรัฐเกินกว่าที่switch
เครื่อง -based มีแนวโน้มที่จะดีกว่า นอกจากนี้บนทั้งแพลตฟอร์ม 8x51 และ TMS2000 ฉันได้ติดตั้ง task-based task-switcher แบบง่าย ไม่มีตรรกะของระบบปฏิบัติการที่จะตัดสินใจเมื่อต้องสลับ - เมื่อใดก็ตามที่ "เธรด" หนึ่งรู้สึกว่ามันจะหยุดพักก็จะสลับไปที่อื่น หากเธรดอื่นเห็นว่ามีบางสิ่งที่รอยังไม่เกิดขึ้นก็สามารถสลับกลับเป็นครั้งแรกในเวลาที่น้อยกว่าระบบปฏิบัติการปกติที่จะใช้ในการตัดสินใจว่าจะเปลี่ยนหรือไม่
คำถามเก่า แต่ฉันจะแสดงความคิดเห็นต่อไป
แม้ว่าคุณจะไม่มีเครือข่ายสแต็คหรือคล้ายกัน ณ จุดที่คุณต้องการตัวจัดกำหนดการงานเนื่องจากคุณมีกระบวนการเพียงพอในแอปพลิเคชันที่ฝังตัวของคุณคุณอาจพิจารณา RTOS การเขียนตัวกำหนดเวลามัลติทาสกิ้งที่ทำงานร่วมกันบนตัวจับเวลาอย่างง่ายไม่ใช่เรื่องยาก แต่ต้องแน่ใจว่ากระบวนการที่ติดอยู่จะไม่บล็อกแอปพลิเคชั่นที่เหลือและอาจใช้เวลาสักพักเพื่อให้ถูกต้อง คุณต้องใช้ระบบที่มีลำดับความสำคัญพร้อมกับการเตรียมการบางอย่างเพื่อให้กระบวนการลงในคิวหากยังไม่เสร็จสมบูรณ์
RTOS ยังให้สิ่งต่าง ๆ เช่นการป้องกันหน่วยความจำและสิ่งที่ทำให้การติดตาม gaffes ทั่วไปในรหัส C ง่ายขึ้น แต่ไมโครคอนโทรลเลอร์ที่เรียบง่ายอาจไม่สามารถจัดการการป้องกันหน่วยความจำที่ซับซ้อนได้ เช่น MSP430 ช่วยให้คุณสามารถแยกรหัสและข้อมูลในระดับสูง แต่ไม่มีการควบคุมการเข้าถึงหน่วยความจำแบบละเอียด
ระบบปฏิบัติการเชื่อมช่องว่างระหว่างฮาร์ดแวร์และแอพพลิเคชั่นซอฟต์แวร์จริง ๆ (ผ่านไดรเวอร์อุปกรณ์) กล่าวอีกนัยหนึ่งมันเป็นแพลตฟอร์มระดับสูงสำหรับโปรแกรมเมอร์ซึ่งจะช่วยลดความซับซ้อนของรหัสในที่สุด และยิ่งไปกว่านั้นระบบปฏิบัติการยังมอบแพลตฟอร์มที่แข็งแกร่งและยืดหยุ่นสำหรับการใช้งานแอพพลิเคชั่น