第3章實時嵌入式Linux

計算機系統與環(huán)境之間的交互通常是實時發(fā)生的，因此，對于作為計算機系統一部分的嵌入式設備來說，有關實時操作系統的討論也是一個重要話題。

本章將討論實時系統的特點，介紹在Linux嵌入式設備上實現實時性的主要方法。具體來說，本章將重點分析PREEMPT_RT內核補丁，該補丁可輕松應用于主線內核。然后，將分析調度延遲的概念以及導致延遲增加的主要原因。最后，結尾部分將重點介紹如何利用特定工具和方法（如Cyclictest提供的工具和方法）以及涉及剖析工具的更復雜工具來測量和分析延遲。

3.1 Linux與實時性

Linux中的實時性是一個非常有趣的話題，每當使用Linux作為操作系統的設備需要運行具有實時性要求的應用程序時，這個話題就會出現。

正如已經強調的那樣，Linux幾乎具備了在許多系統和ICS中采用所需的所有特性。然而，正如第 2.1節(jié)末尾所述，當需要運行的應用程序需要實時行為時，Linux就會受到影響。造成這一問題的主要原因是，Linux最初是作為通用操作系統設計的。因此，Linux在設計時并沒有考慮時間的確定性，因此它并不是一個實時操作系統。

分析Linux的設計方式，它的目的是提供最高級別的整體性能。這隱含地意味著，事情不會以確定的時間方式發(fā)生，因為一切都將以提高整體性能水平的方式進行，而眾所周知，這兩件事是背道而馳的。

盡管如此，考慮到Linux提供了許多有用的功能，但當它必須用于時間關鍵型應用程序時，就會遇到這個問題。

3.1.1 什么是實時？

實時的含義是一個相當混亂的概念，人們在被問及實時系統的定義時，往往會給出許多相互矛盾的定義。因此，在繼續(xù)討論之前，有必要澄清實時系統的概念。
一些最混亂的定義涉及以下說法：

• 實時是指執(zhí)行速度快
• 實時是指性能高
• 實時是指響應速度快

這些說法都有一定的道理，但仍有不足之處。事實上，在談到實時系統時：它并不是指最快的執(zhí)行速度和最快的響應時間，也不是指最好的性能，而是指時間保證。換句話說，實時任務的定義并不是要求任務的執(zhí)行速度越快越好，而是要求任務的執(zhí)行速度在時間要求規(guī)定的范圍內。

如果一項任務必須在某個時間點（即截止日期）之前完成，那么它就可以被定義為實時任務。因此，在處理實時系統時，在指定的時間段前完成任務并不重要，重要的是保證任務的最后期限始終得到遵守。

綜上所述，在討論實時系統時，任務在特定機器上執(zhí)行的算法的正確性不僅取決于算法結果本身的正確性，還取決于算法的執(zhí)行時間。

這意味著，如果算法沒有在指定的時間段內執(zhí)行，相應的時間違規(guī)將導致獨立于算法結果的錯誤條件。
當然，并不是所有的錯誤條件都是一樣的。因此，根據錯過截止時間造成的后果，系統可分為以下幾類：

• 硬實時：錯過最后期限會導致整個系統癱瘓。
• 穩(wěn)健實時：可以容忍不頻繁的截止日期缺失，但服務質量可能會下降，因為截止日期后產生的結果完全無用。
• 軟實時：錯過截止日期后，產生的結果會降低，但仍可使用。不過，多次錯過截止日期后，系統質量可能會下降。

3.1.2 讓Linux實現實時運行

誰真正需要實時Linux？

• 工業(yè)
• 自動化
• 汽車
• 多媒體系統
• 航空航天
• 金融服務

不僅在嵌入式設備上，而且在功能更強大的計算機系統中，都需要具備實時功能。傳統上，使Linux具有實時性的方法主要有兩種：第一種是基于所謂的雙內核方法，這種方法并不是為了使實際的Linux內核具有實時性，另一種是代表新趨勢的內核方法。

雙內核（dual-kernel）方法

最著名的使Linux實時化的雙內核方法是RTAI和Xenomai：它們使用的方案如圖 3.1 所示。

在這種情況下，實際的Linux內核在微內核上運行，微內核確保實時任務的可調度性，并在每次需要時搶占整個Linux內核。

