a级毛片免费全部播放-a级毛片免费观看在线播放-a级毛片免费观看网站-a级毛片免费看-国产成人精品在视频-国产成人精品在线

2022-02-08點擊量：4932

錯誤1：競爭條件競爭條件是指兩個或多個執行線程（可以是RTOS任務或main（）和中斷處理程序）的組合結果根據交織指令的精確順序而變化的任何情況。每個都在處理器上執行。例如，假設您有兩個執行線程，其中一個規則地遞增一個全局變量（g_counter+=1;），而另一個偶然將其歸零（g_counter=0;）。如果不能始終以原子方式（即，在單個指令周期內）執行增量，則存在競爭條件。最佳實踐：可以通過必須以適當的搶先限制行為對原子地執行代碼的關鍵部分，來避免競爭條件。為防止涉及ISR的爭用情況，必須在另一個代碼的關鍵部分持續時間內至少禁止一個中斷信號。對于RTOS任務之間的爭用，最佳實踐是創建特定于該共享庫的互斥體，每個互斥體在進入關鍵部分之前必須獲取該互斥體。請注意，依靠特定CPU的功能來確保原子性不是一個好主意，因為這只能防止爭用情況發生，直到更換編譯器或CPU。共享數據和搶占的隨機時間是造成競爭狀況的元兇。但是錯誤可能并不總是會發生，這使得從觀察到的癥狀到根本原因的種族狀況跟蹤變得異常困難。因此，保持警惕以保護所有共享對象非常重要。每個共享對象都是一個等待發生的事故。最佳實踐：命名所有潛在共享的對象（包括全局變量，堆對象或外圍寄存器和指向該對象的指針），以使風險對于所有將來的代碼閱讀者而言都是顯而易見的；在Netrino嵌入式C編碼標準提倡使用“的G_為此，”前綴。查找所有可能共享的對象將是爭用條件代碼審核的第一步。錯誤2：不可重入功能從技術上講，不可重入功能的問題是爭用狀況問題的特例。而且，由于相關原因，由不可重入函數引起的運行時錯誤通常不會以可重現的方式發生-使它們同樣難以調試。不幸的是，非重入功能也比其他類型的競爭條件更難在代碼審查中發現。為了可以同時從多個RTOS任務中調用此以太網驅動程序的功能，必須使它們可重入。如果它們每個僅使用堆棧變量，則無事可做。因此，C函數最常見的樣式固有地是可重入的。但是，除非精心設計，否則驅動程序和某些其他功能將是不可重入的。使函數可重入的關鍵是暫停對外圍設備寄存器，包括靜態局部變量，持久堆對象和共享內存區域在內的全局變量的所有訪問的搶占。這可以通過禁用一個或多個中斷或獲取并釋放互斥鎖來完成。問題的細節決定了最佳解決方案。最佳實踐：在每個庫或驅動程序模塊中創建和隱藏一個互斥量，這些互斥量不是本質上可重入的。使獲取此互斥鎖成為操作整個模塊中使用的任何持久數據或共享寄存器的前提。例如，相同的互斥鎖可用于防止涉及以太網控制器寄存器和全局或靜態本地數據包計數器的競爭情況。在訪問這些數據之前，模塊中訪問此數據的所有功能必須遵循協議以獲取互斥量。注意非重入功能可能會作為第三方中間件，舊版代碼或設備驅動程序的一部分進入您的代碼庫。令人不安的是，不可重入函數甚至可能是編譯器隨附的標準C或C++庫的一部分。如果您使用GNU編譯器來構建基于RTOS的應用程序，請注意您應該使用可重入的“newlib”標準C庫，而不是默認庫。錯誤3：缺少volatile關鍵字如果未使用C的volatile關鍵字標記某些類型的變量，則可能導致僅在將編譯器的優化器設置為低級或禁用編譯器才能正常工作的系統中出現許多意外行為。該揮發性預選賽期間變量聲明，其中它的目的是為了防止優化的讀取和變量的寫入使用。最佳實踐：將揮發的關鍵字應該用于聲明每個：由ISR和代碼的任何其他部分訪問的全局變量，由兩個或多個RTOS任務訪問的全局變量（即使已阻止了這些訪問中的競爭條件），指向內存映射外設寄存器（或一組或一組寄存器）的指針，以及延遲循環計數器。請注意，除了確保所有讀寫操作都針對給定變量之外，使用volatile還通過添加其他“序列點”來限制編譯器。除易失性變量的讀取或寫入之外的其他易失性訪問必須在該訪問之前執行。錯誤4：堆棧溢出每個程序員都知道堆棧溢出是很不好的事情。但是，每次堆棧溢出的影響都各不相同。損壞的性質和不當行為的時機完全取決于破壞哪些數據或指令以及如何使用它們。重要的是，從堆棧溢出到它對系統的負面影響之間的時間長短取決于使用阻塞位之前的時間。不幸的是，堆棧溢出比臺式計算機更容易遭受嵌入式系統的困擾。這有幾個原因，其中包括：（1）嵌入式系統通常只能占用較少的RAM；（2）通常沒有虛擬內存可回退（因為沒有磁盤）；（3）基于RTOS任務的固件設計利用了多個堆棧（每個任務一個），每個堆棧的大小都必須足夠大，以確保不會出現唯一的最壞情況的堆棧深度；（4）中斷處理程序可能會嘗試使用這些相同的堆棧。使該問題進一步復雜化的是，沒有大量的測試可以確保特定的堆棧足夠大。您可以在各種加載條件下測試系統，但是只能測試很長時間。僅在“半個藍月亮”中運行的測試可能不會見證僅在“一次藍月亮”中發生的堆棧溢出。在算法限制（例如無遞歸）下，可以通過對代碼的控制流進行自上而下的分析來證明不會發生堆棧溢出。但是，每次更改代碼時，都需要重做自上而下的分析。最佳實踐：啟動時，在整個堆棧上繪制不太可能的內存模式。（我喜歡使用十六進制233D3D23，它看起來像ASCII內存轉儲中的籬笆'＃==＃'。）在運行時，讓管理員任務定期檢查是否沒有任何涂料在預先設定的高水位上方標記已更改。如果發現某個堆棧有問題，請在非易失性內存中記錄特定的錯誤（例如哪個堆棧以及洪水的高度），并為產品的用戶做一些安全的事情（例如，受控關閉或重置）可能會發生真正的溢出。這是添加到看門狗任務中的一項不錯的附加安全功能。錯誤5：堆碎片化嵌入式開發工程師并沒有很好地利用動態內存分配。其中之一是堆碎片的問題。通過C的malloc（）標準庫例程或C++的new關鍵字創建的所有數據結構都駐留在堆中。堆是RAM中具有預定最大大小的特定區域。最初，堆中的每個分配都會減少相同字節數的剩余“可用”空間。例如，特定系統中的堆可能從地址0x20200000開始跨越10KB。一對4KB數據結構的分配將留下2KB的可用空間。可以通過調用free（）或使用delete關鍵字將不再需要的數據結構的存儲返回到堆中。從理論上講，這使該存儲空間可用于后續分配期間的重用。但是分配和刪除的順序通常至少是偽隨機的，這導致堆變成一堆更小的碎片。若要查看碎片可能是一個問題，請考慮如果上述4KB數據結構中的第一個空閑時會發生什么情況。現在，堆由一個4KB的空閑塊和另一個2KB的空閑塊組成。它們不相鄰，無法合并。所以我們的堆已經被分割了。盡管總可用空間為6KB，但超過4KB的分配將失敗。碎片類似于熵：兩者都隨時間增加。在長時間運行的系統（換句話說，曾經創建的大多數嵌入式系統）中，碎片最終可能會導致某些分配請求失敗。然后呢？您的固件應如何處理堆分配請求失敗的情況？最佳實踐：避免完全使用堆是防止此錯誤的肯定方法。但是，如果動態內存分配在您的系統中是必需的或方便的，則可以使用另一種結構化堆的方法來防止碎片。許多實時操作系統都具有固定大小的內存池API。如果您可以訪問其中之一，請使用它代替malloc（）和free（）。或編寫自己的固定大小的內存池API。您只需要三個函數：一個用于創建新的池（大小為M塊N字節）；另一個分配一個塊（來自指定的池）；三分之一代替free（）。代碼審查仍然是最佳實踐，可以通過首先確保系統中不存在這些錯誤來避免許多調試麻煩。最好的方法是讓公司內部或外部的人員進行全面的代碼審查。強制使用我在這里描述的最佳實踐的標準規則編碼也應該會有所幫助。如果您懷疑現有代碼中存在這些討厭的錯誤之一，那么執行代碼審查可能比嘗試從觀察到的故障追溯到根本原因要快。...

