在過去的幾年中，我注意到嵌入式系統開發人員和團隊之間的趨勢非常令人不安。趨勢包括開發功能（最好）但不是為生產環境構建或測試的嵌入式系統。這種趨勢導致災難。

這種“簡單功能”趨勢的主要原因似乎是由于三個因素：利用示例代碼，匆忙的開發周期，以及缺乏理解它需要什么構建生產嵌入式系統。利用示例代碼的第一個因素實際上是啟動嵌入式軟件開發的關鍵一步。示例代碼有助于啟動和運行嵌入式系統，以及獲得對目標硬件的重要見解。許多微控制器供應商為開發人員提供了有關如何設置外設和與微控制器交互的急需的示例代碼。

但是，許多開發人員通常不會考慮這個示例代碼。首先，示例代碼只是一個例子;它不適合生產。它只是如何設置和與各種外圍設備交互的指南。然而開發人員將采用代碼，一旦將示例代碼引入系統，它通常會保留在系統中。

仔細檢查來自不同微控制器供應商的示例代碼，經常會發現免責聲明所提供的代碼不能保證適用于任何目的。它甚至不能用于任何目的，而只是“原樣”提供。只要閱讀免責聲明，就應該讓嵌入式軟件開發人員在考慮采用該代碼時感到不安。該軟件的制作人沒有足夠的信心支持他們的榜樣，那么是什么讓人們認為示例代碼產品已經準備就緒？

檢查硬件寄存器標志時，通常可以看到功能示例代碼的一個很好的例子。圖1顯示了類似于人們通常會發現的內容。

圖1 - 示例代碼硬件寄存器標記檢查

一個問題使用圖1中的代碼是 while 循環假設操作最終會成功完成。在理想條件下，這可能是真的，但如果硬件出現故障會怎樣？也許振蕩器正在漂移，因此無法實現同步。也許寫入閃存失敗了。當流氓出現故障的外部傳感器導致總線停機時，硬件檢查可能在通信總線標志上，從而無法完成傳輸。在這些情況下，使用圖1中的代碼的結果將是無限循環，需要外部力量（例如看門狗定時器）的干預。即使這樣，看門狗定時器也會重置系統，但不能保證系統不會在循環中結束，進入永久復位的永久循環。

為生產環境編寫的軟件應該適應失敗的可能性。某些場景的解決方案（如圖1中的 while 循環）可能是基于系統節拍向循環添加超時，或者可能建立最大數字標志檢查。這些將阻止系統進入無限循環或永久復位循環。

圖2中的示例演示了如何將附加條件添加到 while 循環中，以便系統退出發生故障時的循環。這些添加不是使系統掛起等待救援的無限循環，而是生成錯誤代碼，該錯誤代碼警告調用例程感興趣的硬件標志已超時。然后，系統可以在不調用最后一個監視器的情況下采取糾正措施。

圖2 - 生產代碼硬件寄存器標記檢查

導致構建功能性而非生產意圖嵌入式系統趨勢的第二個因素是匆忙的開發周期。開發嵌入式系統會給企業帶來巨大的管理成本，這使得企業希望昨天進入市場。此外，初創企業，小型企業和銷售團隊因樂觀地設定生產日期而不考慮開發強大的生產就緒系統所需的實際工作而臭名昭著。許多工程師要么在這種情況下拒絕接受管理，要么他們確實發現他們的擔憂被置若罔聞。最終結果是角落被切割以試圖滿足不切實際的最后期限，這導致設計僅包含僅在一系列非常受控的條件下工作的功能代碼。

有助于發布功能性而非生產意圖的嵌入式系統的最終因素是缺乏對如何構建生產意圖嵌入式系統的理解。嵌入式軟件和系統工程師需求量大，供不應求。這種情況導致公司在校外或從不同學科的工程師（如網絡或應用程序開發）中擔任重要角色。結果是如何正確地構建和實現健壯的嵌入式系統的知識差距，這些嵌入式系統不需要每天更新修補程序錯誤并修復安全問題。

但是，綠色和跨學科的工程師并非完整的故事，導致人們對生產嵌入式系統的真正缺乏了解。經常會要求訓練有素且經驗豐富的工程師開發原型或概念證明。為了向管理人員演示，工程師們提供了一個基于功能性示例代碼的漂亮功能原型。演示很順利，但該系統只能在受控條件下工作。但由于演示進展順利，管理層希望立即運送系統，而不是理解仍需要做很多工作才能使系統生產準備就緒。

嵌入式系統正在進入我們生活的每一個角落。對于在受控條件下操作的一些設備，僅使用功能代碼可能是好的。但隨著物聯網和自主智能社會的快速發展，運輸功能而非生產代碼的危險趨勢是等待發生的事故。