"Altenberg 說："有了雙內核，當優(yōu)先實時應用程序不在微內核上運行時，Linux 可以獲得一些運行時間。
這種方法最明顯的問題是，必須有人維護微內核，并支持將其移植到新的硬件平臺上。此外，由于 Linux 不能直接在硬件上運行，因此還需要定義和維護一個硬件抽象層。

當然，解決這些問題需要付出巨大的努力，這也是因為開發(fā)社區(qū)沒有維護通用Linux內核的社區(qū)那么大。因此，考慮到所需的精力和需要維護的各種東西，這些雙內核方法通常要比實際的Linux主線版本晚幾步。更詳細地說，RTAI是米蘭大學開發(fā)的第一個嘗試。使用它，可以在內核空間編寫實時應用程序，而實時應用程序與用戶空間之間的交互是通過非常有限和特殊的方法完成的。RTAI的目的是獲得最低的延遲，支持的操作系統包括x86、x86_64 和一些 ARM 平臺支持。

"有了RTAI，你就可以編寫一個由微內核調度的內核模塊。這就像內核開發(fā)一樣，真的很難進入，也很難調試"。此外，由于RTAI的開發(fā)是在內核空間進行的，根據內核通用公共許可證（GPL）的規(guī)定，代碼必須發(fā)布，這可能會使事情變得更加復雜，因為工業(yè)客戶往往希望使用封閉源代碼。

如今，RTAI的另一種雙內核替代方案是Xenomai，它已成為主流。它比RTAI支持更多的硬件平臺，但更重要的是，它提供了一種在用戶空間進行實時操作的解決方案。
"為此，他們提出了皮膚的概念，即不同實時操作系統（RTOS）（如Unix的可移植操作系統接口（POSIX））API 的仿真層。這樣就可以重新使用某些實時操作系統的現有代碼子集"。

不過，即使使用Xenomai，也需要維護一個單獨的微內核和一個硬件抽象層。此外，標準C庫無法使用，應用程序開發(fā)需要特殊工具?？傊p內核方法克服了Linux在管理實時應用程序方面的局限性。不過，所分析的兩種解決方案都有一些不容忽視的缺點，尤其是在處理大型復雜項目時。

in-kernel方法

由于使用雙內核方法可能會很復雜，這可能會阻礙開發(fā)人員使用Linux，因此最好的辦法就是使實際的Linux內核具有實時性，而不需要任何外部微內核的幫助，如圖 3.2 所示。

實時操作系統要想獲得確定性時序行為，首先必須提供搶占功能。具體來說，它需要在大部分時間都能搶占先機，因為優(yōu)先級較高的任務必須總是搶占其他不太重要的任務和優(yōu)先級較低的任務的先機。當然，一旦增加了搶占功能，就必須管理和解決其他眾所周知的問題，如優(yōu)先級倒置。

傳統上，使主線內核實時運行所需的所有轉換都是通過內核補丁完成的：即所謂的 PREEMPT_RT。
如今，PREEMPT_RT補丁已被廣泛使用，它是使Linux實現實時運行的主要方法。

3.1.3 PREEMPT_RT

PREEMPT_RT補丁代表了最常用的內核方法，可使Linux在實時場景中發(fā)揮作用。此外，由于PREEMPT_RT已獲官方支持，它允許使用標準POSIX，而不需要特殊的API來編寫實時應用程序。因此，PREEMPT_RT得到了很好的支持，并得到了官方社區(qū)的高度認可，其大部分功能已被納入主線內核。對此Linus Torvalds在2006 年的一次峰會上表示支持："用Linux控制激光器太瘋狂了，但在座的每個人都有自己的瘋狂之處。因此，如果你想用 Linux 來控制工業(yè)焊接激光器，我對你使用 PREEMPT_RT 沒有意見"。

在繼續(xù)分析PREEMPT_RT補丁的實際作用之前，我們不妨先看看Linux系統中造成非確定性的最常見原因。

3.1.3.1 延遲和非確定性的來源

由于系統延遲的增加，各種原因都可能導致實時應用程序錯過最后期限。一般Linux系統中最常見的非確定性原因包括:

• 調度算法

實時線程需要先于其他任務進行調度，因此需要實時調度策略。此外，該策略還必須管理根據任務截止日期分配的各種優(yōu)先級。