2022-02-02點擊量：4964

預期行為和實際行為可能以多種方式不同，這些方式在源代碼中并不明顯，并且難以通過功能測試來檢測。當應用程序變得越來越復雜時，這對于運行RTOS或Linux內核的多線程嵌入式軟件的嵌入式開發人員來說是一個越來越大的挑戰。遵循這五個最佳實踐，以獲得系統級別的實時行為所需的可見性，以提高產品質量并加快開發速度。1.通過可視化時間線減少猜測。運行完整的多線程系統時檢測到的問題通常難以解決。幸運的是，調試過程中更好的洞察力可以減少猜測。這樣可以更容易地找到根本原因，從而正確修復錯誤并減少調試時間。看到軟件執行的可視化時間線的能力在許多情況下都很重要，例如當錯誤的位置從最初的癥狀中不明顯時，當問題難以重現時，以及當傳統的調試工具(停止執行)時不能使用。printf調試呢?在應用程序代碼中添加調試打印的舊做法是有風險的、侵入性的，并且無法擴展到更復雜的應用程序和更快的處理器。printf函數不是為此目的而設計的，而且通常很慢——每條消息需要幾毫秒。相比之下，視覺跟蹤診斷依賴于軟件跟蹤的優化解決方案，并且比printf調用快約100倍，因此你可以收集更多信息而不會產生明顯影響。此外，數據可視化技術可以輕松地將軟件跟蹤轉化為可操作的見解。2.監控系統測試以發現難以捉摸的問題。跟蹤數據的持續實時流式傳輸使嵌入式開發人員能夠長時間記錄和可視化軟件的完整圖片，以捕捉難以重現和調試的難以捉摸的軟件問題。捕獲跟蹤記錄中的任何“故障”并了解導致它們的原因。或者在經過數小時的壓力測試后找出系統崩潰的原因。Percepio廬Tracealyzer廬的可視化跟蹤診斷使你能夠查看運行時系統的實時動畫視圖，在高級可視化概覽和統計中發現異常，并深入了解特定事件以準確了解發生了什么。3.改進軟件設計以獲得更好的產品和更低的成本。一些開發項目會遇到“調試地獄”，這是一種常見的場景，大量的調試會阻礙項目。軟件設計和RTOS應用程序開發中與最佳實踐的偏差通常是主要的促成因素。一些示例包括不合適的任務優先級、軟件時序的巨大變化以及任務之間的過多依賴關系。此類問題可能會導致復雜和混亂的系統行為，可測試性差，這增加了難以捉摸的錯誤泄漏到生產設備中的風險。可視化跟蹤診斷幫助開發人員分析和改進軟件設計，確保系統行為穩定可靠。當你可以更早地發現軟件設計缺陷時，修復它們所需的更改更少，并且已交付產品中出現錯誤的風險也會降低。軟件設計改進還可以顯著提高系統性能和響應能力。這可以允許嵌入式開發人員選擇更具成本效益的處理器來降低BoM成本，或者使用較低的時鐘頻率來延長電池壽命。4.驗證整個項目的時間安排和產品性能。盡早測量時間和性能指標，以便你可以在交付前解決任何問題。這對于具有明確時序要求的實時系統至關重要，對于其他應用程序的用戶體驗也很重要。沒有人喜歡緩慢的觸摸屏界面或緩慢的Wi-Fi路由器，但通常原因在源代碼中并不明顯，如果問題根源在于軟件設計，更快的處理器可能無濟于事。可視化跟蹤診斷可以輕松顯示異常原因并測量軟件時序屬性、內存使用情況和CPU負載。更容易滿足實時要求以及更好的應用程序性能和客戶滿意度是眾多好處中的一部分。5.使診斷變得容易獲得并每天受益。無需額外硬件，僅使用軟件集成和應用程序的現有硬件即可提供可視跟蹤診斷。這樣，你可以默認將其包含在軟件系統中，以便開發人員在整個開發、測試和發布過程中都可以訪問。當你在遇到問題時隨時提供診斷，所有嵌入式開發人員每天都可以從中受益。記錄與你的應用程序相關的任何信息，包括運行時未公開的內部數據和狀態。與可視化執行時間表并行查看所需的任何數據圖，并制作出擊敗競爭對手的出色產品。...

