很多人開始一個新的嵌入式項目，第一反應是購買開發板。一旦有了開發板，嵌入式開發人員就可以設置開發環境，獲得一些示例代碼，開始運行并編寫項目代碼。但是這真的是開發嵌入式軟件的最佳方式嗎?自下而上的方法真的能最有效地實現企業和客戶的目標嗎?
自下而上方法的問題
嵌入式軟件開發人員自然會自下而上地思考。假設我告訴一個團隊，一個產品需要的第一個功能是一個可以打開和關閉的加熱器。我不知道加熱器是如何工作的。沒有人問最小值和最大值、客戶安全機制、滯后、砰砰控制或諸如此類的需求。相反，我被問及加熱器連接的GPIO引腳、GPIO外圍設備如何工作、必須開發的驅動程序等。
事實是那些低級的細節并不重要。客戶、你的老板和企業并不關心這些細節。他們需要一個可以開關的加熱器，有最小值和最大值，可能還有超時等等。事實上，他們需要盡早看到這個軟件及其行為，以驗證功能并確保產品特性符合他們的需求。
嵌入式開發人員不是從產品特性開始，從應用程序堆棧的頂部獲得早期反饋，而是關注底層細節，并逐步提升。他們得到一個開發板，編寫一堆驅動程序，集成中間件，通常，經過幾個月的努力，最終得到應用程序代碼。在此期間，開發人員在開發板上編寫代碼，通常沒有足夠的工具，這將經歷一個非常緩慢的編譯、擦除、編程和調試周期。
嵌入式軟件的自上而下方法
在開發嵌入式產品時，你確實希望盡快獲得應用程序代碼。你越早在客戶面前獲得產品及其功能的反饋越好。你可能會發現產品走錯了路，甚至你的團隊認為非常棒的產品變成了死胡同!如果是這樣的話，所有在開發板上工作以啟動和運行低級代碼的時間都將被浪費，更不用說所有的錢了。
在許多情況下，一種更好的方法(老實說，沒有辦法對它們全部進行規則化)是從應用程序代碼開始，并朝著低級代碼的方向努力。這對嵌入式開發人員來說聽起來很荒謬，但它會帶來更好的產品。如果你從應用程序開始，你可以快速地在客戶面前獲得功能。客戶反饋至關重要。你會發現，你被迫為尚未編寫的低級代碼創建接口。你可能正在PC上進行設計，并使用網絡適配器作為模擬USART。該接口將使你的代碼更加靈活，這樣你就可以更好地測試、移植它，并在其他產品中重用它。事實上，這些接口將使你更容易測試代碼，并且你的代碼不會關心底層細節。你的代碼將與硬件解耦!
改變你的思維方式
我們可以想出很多借口來解釋為什么我們應該在開發板上開發嵌入式軟件。我們可能會說，我們需要硬件加速，或者我們需要了解目標硬件的某些功能才能構建系統。有時情況確實如此，但你通常可以為應用程序代碼抽象這些細節。恢復機制、固件更新等可能需要低級別的詳細信息。
如果你在早期階段放棄開發板，專注于應用程序代碼，你會更快地行動，擁有更靈活的代碼庫，獲得客戶反饋，最終獲得更可靠的系統。這不是一個保證，但在時間和預算上更有利于你。
訣竅是嵌入式開發人員從上到下改變你對開發嵌入式軟件的看法，而不是自下而上。
京公網安備 11010802030320號