• 調度延遲

實時內核必須能夠在事件發(fā)生（如觸發(fā)中斷）后立即重新調度，調度越早越好。減少調度延遲是一個關鍵點，因此本節(jié)下文將對此進行詳細介紹。

• 未啟用搶占機制

在執(zhí)行關鍵部分時，搶占機制可能被禁用。當然，由于進程無法搶占先機，這個問題可能會導致意想不到的延遲。因此，在實時情況下，必須禁用搶占機制。

• 優(yōu)先級倒置

這是一個眾所周知的問題，由于優(yōu)先級較高的線程被阻塞在優(yōu)先級較低的任務所持有的互斥任務上，可能會導致無限制的延遲。應對這一問題的最常用解決方案之一是實施優(yōu)先級繼承機制。這在時間上提高了持有互斥任務的低優(yōu)先級線程的優(yōu)先級，以免高優(yōu)先級任務被鎖定太長時間。

• 精確定時器

當需要滿足的最后期限非常小（幾毫秒或幾微秒）時，高分辨率定時器對小時間量的敏感性至關重要。

• Page故障

在執(zhí)行實時任務時，頁面故障可能會導致意想不到的延遲，因此需要一些可以鎖定內存的機制。

• 中斷

由于中斷會以不可預測的時間率發(fā)生，實時進程的延遲可能會顯著增加，尤其是當多個中斷接連發(fā)生時。為了解決這個問題，一種解決方案是將中斷作為內核線程運行，或者在多核CPU中，將中斷處理工作交由一個內核專門負責。

• 處理器緩存

緩存在CPU和主內存之間提供了高速緩沖區(qū)，但由于其本身的性質，緩存是非確定性的來源，特別是在多核設備上。

• 內存總線爭用

通常，當內存?zhèn)鬏斨苯油ㄟ^DMA外設進行時，用于移動數據的通道與CPU共享，這取決于可用帶寬，可能會減慢實時任務的執(zhí)行速度。因此，當使用DMA通道時，延遲可能會增加。

• 電源管理

實時策略和電源管理策略完全背道而馳。事實上，由于從一種睡眠狀態(tài)切換到另一種睡眠狀態(tài)不可避免地需要時間，電源管理往往會導致更高的延遲。導致無法瞬時轉換的原因有很多：從時鐘頻率發(fā)生器需要時間來穩(wěn)定，到穩(wěn)壓器設備需要時間來提供穩(wěn)定的輸出。因此，可以肯定的是，從低功耗狀態(tài)退出的設備不會立即對中斷或其他刺激做出響應，延遲也會因此而增加。

3.1.3.2 調度延遲

正如預期，調度延遲是實時系統的一個關鍵點。事實上，為了使實時任務不會錯過最后期限，它們需要在有事情要做時立即進行調度。

然而，在實際系統中，即使CPU處于空閑狀態(tài)，也沒有其他具有相同或更高優(yōu)先級的線程在運行，在喚醒事件發(fā)生的瞬間與相應線程開始執(zhí)行的時間之間，總會存在一定的延遲。如圖3.3所示，這種延遲被稱為調度延遲。

第一個延遲是硬件中斷延遲：從中斷發(fā)生到啟動相應的中斷服務例程（ISR）。而這一延遲又由兩部分組成：第一部分（通常較?。┦怯芍袛嘤布旧碓斐傻模溆嗖糠謩t是通過軟件禁用中斷造成的。因此，盡量縮短中斷被禁用的時間非常重要。

下一個延遲是處理程序延遲：它由ISR執(zhí)行所需的時間決定，這個延遲主要取決于例程的編寫方式，希望它只需要微秒量級的短時間。

一旦ISR執(zhí)行完畢，就會出現調度延遲：從通知內核運行調度程序的時間點到實際執(zhí)行的時間點。最后的延遲由調度器持續(xù)時間給出：這是調度器算法決定何時開始運行實時線程所需的執(zhí)行時間。

當然，調度器延遲及其持續(xù)時間取決于內核是否可以搶占先機，事實上，如果內核正在關鍵部分運行某些代碼，重新調度就會延遲，從而導致總延遲增加。
既然我們已經分析了非確定性的主要原因，也了解了調度延遲的含義，那么就可以回答"PREEMPT_RT到底是做什么的 "這個問題了。