2022-02-02點擊量：4876

你怎么知道你的軟件正在按照它應該的方式工作?你測試一下！然而，真正的問題是“你如何測試它?”。在過去，嵌入式開發人員過去只是手動測試他們的軟件。然而，手動測試并不是測試軟件的好方法。大量的測試用例、測試所需的時間和勞動強度幾乎保證了軟件不會得到充分的測試。改進嵌入式軟件測試的解決方案是使用自動化測試。自動化測試可以有多種形式，但現在，我們將專注于單元測試。單元測試是“一種軟件測試方法，通過該方法對各個源代碼單元(一個或多個程序模塊的集合以及相關的控制數據、使用程序和操作程序)進行測試，以確定它們是否適合使用”。今天的文章將探討開發和運行嵌入式軟件單元測試的三個技巧。技巧1–將您的軟件組織成組件進行測試通常，嵌入式軟件程序將由幾十個模塊組成，這些模塊被放入一個程序文件夾中。今天，更常見的是看到一些文件夾組織，其中模塊按應用程序、中間件和驅動程序組織。像這樣的程序組織結構是可以的，但在考慮單元測試時，按組件管理程序會容易得多。組件是封裝了一組相關功能、數據和測試用例的模塊。例如，為FIR濾波器編寫應用程序組件的開發人員可能會按如下方式組織它：FIRFilter–include—fir.h–source—fir.c–tests—fir_test.c構建這樣的文件夾結構起初可能看起來有點痛苦。但是，它保留了組件執行其目的所需的所有軟件模塊和測試用例!此外，像這樣組織組件使組件易于移植，或者更重要的是，更易于在其他軟件項目中重用。技巧2–使用測試驅動開發(TDD)開發軟件敏捷運動為嵌入式開發人員提供了許多流程和工具，旨在幫助他們更快地開發出高質量的軟件。敏捷產生的一種方法是測試驅動開發，通常稱為TDD。TDD“是一個軟件開發過程，依賴于在軟件完全開發之前將軟件需求轉換為測試用例，并通過針對所有測試用例重復測試軟件來跟蹤所有軟件開發”。一般來說，TDD通過專注于測試改變了開發人員編寫軟件的方式案例。開發人員創建一個測試用例，使其失敗，然后編寫通過測試用例所需的代碼。通過這樣做，他們正在構建測試用例，他們知道如果將錯誤引入軟件中就會發現問題。技巧3–利用Docker和單元測試工具嵌入式開發人員可用于開發單元測試的工具在過去幾年中發生了很大變化。當我第一次開始使用自動化測試時，我發現設置工具是一個巨大的挑戰，今天不再是這種情況。團隊可以通過多種方式設置單元測試。首先，他們可以將測試設置為持續集成和持續部署(CI/CD)系統的一部分。CI/CD允許團隊在構建和部署過程中自動運行測試用例。接下來，開發人員可以選擇一個測試工具并將其安裝在他們的系統上。在這種情況下，測試工具在獨立環境中運行。最后，開發人員可以構建他們的測試工具和開發流程，并在Docker環境中進行設置。Docker允許開發人員在可移植的映像中運行他們的開發環境，從而最大限度地減少設置時間并提高開發人員之間的一致性。可以在Docker中設置測試工具，然后輕松部署到多個開發人員，以便他們只需使用幾條命令即可設置環境。一開始，為嵌入式軟件創建和使用自動化測試似乎令人生畏。然而，鑒于當今系統變得如此復雜，手動進行測試幾乎是不可能的。唯一真正的解決方案是開發可用于執行所有系統功能的自動化測試。單元測試是嵌入式開發人員最常用的工具，可以顯著提高系統質量，同時減少開發軟件的總時間。...

2022-01-28點擊量：4597

技術#1–嵌入式DevOps在過去十年左右的時間里，軟件DevOps對一般軟件開發進行了顯著改進，但嵌入式開發人員通常忽略了它。部分是因為大多數電氣工程師和嵌入式軟件開發人員在學校或職業生涯早期都沒有接觸過它。因此，雖然他們可能知道它的存在，但對項目的持續努力阻止了他們成功構建DevOps流程。對于希望恢復他們開發軟件的方式的開發人員，這里有幾條建議。首先，學習如何使用Docker設置嵌入式工具鏈。接下來，使用CI/CD服務器自動化構建過程。最后，如果時間允許，通過添加代碼分析、單元測試、集成測試等來繼續改進您的CI/CD流程。每天和每周都采取一些小步驟，到今年年底，您將開始擁有一個出色的DevOps流程。技術#2–自動化硬件在環測試除了調試之外，嵌入式開發人員和團隊遇到的頭號問題是測試。測試總是一個問題有幾個原因，例如：測試通常仍保留為手動過程對硬件進行自動化測試似乎既復雜又耗時團隊急于編碼，而測試是事后的想法軟件界面設計不當硬件在環測試并不是什么新鮮事物，但卻是一種經常被忽視的能力。因此，測試可能會被忽略，因為您需要考慮您的DevOps才能正確執行測試。技術#3–多核微控制器開發多核微控制器的使用將在未來幾年猛增，我認為它們在嵌入式開發中變得無處不在有幾個原因，例如：許多應用程序需要隔離運行時環境低功耗應用可以從打開和關閉功能目標內核中受益將應用程序分成運行時域在架構上是有意義的多核微控制器的成本正在急劇下降（撇開一些供應鏈問題不談）。技術#4–ArmTrustZone安全是重要驅動因素，或者應該是我們設計和制造的產品的主要驅動因素。因此，我們需要在2022年及以后掌握安全技術，以保護我們的知識產權（固件）和客戶的數據和隱私。有多種安全解決方案可用于微控制器，包括使用多核處理器來創建隔離的運行時環境。盡管如此，我認為將TrustZone單獨作為一種學習技術是有道理的，這有幾個原因，例如：新的Arm微控制器架構具有TrustZone選項TrustZone工具正在進入大多數商業甚至開源工具TrustZone提供更接近許多開發人員熟悉的軟件模型的單核解決方案技術#5–學習C++多年來，C++在嵌入式應用程序中慢慢變得越來越流行。該標準不斷更新，并為嵌入式開發人員提供了現代面向對象的工具來設計和構建他們的系統。在過去的兩年里，很多公司編寫的C++項目比C還多！...

