嵌入式應(yīng)用軟件開發(fā)流程.

1、嵌入式應(yīng)用軟件開發(fā)流程目錄 確定需求 確定方案 程序編碼 代碼調(diào)試 交叉編譯 聯(lián)調(diào)測試 打包程序 現(xiàn)場試用 穩(wěn)定性測試確定需求 硬件資源：首先應(yīng)確定目標(biāo)板的硬件資源，包括各種器件和設(shè)備，這對內(nèi)核編譯和驅(qū)動(dòng)的開發(fā)至關(guān)重要。 軟件資源：然后應(yīng)確定我們能使用的有哪些軟件資源，如工具鏈、IDE和第三方庫等。 功能需求：用戶都需要哪些功能，在現(xiàn)有的硬件和軟件資源情況下能否實(shí)現(xiàn)。 界面需求：用戶有沒有界面需要，是彩色液晶還是單色液晶，操作鍵盤有多少個(gè)鍵，各個(gè)鍵的功能等。 性能需求：穩(wěn)定性、響應(yīng)速度、運(yùn)行速度、容錯(cuò)性等性能需求。 接口需求：對外有多少個(gè)硬件接口和軟件接口，都有哪些要求。 其它需求：如工期、交

2、付物形態(tài)等。確定方案 開發(fā)工具：我們將使用哪種或哪幾種語言進(jìn)行編程，編程時(shí)會用到哪些工具等。 開發(fā)方法：我們將采用哪種思想或哪種模式進(jìn)行開發(fā)，開發(fā)過程需要哪些資源等。 程序架構(gòu)：程序的哪些內(nèi)容可以做成平臺，哪些內(nèi)容應(yīng)當(dāng)實(shí)現(xiàn)成接口，哪些內(nèi)容可以抽象等。 程序詳細(xì)方案：程序功能時(shí)序順序、詳細(xì)類結(jié)構(gòu)和數(shù)據(jù)庫結(jié)構(gòu)等。程序編碼 程序編碼其實(shí)通俗易懂，就是將詳細(xì)設(shè)計(jì)方案實(shí)現(xiàn)成代碼的過程。但我們?nèi)匀粦?yīng)當(dāng)注意以下幾點(diǎn)： 切記只使用標(biāo)準(zhǔn)C/C+的庫，因?yàn)樘嗟牡谌綆鞎屇愕某绦蜃兊糜纺[，這違背了嵌入式的宗旨。 面向?qū)ο笤谇度胧絃inux開發(fā)中可用，但不是到處都非用不可，有些地方不用反而更好。 時(shí)刻牢記嵌入式軟

3、件的可擴(kuò)展、可裁剪特性。 時(shí)刻牢記軟件的異常處理，如可能發(fā)生的指針錯(cuò)誤等，但你不可以拋異常，而應(yīng)該記錄異常。 你應(yīng)當(dāng)熟悉甚至精通STL和系統(tǒng)的API函數(shù)庫，并將其用到你的實(shí)際工作中，否則你的工作將會事倍功半。代碼調(diào)試 代碼編寫完成后，我們應(yīng)當(dāng)進(jìn)行調(diào)試，而且是100%覆蓋率的逐行調(diào)試。 由于我們只使用標(biāo)準(zhǔn)C/C+進(jìn)行代碼編寫，所以我們一般會在開發(fā)主機(jī)中先對代碼進(jìn)行調(diào)試，來排查和編譯器無關(guān)的問題。 使用Eclipse等IDE，會讓代碼調(diào)試更加輕松，這比直接使用GDB進(jìn)行調(diào)試要友好得多。 原則：不放過一個(gè)警告，因?yàn)榫媸菨撛诘腻e(cuò)誤。交叉編譯 首先編寫交叉編譯腳本Makefile，定義CPU架構(gòu)、代碼

4、目錄和編譯選項(xiàng)。 執(zhí)行make，編譯程序。 排除出現(xiàn)錯(cuò)誤，不放過一個(gè)警告。因?yàn)?，警告是隱含的錯(cuò)誤，也許將來警告就會變成錯(cuò)誤。聯(lián)調(diào)測試 這一步又叫集成測試，有兩種集成：內(nèi)部集成和系統(tǒng)集成。 內(nèi)部集成：多進(jìn)程、多線程之間的聯(lián)動(dòng)測試，系統(tǒng)模塊之間的聯(lián)調(diào)測試。 系統(tǒng)集成：和其它子系統(tǒng)的聯(lián)調(diào)測試，比如自動(dòng)路測儀應(yīng)當(dāng)和近端調(diào)試軟件、遠(yuǎn)端控制軟件進(jìn)行聯(lián)調(diào)測試，保證軟件功能和其它子系統(tǒng)沒有歧義。打包程序 準(zhǔn)備需要打包的資源，如主程序、動(dòng)態(tài)庫、配置文件、腳本和第三方庫等。 編寫打包腳本（開發(fā)主機(jī)） 。 編寫安裝腳本（開發(fā)主機(jī)） 。 測試打包腳本（開發(fā)主機(jī)）。 測試安裝腳本（目標(biāo)板）。 打包并發(fā)布程序和安裝腳本。

5、 有些場合你可能還需要編寫一個(gè)專用于刷寫用戶程序的PC程序?，F(xiàn)場試用 原因及其重要性：前面的過程基本上都是研發(fā)人員閉門造車的結(jié)果，能否滿足用戶需求，適應(yīng)現(xiàn)場情況，還不確定。嵌入式設(shè)備一般都要求無故障運(yùn)行很長一段時(shí)間，或者出現(xiàn)故障能夠自動(dòng)恢復(fù)，而且現(xiàn)場試用能夠發(fā)現(xiàn)我們在實(shí)驗(yàn)室發(fā)現(xiàn)不了的問題。 方法：假如現(xiàn)場已有工程點(diǎn)，則挑選一定數(shù)量的工程點(diǎn)進(jìn)行試用。假如沒有工程點(diǎn)，則應(yīng)模擬實(shí)際現(xiàn)場情況進(jìn)行測試。穩(wěn)定性測試 穩(wěn)定性測試是研發(fā)人員在進(jìn)入維護(hù)階段后應(yīng)該認(rèn)真執(zhí)行的事，目的是發(fā)現(xiàn)一些細(xì)微的問題，或者是測試人員沒有發(fā)現(xiàn)的問題，并確定程序能否滿足長期運(yùn)行的要求。 嵌入式軟件的穩(wěn)定性要求非常之高，想象一下，假如程序不穩(wěn)定，那么我們的技服人員可能需要每天疲于奔命的去追著公交車跑維護(hù)，那會是我們花不起的成本。結(jié)語 嵌入式軟件的穩(wěn)定性重于一切，從挑選工具和第三方庫的時(shí)候，就應(yīng)該考慮這一點(diǎn)。請研發(fā)人員重視測試！ 面向?qū)ο笫呛脰|西，用好，用恰當(dāng)了是關(guān)鍵?？紤]到代碼大小和遠(yuǎn)程升級，用C可能是更好的選擇。實(shí)現(xiàn)復(fù)雜度和代碼體積總是成反比的。 如果有遠(yuǎn)程通信