基本上，PREEMPT_RT補丁的主要作用是使Linux內核完全搶占式，同時解決非確定性的主要原因，以減少延遲。

更詳細地說，這些目標是通過以下方式實現的：

• 使用自旋鎖（spinlock）將內核鎖定原語轉換為可搶占式鎖定原語，并使用實時互斥器（real-time mutexes）重新實現這些原語。
• 使用新的可搶占式鎖定原語重新實現大多數關鍵部分 - 使用優(yōu)先權繼承機制解決內核內 spinlocks 和 semaphores 的優(yōu)先權反轉問題。
• 使用可搶占的內核線程管理中斷處理程序，即 PREEMPT_RT 補丁將軟中斷處理程序作為內核線程來管理。
• 改進舊的 Linux 定時器 API，以便在用戶空間上下文中也能管理高分辨率的內核定時器。

事實上，標準的Linux內核已經包含了高分辨率定時器、內核互斥和線程中斷處理程序。
然而，所有旨在減少內核在原子上下文中運行時間的內核核心修改，即增加內核可搶占時間的修改，都被保留在主線之外，因為它們具有相當的侵入性。
事實上，將這些修改納入主線后，只有一小部分Linux用戶能從中受益，因為平均延遲時間會更長，但確定性更高，這正是 PREEMPT_RT 的作用所在。

另一個問題與如何將PREEMPT_RT 修改應用到標準內核有關。
顧名思義，PREEMPT_RT補丁是必須應用于源代碼的內核補丁，因此，要啟用完整的實時功能，需要內核源代碼和PREEMPT_RT補丁。
除內核源代碼補丁外，還必須通過PREEMPT_RT_FULL內核配置選項啟用完全搶占式內核，如圖3.4所示，具體說明見第4.2.2節(jié)。

3.2 實時基準測試

一旦打上補丁并編譯了實時內核，最常見的問題就是要確定特定硬件及其配置是否能讓應用程序在不錯過截止日期的情況下運行。要解決這類問題，最好能有一個數學證明，說明應用程序絕不會錯過最后期限。

遺憾的是，Linux系統非常復雜，基本上不可能用數學方法證明一項任務在運行時不會錯過最后期限。因此，要確定在特定硬件上運行的應用程序是否會錯過最后期限，唯一的辦法就是進行實際的設備測量。
更詳細地說，可以確定并遵循不同的途徑來執(zhí)行這些測量：也許，最直接的選擇是運行實際的實時應用程序，以了解其是否滿足截止日期要求。但遺憾的是，由于種種原因，運行實際應用程序并不總是可能的，因此需要采用其他方法。

具體來說，為了了解設備是否足夠實時，可以測量和分析系統的調度延遲。
事實上，如圖3.5所示，調度延遲越小，即系統響應事件發(fā)生所需的時間越短，執(zhí)行實時計算的剩余時間就越長。

總之，測量調度延遲有助于了解設備的實時性。

3.2.1 RT-tests

rt-tests是一個測試套件，其中包含測試各種實時Linux功能和調度延遲的工具：rt-tests 的主要工具包括

• cyclictest
• hackbench
• pip_stress
• pi_stress
• pmqtest
• ptsematest
• sigwaittest

3.2.1.1 Cyclictest

Cyclictest是一種廣泛使用的驗證最大調度延遲的工具：它運行一個非實時的主線程，該主線程依次啟動一定數量的"測量"線程，這些線程具有定義的實時優(yōu)先級（使用SCHED_FIFO調度），然后"測量"線程在定時器到期后以定義的時間間隔定期被喚醒，每次喚醒都會計算編程時間和有效喚醒時間之間的差值，并將其提供給主線程。

最后，主線程會跟蹤延遲值，并打印出最小值、平均值和最大值以及其他有用信息。
為了更好地理解Cyclictest的工作原理，可以對其源代碼進行分析，為此，在3.1和3.2中報告了其源代碼的簡化版本。

void *timethread(void *par){

	// Thread set up
	clock_gettime(&now);
	next = now + interval;
	while (!shutdown){
		clock_nanosleep(&next); // Sleep
		clock_gettime(&now); // Get current time
		diff = now - next; // Compute the difference
		update_stat(diff); // Update statistics
		next += interval; // Compute the new wake-up time
	}
}