2022-01-27點擊量：4673

很多人在學習嵌入式教程的時候都想要速成FPGA，然后選擇看視頻，一個小時就可以讓板子運行起來了，見效非常快。但這樣的話應用還行，遇到大項目理論知識全無，直接芭比Q了。所以說，學習FPGA要理論實踐兩手抓，不能一味求快，更建議穩扎穩打。學習FPGA的重點是要多看代碼，多建模型。多看代碼是為了學習別人的優秀代碼，讓自己也養成良好的代碼意識。而多建模型是為了讓自己腦海里可以快速形成邏輯模型，理解FPGA內部邏輯結構實現的基礎，才能明白為什么寫Verilog和寫C整體思路是不一樣的，才能理解順序執行語言和并行執行語言的設計方法上的差異。學習FPGA除了邏輯思維還需要數學思維，或許有朋友說自己數學不好，那可怎么辦。那就要多下點苦工了，因為沒有數學思維的話，你會發現你的設計會非常復雜，看別人的設計也不一定看得懂。FPGA的設計內容我們可以看到是以時序電路為主的，所以大家都希望組合邏輯電路為主，但是奈何它不爭氣，而時序電路在一拍怕下轉變出發的，一旦控制出錯，那么電路功能非常容易出錯，變得混亂。看萬本書不如行萬里路，實踐出真理，只是學習嵌入式教程唯一真理，而不是為了看書而看書，一切都是為了實際運用服務的，這也是最好的進步方式。...

2022-01-27點擊量：4472

很容易假設一個系統在現場表現得和在工程臺上一樣完美。在開發過程中，嵌入式軟件是在最好的條件下編寫的。嵌入式開發人員知道，或者至少有他們自己的系統應該如何工作的概念。事情通常運行得相當順利，但隨著成千上萬的設備開始進入用戶手中，意外發生和錯誤發生的可能性在統計上變得很可能。在今天的文章中，讓我們探討開發人員編寫可以處理意外錯誤的軟件所需的策略。策略#1–不斷考慮可能出現的問題開發人員需要部署以處理錯誤的第一個策略是在編寫每一行代碼時積極質疑可能出現的問題。例如，當我為如下函數編寫實現時：voidDio_WriteChannel(DioChannel_tChannel,boolstate){//Additionalcodegoeshere}我問自己幾個問題：如果Channel參數超出范圍會發生什么？該函數應該返回錯誤代碼還是成功標志？如何驗證所需的通道狀態是否已更改？如果狀態試圖改變但不能改變，我該怎么辦？內存是否會損壞，以至于我的bool狀態變量不是真假?如果是這樣，我該如何處理？斷言是否足以在開發時檢查邊界條件，還是應該對參數進行實時檢查？這是很多問題，或者諸如簡單通用代碼塊之類的問題，我們真的還沒有開始填寫細節!但是，如果你希望能夠處理錯誤，則必須不斷地質疑代碼以及可能出現的問題。策略#2–使用TODO記錄疑慮和問題隨著軟件的開發，有時問題多于目前的答案。在上面的示例中，可能還沒有關于如何處理返回錯誤的答案。暫時就這樣真的很容易，但是隨著其他問題會出現，這個問題就會被遺忘在喧囂中。大多數現代IDE都會有自定義標簽，可以從代碼中提取這些標簽來創建一個列表，例如使用TODO。這些將顯示為信息性消息。如果有需要處理的錯誤，但我不知道如何處理，我會使用TODO。如果有一個實現，但我想查看它，我可能會使用TODO，但也可能使用其他一些我可以輕松搜索代碼的關鍵字。需要注意不要讓TODO信息消息過載，否則它會變得太嘈雜，但我們也希望確保我們不會丟失我們的問題或問題。是的，可以使用外部跟蹤器，但我發現將其與代碼一起保存要容易得多，因此代碼審查員和其他嵌入式開發人員可以輕松地看到它。策略#3–總是抱著“以后會改的態度”現在是修復、記錄或實施錯誤檢查的最佳時機。總是有某些問題正在引起開發人員的注意，雖然我們總是想返回并添加錯誤處理，但卻總是在拖延!一旦某些事情似乎對管理層有用，就該著手處理下一個緊迫問題了。如果它有效，你為什么要在它上面投入更多的時間來減少回報?管理層沒有意識到你沒有包括錯誤檢查或實施中存在巨大的漏洞!如果產品需要健壯性，請不要嘗試稍后添加它，或者相信你可以稍后再返回并修復它。結論嵌入式開發人員編寫軟件的方式決定了他們的系統是否能夠從錯誤中優雅地恢復，關鍵是要有正確的開發態度，在編寫軟件時考慮可能出現的問題并實施恢復機制。為了更好地處理錯誤，請處理當前可能出現的問題，否則將永遠無法處理。...

2022-01-27點擊量：4944

