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