int main (){
	for(i=0; i<num_threads; i++){
		pthread_create(timethread); // Creates threads
	}
	while(!shutdown){
		for(i=0; i<num_threads; i++){
			print_stat(stat[i], i); // Prints statistics
		}
		usleep(10000);
	}
	if(histogram){
	print_hist(parameters , num_threads);
	}
}

在處理 Cyclictest 時，需要牢記的一些最重要的因素如下：

• 主線程以較低的優(yōu)先級運行，因此與普通線程無異。
• 測量線程以較高的優(yōu)先級運行，即用戶指定的優(yōu)先級。
• Cyclictest不能提供確定性結果。
• 運行 Cyclictest 只會給出延遲的下限，事實上，除非CPU處于負載狀態(tài)，否則它不會給出最壞的情況。
• 在CPU空閑時運行Cyclictest幾乎毫無用處。
• 必須根據要測試的系統調整Cyclictest設置。
• 如果不考慮系統屬性，可能會出現某些延遲原因未涵蓋在內的情況。例如：由于Cyclictest以固定頻率喚醒線程，因此可能存在在Cyclictest線程運行前就已管理好的延遲源，在這種情況下，以不同周期運行Cyclictest可能會有所幫助。
• Cyclictest并不測量實時應用程序的中斷請求（IRQ）處理路徑，事實上，定時器的IRQ通常在IRQ上下文中得到完全處理，在更現實的情況下，處理程序會喚醒相應的線程，進而喚醒實時進程。

總之，在需要牢記的各種因素中，正如已經強調過的，Cyclictest必須在特定負載條件下運行，以確定系統最壞情況下的延遲。因此，正確使用Cyclictest的可能解決方案有

• 不要使用Cyclictest將延遲測量嵌入到實時應用程序中

實際上，這并不是一個真正的解決方案，但是，將測量嵌入到實時應用程序中，讓應用程序直接測量延遲的方式是最好的方法，盡管這并不總是可行的。

• 在Cyclictest運行時，運行正常的實時應用程序和非實時應用程序作為系統負載來測量延遲。

所有建議的解決方案都需要有系統實時應用程序。不過，在某些情況下，無法使用真實應用程序，必須尋找其他替代方案。

當需要分析系統的性能，而系統的實際最終應用又不可用時，就需要其他基準測試方法。在這種情況下，合成基準就能派上用場：合成基準是為了獲得可準確比較的結果而設計的易于重復的測試場景。

合成基準通過孤立的調查，還可以檢查系統內最小的瓶頸，即它們是基于測試單個部件的想法，而不會受到影響結果的其他因素的交互作用。因此，系統的每個組件都要單獨測試，例如：先測試處理器，然后測試網絡接口、磁盤等。

在沒有實際應用程序的情況下，這些基準確實非常有用，但必須仔細定義，如第 4.2 節(jié)所述。

3.2.1.2 Hackbench

Hackbench既是基準也是Linux內核調度程序的壓力測試，其主要任務是創(chuàng)建指定數量的線程或進程，并通過套接字或管道進行通信。此外，它還作為基準工具測量通信所需的時間。如前所述，空閑的內核會顯示較低的調度延遲，因此 Hackbench 可用作壓力程序，以獲得繁忙的內核，從而得到更真實的延遲結果。

Pip_stress使用三個進程創(chuàng)建優(yōu)先級反轉。具體來說，優(yōu)先級最低的進程持有一個互斥進程，它被中等優(yōu)先級的進程搶占，后者只是運行一個無限循環(huán)。然后，第三個進程，也就是優(yōu)先級最高的進程，試圖鎖定優(yōu)先級最低的任務已經持有的互斥任務。由于使用的是優(yōu)先級繼承互斥，因此允許優(yōu)先級最低的進程以較高的優(yōu)先級運行，這樣它就可以搶占優(yōu)先級中等的第二個進程。Pip_stress測試程序不將任何選項作為輸入，如果優(yōu)先級反轉問題得到解決，它應立即退出。因此，Pip_stress主要用于測試優(yōu)先級繼承機制是否正常工作。

Pi_stress用于測試優(yōu)先級繼承機制的程序。它運行多組線程。具體來說，每組線程都會導致優(yōu)先級倒置，如果優(yōu)先級繼承機制失效，就會出現死鎖。