嵌入式系統開發中常見的存儲器及其特點：第一節嵌入式存儲結構層次的劃分首先看一下嵌入式存儲體系的劃分，此處按照存儲速度進行劃分。●寄存器●高速緩存Cache●RAM（例如SRAM、DRAM、DDRAM）●主存儲器（例如Flash、PROM、EPROM、EEPROM）●外部存儲器（例如磁盤、光盤、CF卡、SD卡）●遠程二級存儲（例如分布式文件系統、Web服務器）那么問題來了，為什么會存在嵌入式存儲體系，都用寄存器或者磁盤存數據不就好了？其實計算機采用分級存儲體系的主要目的是解決存儲容量、成本和速度之間的矛盾問題。速度越快的存儲器，通常價格也越高。所有數據都采用寄存器存儲也是可以的，但是做出來的產品價格將會特別昂貴！用磁盤存所有的數據也行，但是嵌入式設備的運行速度將會特別慢！所以兩者在商業上并不可行。因此我們的寄存器一般用特別小的容量，Cache容量比寄存器大，主存儲器容量又比RAM大，如此遞推，可以獲得最佳的性價比。第二節寄存器通常是嵌入式開發中最高速的存儲器，由邊沿觸發方式的的觸發器、門電路組成，價格極為昂貴。主要作用是用來暫時存放數碼或指令一個觸發器可以存儲1位二進制代碼，故存放n位二進制代碼的寄存器，需用n個觸發器來構成。第三節高速緩存Cache大家在嵌入式開發中，可能比較少聽說過Cache這個詞，但Cache的作用是至關重要的。你可以把Cache理解為一個承上啟下的存儲器，它傳遞數據給CPU，又向主存獲取數據。那么為什么不直接從主存直接獲取內容傳給CPU？原因是存儲速度和儲存的局部性原理。為了緩解CPU和主存中速度差異，引入Cache這種比CPU速度慢但是又比主存速度快的中間介質會有效解決速度差異帶來的矛盾。再者存儲是有局部性的，在CPU運行時，所訪問的數據會趨向于一個較小的局部空間地址內（例如循環操作，循環體反復被執行）。所以高速緩存Cache用來存儲當前最為活躍的程序和數據，直接與CPU交互。Cache由半導體材料（通常是SRAM）構成，其功能對于程序員來說是透明的存在，所以大部分程序員都沒有留意到它。這里值得注意的是Cache的存儲內容是當前最為活躍的程序和數據。因此Cache有一個命中率的概念，即當CPU所訪問的數據在Cache中命中時，直接從Cache中讀取數據。若CPU訪問的數據不在Cache中，則還是需從主存中讀取。第四節RAMRAM是隨機存取存儲器（RandomAccessMemory）的簡稱，其存儲的內容可以隨意取出或者存入，且存取速度與存儲單元的位置無關，存儲速度快，通常作為操作系統或其他正在運行中的程序的臨時數據存儲介質。這種存儲器在斷電時將會丟失其存儲內容，故用于存儲短時間使用的程序和數據。嵌入式開發常見的RAM有：SRAM、DRAM、DDRAM（雙倍速率隨機存儲器）。①SRAM是靜態的，因此只要供電它就會保持一個值，不用對它進行周期性刷新。其由觸發器構成基本單元，每個存儲單元由六個晶體管組成，因此其成本較高，但它具有較高的速率，可以用來做Cache。②DRAM是動態的，需要有規律地定時進行刷新，但是價格比SRAM低。DRAM中的每個存儲單元由一個晶體管和一個電容器組成，因為組成包括電容器，而電容器會漏電，所以才要定期刷新，刷新周期一般為1ms。③SDRAM（SynchronousDRAM，同步動態隨機存儲器），即數據的讀寫需要時鐘來同步。其存儲單元不是按線性排列的，是分頁的。DRAM和SDRAM由于實現工藝問題，容量較SRAM大。但是讀寫速度都不如SRAM。④DDRAM（displaydataRAM）是顯示數據隨機存儲器的簡稱，為了解決SDRAM中讀寫速度慢的一種RAM。其基于SDRAM技術，引入一種叫做雙倍預取的技術（即在內存芯片內部的數據寬度是外部接口數據寬度的兩倍），使峰值的讀寫速度達到輸入時鐘速率的兩倍。第五節主存儲器主存儲器常見的有ROM和Flash兩種，一般被用來保存較大容量的數據，現在的人習慣把Flash也叫做ROM。其實ROM指的是只讀存儲器（ReadOnlyMemory，一般是指MaskROM）和Flash（閃速存儲器）有一定區別。但是Flash又是從ROM和RAM的發展而來，Flash不僅具備電子可擦除可編程（EEPROM）的性能，還可以快速讀取數據（RAM的優勢），就常被電商劃分為ROM了。主存儲器的種類：①MaskROM（掩模ROM）：一次性由廠家寫入數據的ROM，用戶無法修改。②PROM（可編程ROM）：由用戶來編程一次性寫入數據，只能寫入數據一次。③EPROM（電可擦寫ROM）：可以重復擦除與寫入，但是要通過紫外光才能擦除。④EEPROM（電可擦除可編程ROM，也就是E2PROM）：解決了EPROM的擦除問題，可以通過加電擦除原數據，擦除更加方便。⑤FlashMemory（閃速存儲器）：綜合了EEPROM的優點，而且極大提高了讀寫速度。常見的有NORFlash、NANDFlash。NORFlash允許程序直接在上面運行，但是價格比較貴。NANDFlash解決了NORFlash成本較貴的問題，但是NANDFlash的困難在于需要特殊的系統接口。⑥EMMC(EmbeddedMultiMediaCard）：將NANDFlash芯片和控制芯片設計成1顆MCP芯片，客戶只需要采購EMMC芯片，放進設備中，不需處理其它繁復的NANDFlash兼容性和管理問題，最大優點是縮短新產品的上市周期和研發成本，加速產品的推陳出新速度。第六節外部存儲器常見的外部存儲器分為磁盤存儲器、光盤存儲器、CF卡、SD卡。一般被用來保存大容量的數據，其特點如下：①磁盤儲存器：分為硬盤和軟盤，容量大、使用壽命長但價格昂貴，主要在個人PC中應用多，較少出現在嵌入式領域中。②光盤存儲器：用光學方式讀取/寫入信息的圓盤，一般用于多媒體數字信息的載體，較少出現在嵌入式領域中。③CF卡：最早推出的存儲卡，體積比磁盤儲存器和光盤存儲器小，抗磁性好、儲存性能穩定。④SD卡：可以看做CF卡的升級版，體積比CF卡小，安全性也更高。支持SD模式和SPI模式，外圍只需簡單電路就可以用于嵌入式開發。嵌入式領域最常見的外部存儲器。第七節存儲管理和頁面置換算法通過前面幾節的學習，我們對嵌入式存儲體系有了一定的了解，那么在這個體系下，會出現一個問題—當進程運行所需的內存大于系統內存時，就無法將整個進程一起調入系統內存，因此無法運行。為了解決上面這個矛盾，我們采用頁式存儲或者段式存儲將進程空間劃分。此時總的進程空間就會變成多個小段的進程空間，然后通過頁面置換算法進行淘汰，使分出的小段進程空間有序調入內存中運行。...

2022-01-26點擊量：4647

嵌入式系統的分層在我們學習嵌入式的過程中是必須了解清楚的，尤其是作為硬件工程師來說，你不熟悉這些構造對你的工作影響非常大。我們如果從下到上分解嵌入式系統，我們可以分為硬件層，驅動層，系統層，應用層。如果你發現有些嵌入式系統沒有系統層，這是非常正常的，你也會發現沒有系統層的嵌入式系統是相對簡單的。對于不同的分層，我們需要學習的內容也是不一樣的，例如硬件層，這個一般是硬件工程師的活，對于他們來說模擬電路、各種元器材還有數字電路是必須摸通摸透的，當然還包括設計PCB，懂FPGA開發等。而驅動層，中斷過程、bootloader過程、相關處理器體系結構都是需要熟悉的。至于硬件原理圖、時序圖不用說，也是要讀懂的。我們再看到系統層這邊，一般來說，這一層大家都不會動手去寫操作系統，并不是懶，只是移植會更方便而已。即便如此，該會的還是要會的，例如你要移植Linux，那你u-boot移植不能丟，還有交叉編譯、內核調試、根文件系統制作等整個流程也是要熟記在心的。至于應用層，我們需要分情況來看，是否有操作系統。如果沒有，那程序一般是比較簡單的。但如果有的話，你不妨將其看成桌面軟件開發。一般來說掌握Linux操作系統的相關知識即可。雖然看著需要掌握的東西不少，但我們在學習嵌入式時做好定位，再分層熟悉學習，還是非常快速能搞懂的。...

2022-01-26點擊量：4638

學習嵌入式的朋友應該都經歷過絕望的51單片機，畢竟有44個操作碼助記符，33種功能，其操作數有#data、direct、Rn、@Ri等。要全部記住，而且熟練運用可不是短時間內就可以辦到的，深入的了解單片機，除了搞清內部功能、存儲空間分配及I/O接口外，還應掌握其指令系統。MCS－51共有111條指令，這里介紹一下指令助記符及其相關符號的記憶方法，希望可以幫助到大家。我們可以通過表格，將指令分為幾大類，通過異同點來記憶，這樣的就不會像個無頭蒼蠅一樣，盲目死記硬背。同時我們還可以通過英語來記憶，當然不是讓你背單詞，而是將縮寫還原成原樣。因為這樣可以幫助我們理解它的原意，而不是一個毫無意義的符號，我們通過中英聯想對照，從而加強記憶。我們也可以通過功能將指令區分，比如數據傳送，邏輯運算等，這樣模塊式的記憶比逐個記憶方便許多。當然，也可通過指令操作數的有關符號來記憶，MCS-51的尋址方式共有六種：立即數尋址、直接尋址、寄存器尋址、寄存器間址、變址尋址、相對尋址。人的記憶對于圖像比起文字來說更加敏感，通過將每一個指令用圖片來具象化，這樣我們記憶和運用的時候就可以通過圖片聯想法來記憶。或許上述方法大家都覺得麻煩，那么只能說，還是笨鳥先飛吧，秉承學習嵌入式的一貫作風，做就是了，畢竟熟能生巧嘛。...

2022-01-25點擊量：4729

在我們剛接觸嵌入式的時候我們總是不可避免的遇到許多總線，但在初學者眼里這些總線貌似都差不多。不管是高速總線，低速總線還是數據總線，初學者都是很難區分的，所以這里簡單介紹一下總線最常用的幾種分類方法。首先，最常見也是最常用的分類就是按照功能來分。那按照這種分類方法，我們可以把總線分為地址總線、數據總線、控制總線。地址總線正如其名字所述，地址總就是用來傳送地址的，數據總線就是傳送數據，而控制總線就是傳送控制信號的。地址總線的位數決定了存儲空間，16位最大可存儲216，也就是64KB。而數據總線更多變一點，除了傳送的不一定是完全意義上的數據，其傳輸方式也更多。如單向傳輸和雙向傳輸，一般來說，雙向傳輸使用的是雙向三態形式。和數據總線相比，控制總線一般都是雙向的，傳送方向也是看具體控制信號，位數也要看實際的系統需要來定。除了按照功能劃分，我們還可以按照傳輸方式來劃分為串行總線和并行總線。如果僅僅從理論上來看，并行會比串行更好，但成本卻更高。更淺顯一點來說，并行就是多條道路，而串行就是單線公路。嵌入式還會學到一種比較少見的分類就是按照時鐘信號方式分類，這種分類方式分為同步總線和異步總線。同步總線的時鐘信號獨立于數據，也就是說要用一根單獨的線來作為時鐘信號線;而異步總線的時鐘信號是從數據中提取出來的，通常利用數據信號的邊沿來作為時鐘同步信號。最后一種分類方法按功能和規范劃分也是比較常見的，分為片總線(ChipBus，C-Bus)和外總線(ExternalBus，E-Bus)，片總線(ChipBus，C-Bus)又稱元件級總線，是把各種不同的芯片連接在一起構成特定功能模塊(如CPU模塊)的信息傳輸通路，它的寬度可以是8、16、32或64位。目前比較流行的幾種內部總線技術：I2C總線、SCI總線等。外總線(ExternalBus，E-Bus)又稱通信總線，是微機系統之間或微機系統與其他系統(儀器、儀表、控制裝置等)之間信息傳輸的通路，如EIARS-232C、IEEE-488等。...

2022-01-25點擊量：4809

有個朋友說他之前是學機械的，想轉嵌入式，需要點意見。一般來說，需要的建議有兩方面，一方面是應不應該轉行，另一方面是如果真的轉了，要怎么學才好。其實機械轉嵌入式，會比其他專業更容易一下，因為雙方都是有聯系的，甚至在學習硬件開發這塊會有一定幫助。在未來，單一型人才將會沒那么吃香，除非你研究得非常深入，但即便如此，中間過渡也是長時間單一性。作為企業，肯定是希望你什么都懂，這樣自己可以節約人力成本。而作為求職者，個人技能越多，對于職位，薪資肯定也會有一定程度的影響。不管你是從什么專業轉過來的，學習嵌入式第一件事肯定是要學習C語言，這是一切的基礎。C++要知道什么是類，怎么定義，繼承，接口，要深刻理解，當然基本語法也是必不可少的。操作系統原理也應該知道基本的原理的，什么時間片，任務調度，都是需要知道。然后，裸機、RTOS、Linux編程這些都要大概掌握一下。一開始看書不明白是正常的，但一定要多動手，這樣可以幫助你快速記憶，快速學習。比如今天整個LED，明天再搞個串口，逐步積累，直到你能做項目。不管你是自學還是培訓，你都一定要通過開發板去進行學習，只有自己親自動手的東西才是屬于自己的，這個道理相信做機械也是一樣見多識廣，熟能生巧。學習嵌入式要多看代碼，要從代碼中讀出代碼的意思來，自己平時也要多寫代碼，多練習的。...

2022-01-24點擊量：4462

學習嵌入式從來都不是只有一條出路，你可以選擇硬件，你也可以選擇軟件，甚至你可以選擇這兩者以外的道路，而在不同的方向之間也可以進行轉化，一旦覺得自己不合適，也沒有必要一路走到黑。當你剛從硬件轉成軟件，可能會覺得天大的問題都不是問題，擼起袖子就是干。但一定要抑制住你的沖動，有時候盲干不是解決問題，而是在創造問題，這時候我們應該先用流程圖制定一個軟件架構圖。這樣我們可以有一個簡單的草稿，等實操起來就不需要過多的試錯，節省了時間，也省去了不少麻煩。軟件是復雜的，不管是開發，還是維護上都是復雜的。對于從硬件轉過來軟件的更是如此，面對一些單一文件時，又或者面對松散關聯的多個文件時，建議分解成模塊。這不單單增加了可維護性、減少了復雜性、也提高了可重用性。工程學有個舊詞叫做“KISS”，不要想歪，可不是你想的那個，而是保持簡單，直接的英文縮寫。正如上述說的模塊化一樣，讓事情簡單是非常重要的，因此我們在編寫代碼，進行開發的時候要限制功能復雜度。其實不管是嵌入式教程硬件轉軟件，還是一直從事軟件開發的人員一直都不一定擁有良好的習慣，比如詳細說明代碼，即便是簡單的加個注釋。為了趕進度，也可能是忘了，各種理由和因素的影響導致許多人久而久之就沒有了這樣的習慣。但注釋不管是對于自己還是別人讀懂這個代碼的幫助是非常大的，在日后的維護中，也是必不可少的部分。...

2022-01-24點擊量：4589

信息時代、數字時代使得嵌入式產品獲得了巨大的發展契機，為嵌入式市場展現了美好的前景，同時也對嵌入式生產廠商提出了新的挑戰，從中我們可以看出未來嵌入式開發技術的幾大發展趨勢：技術#1–嵌入式DevOps在過去十年左右的時間里，軟件DevOps對一般軟件開發進行了顯著改進，但嵌入式開發人員通常忽略了它。部分是因為大多數電氣工程師和嵌入式軟件開發人員在學校或職業生涯早期都沒有接觸過它。因此，雖然他們可能知道它的存在，但對項目的持續努力阻止了他們成功構建DevOps流程。對于希望恢復他們開發軟件的方式的開發人員，這里有幾條建議。首先，學習如何使用Docker設置嵌入式工具鏈。接下來，使用CI/CD服務器自動化構建過程。最后，如果時間允許，通過添加代碼分析、單元測試、集成測試等來繼續改進您的CI/CD流程。每天和每周都采取一些小步驟，到今年年底，您將開始擁有一個出色的DevOps流程。技術#2–自動化硬件在環測試除了調試之外，嵌入式開發人員和團隊遇到的頭號問題是測試。測試總是一個問題有幾個原因，例如：測試通常仍保留為手動過程、對硬件進行自動化測試似乎既復雜又耗時、團隊急于編碼，而測試是事后的想法、軟件界面設計不當……硬件在環測試并不是什么新鮮事物，但卻是一種經常被忽視的能力。因此，測試可能會被忽略，因為您需要考慮您的DevOps才能正確執行測試。有許多硬件在環技術，建議花一些時間來評估自動化目標測試是否可以顯著提高代碼質量和開發成本，如果答案是肯定的，請設定一些簡單的目標來研究特定技術，并逐步將這些功能添加到您的測試體系中。隨著時間的推移，您將慢慢移除手動測試并用自動化測試取而代之，這將節省每個人的時間、壓力和您的公司資金。技術#3–多核微控制器開發多核微控制器的使用將在未來幾年猛增，我認為它們在嵌入式開發中變得無處不在有幾個原因，例如：許多應用程序需要隔離運行時環境、低功耗應用可以從打開和關閉功能目標內核中受益、將應用程序分成運行時域在架構上是有意義的、多核微控制器的成本正在急劇下降（撇開一些供應鏈問題不談）。技術#4–ArmTrustZone安全是重要驅動因素，或者應該是我們設計和制造的產品的主要驅動因素。因此，我們需要在2022年及以后掌握安全技術，以保護我們的知識產權（固件）和客戶的數據和隱私。有多種安全解決方案可用于微控制器，包括使用多核處理器來創建隔離的運行時環境。盡管如此，我認為將TrustZone單獨作為一種學習技術是有道理的，這有幾個原因，例如：新的Arm微控制器架構具有TrustZone選項、TrustZone工具正在進入大多數商業甚至開源工具、TrustZone提供更接近許多開發人員熟悉的軟件模型的單核解決方案……技術#5–學習C++多年來，C++在嵌入式應用程序中慢慢變得越來越流行。該標準不斷更新，并為嵌入式開發人員提供了現代面向對象的工具來設計和構建他們的系統。在過去的兩年里，很多公司編寫的C++項目比C還多！...

2022-01-22點擊量：4848

看到這個問題，很多人就會覺得奇怪，這不就是開和關嘛，不學嵌入式都知道。確實，“O”和“|”分別代表著關和開，但為什么是“O”和“|”而不是別的?很多人認為O是open，或者ON的首字母，但這個說法很明顯不對，因為Off的首字母也是O，在很多電器上我們都可以看到，但off的意思是關閉，所以很明顯O不是open或者on的首字母。當然還有人人為“O”和“|”分別是output/input的首字母，因為翻譯過來就是輸出和輸入的意思，這個解釋貌似合理，“O”和“|”分別代表著關和開。但很可惜，還是不對。眾所周知，計算機都是使用二進制的，而二進制你會發現只有兩個數字，而這兩個數字分別是0和1。看到這里是不是有點眼熟了，沒錯，“O”和“|”其實就是0和1，是不是比大家想象中簡單許多。在二戰期間，為了讓不同國家的人都能正常使用電氣設備，那必須要統一規格。不管是海陸空，還是說我們的日常生活，最起碼要先學會開啟和關閉設備，我們才可以使用設備，而且要快速掌握。最后發現數字是最簡單辨認的，而在二進制中「1」代表「開啟」「0」代表「關閉」于是，有了開關上的“|”和“O”。畢竟當時不是所有人都接觸英語，但數字卻是通用的。嵌入式確實不會告訴你“O”和“|”的來源，但當你知道它們為何是這樣后，也能感受到其自身的魅力，不妨繼續學習和探究下去，或許我們身邊不起眼的某樣事物背后有著許多有趣的故事。...

2022-01-22點擊量：4990

許多微控制器都帶有一個生態系統，其中包括外圍驅動程序、RTOS、中間件甚至示例應用程序代碼。許多嵌入式開發人員可以將大部分時間花在高級應用程序代碼上，而忽略了滿足硬件的軟件。問題是，雖然這個預構建的生態系統可以加速開發，但這種加速通常是以時鐘周期和執行效率為代價的。在今天的文章中，我們將探討開發人員可以應用的幾個技巧，以幫助提高其中斷服務例程回調的效率，這些回調與許多微控制器軟件框架緊密集成。先決條件–測量ISR執行時間加速軟件執行的第一步是停止并進行一些測量。你如何知道你的中斷處理程序是使用過多的CPU時間還是運行緩慢？你量一下！開發人員可以利用幾種不同的選項來測量中斷執行時間。首先，只需切換GPIO線！我經常將測試GPIO線初始化為高電平，然后當我進入ISR時，我會將GPIO線切換為低電平，然后在退出ISR時再次將GPIO線切換為高電平。結果是一個低電平有效信號，它近似代表ISR執行時間。測量值是近似值的原因是它沒有考慮切換GPIO線的時間，我們假設它可以忽略不計（但如果你使用的是框架代碼，則可能不是！）。這種方法產生了一個簡單且易于測量的波形。第二種方法，我將簡要提及的是使用跟蹤軟件。如果你使用的是RTOS，RTOS通常會記錄系統中發生的事件，包括進入和退出中斷服務程序。嵌入式開發人員可以使用他們的跟蹤分析器來了解他們的中斷服務程序執行了多長時間。現在乍一看，上面測得的24.3us對于ISR來說似乎并不算太糟糕。這實際上取決于應用程序的好壞，但總的來說，我們希望ISR執行時間盡可能短。在這個例子中，我設置了一個輸入捕捉外設來測量輸入信號的頻率。如果頻率只有區區20KHz，這個ISR將占用大約50%的CPU周期！技巧#1–在ISR中調用的內聯函數首先，從ISR調用函數是個壞主意！函數調用開銷會給中斷增加一大堆浪費的時鐘周期，這將延遲返回到定期安排的代碼執行。但問題是許多現代框架都這樣做！現在，我添加了GPIOHAL調用，但你可以看到，默認情況下，中斷會調用HAL_TIM_IRQHandler，這是STM32上所有定時器的通用中斷處理程序。（對于可重用和可移植的代碼來說，這是一個很棒的框架理念，但它可能對時間敏感的代碼有害）。這里沒有試圖告訴編譯器我們處于ISR中，因此編譯器可能會添加函數調用的代碼并向ISR添加無用的循環。事實上，這個函數會有條件地檢查并調用幾個函數，這可能會使事情變得更糟。內聯函數可能會減少執行時間，但會以稍大的代碼大小為代價。提示#2–自定義默認中斷服務程序(ISR)預構建的框架通常會將外圍類型的中斷處理集中在一起。例如，我們剛剛看到的定時器中斷，它傳遞了一個定時器對象，然后有一堆條件語句來決定它應該做什么。該框架是為重用而不是執行速度而構建的。如果我重寫我的中斷以刪除所有這些通用函數調用，中斷執行時間變為21.712，現在為我們節省了2.5us(10.3%)！對于我們正在查看的數字，它似乎并不多，但如果這是一個高頻中斷，那可能是大量的CPU使用率。提示#3–優化中斷服務程序(ISR)回調函數我經常注意到，編寫各種功能的示例代碼是為了向嵌入式開發人員展示如何完成某事。例如，許多供應商將提供輸入捕獲代碼，以顯示如何計算信號的占空比和頻率。這太棒了，除了代碼通常是在中斷服務程序中執行的。這是次優的。一個例子。算法通常是正確的，但它們不是以生產意圖的方式完成的。他們可能不會考慮重要的考慮因素，例如CPU負載和實時響應。他們只是想向你展示他們的部分可以做你需要的事情，測量頻率或任何功能。今天的嵌入式開發人員擁有如此多的示例代碼和如此多的開箱即用的框架供我們利用，這真是太棒了。需要注意的是，這段代碼可能不是為我們自己的目的而設計或實現的。它通常被快速編寫以展示一個特性或功能，而不是為生產而設計的。...