Pmqtest啟動成對的線程，測量與POSIX消息隊列進行進程間通信的延遲。更詳細地說，它測量發(fā)送和接收消息之間的延遲。

Ptsematest啟動兩個線程，使用POSIX mutex測量進程間通信的延遲。具體來說，它測量的是釋放和獲取互斥之間的延遲。

Sigwaittest啟動兩個通過信號同步的線程，并測量發(fā)送信號和從sigwait()返回信號之間的延遲。也可以選擇啟動兩個進程而不是線程。

3.3 剖析工具

當想了解程序如何運行時，可以使用源代碼級調試器，如第2.2.1.2節(jié)所述的調試器。調試器允許深入了解系統正在做什么。不過，調試器只能查看一小部分代碼，也就是說，調試操作僅限于特定的應用程序。

大多數情況下，經典調試方法并沒有問題，但有時需要一種方法來獲得系統的高層概覽，以了解哪些進程正在運行、CPU 和內存資源的使用情況等。

因此，除了傳統的調試技術外，還需要一些替代工具，以便獲得更全面的信息，說明系統是否按預期運行。

這些復雜的替代工具就是所謂的剖析和跟蹤工具：它們旨在找出瓶頸所在，以便在分析整個系統的同時解決性能問題。因此，當系統出現一些性能問題時，使用這類工具來分析問題所在是明智之舉。

在Linux環(huán)境中，最著名的剖析工具可能就是所謂的top，它可以顯示當前由內核管理的任務列表和其他系統概要信息。

除了top之外，還有其他工具，例如，剖析工具Perf提供了更強大的分析和剖析應用程序的手段。另外，如果問題和瓶頸是由Linux內核造成的，ftrace和LTTng等跟蹤工具也能提供收集所有所需信息的手段。

總之，剖析工具對于動態(tài)分析和測量系統狀態(tài)及其資源使用情況非常有用。此外，使用剖析工具還可以了解程序的復雜性、特定指令的使用次數、系統調用的頻率和持續(xù)時間、正確預測的分支數量等。因此，剖析工具通常用于優(yōu)化程序的執(zhí)行，并找出系統在性能方面的問題所在。

參考資料

• 軟件測試精品書籍文檔下載持續(xù)更新 https://github.com/china-testing/python-testing-examples 請點贊，謝謝！
• 本文涉及的python測試開發(fā)庫 謝謝點贊！ https://github.com/china-testing/python_cn_resouce
• python精品書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
• Linux精品書籍下載 https://www.cnblogs.com/testing-/p/17438558.html

3.3.1 ARM DS-5 Streamline

ARM DS-5 Streamline是ARM公司推出的各種剖析工具之一，正如ARM公司所稱，"DS-5 Streamline 為您提供了更多的選擇： "DS-5 Streamline 可以讓您比以往任何時候都更深入地了解軟件的執(zhí)行情況。

Streamline是一種性能分析器，針對ARM設備進行了優(yōu)化，是開發(fā)在ARM SoC上運行的優(yōu)化應用程序的理想工具。例如，通過其時間線視圖，可以輕松讀取顯示性能計數器值和執(zhí)行進程詳情的圖表，如圖 3.6 所示。

Streamline 允許為每個進程和線程選擇獨立顯示的信息，以便分析對特定用例有用的信息。DS-5 Streamline 套件可通過以太網連接輕松使用，由三個主要軟件組件組成： 它由三個主要軟件組件組成：在開發(fā)主機上運行的 Streamline、持續(xù)收集所需信息的 Gator 內核模塊和管理主機與目標之間連接的 Gator 守護進程。圖 3.7 概述了 Streamline 的工作原理及其組成部分。

3.3.1.1 性能監(jiān)測單元（PMU Performance Monitoring Unit）

如前所述，使用 Streamline 可以分析系統上運行的各種進程，獲取詳細信息，如：未命中預測分支的數量或緩存未命中的數量。
Streamline 通過使用集成在 SoC 中的性能監(jiān)控單元（PMU）來獲取所有需要的信息。事實上，PMU 可通過監(jiān)控 SoC 資源幫助收集有用的性能信息。

文章來源地址http://www.zghlxwxcb.cn/news/detail-615414.html

到了這里，關于實時嵌入式Linux設備基準測試快速入門3實時嵌入式Linux的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！