將質(zhì)量融入嵌入式軟件并非偶然。質(zhì)量必須從一開始就內(nèi)置。下面是嵌入式開發(fā)人員可以使用的清單，以確保他們以正確的方式開始嵌入式軟件實施階段，并牢記質(zhì)量
階段1——項目設(shè)置
設(shè)置版本控制
創(chuàng)建項目
創(chuàng)建項目目錄結(jié)構(gòu)
空白配置/設(shè)置
項目設(shè)置的第一階段可能看起來微不足道，但包含了保證質(zhì)量的關(guān)鍵步驟。應(yīng)該首先建立一個修訂控制系統(tǒng)，而不是在軟件復(fù)雜到開發(fā)人員開始失去代碼的時候。另一個經(jīng)常被忽略的方面是為項目編輯器設(shè)置空白和制表符間距。許多開發(fā)人員在IDE上有自己的偏好，因此為了確保源文件保持正確的格式，需要在所有環(huán)境中一致地設(shè)置空白。
第2階段——配置
Doxy模板和工具設(shè)置
導(dǎo)入框架HAL/API模板
版本日志
硬件配置
一旦建立了項目環(huán)境，嵌入式開發(fā)人員應(yīng)該創(chuàng)建一個基礎(chǔ)版本，這樣他們就可以從頭開始跟蹤代碼基礎(chǔ)的變化。版本日志通常在開發(fā)人員列表的最后，但是為了正確地捕獲變更，應(yīng)該首先創(chuàng)建版本日志。在整個開發(fā)周期中，從開發(fā)套件硬件到alpha和beta版本，硬件經(jīng)常會發(fā)生多次變化。硬件配置文件可用于有條件地編譯和調(diào)整目標(biāo)硬件的代碼庫。
正在配置項目的開發(fā)人員也應(yīng)該考慮使用源模板和頭模板。嵌入式軟件應(yīng)該有一致的外觀和感覺，并有良好的文檔記錄。基于Doxygen的模板除了提供自動生成軟件手冊的能力之外，還可以提供這種外觀和感覺。
階段3——代碼分析
設(shè)置靜態(tài)分析工具
設(shè)置代碼指標(biāo)
動態(tài)代碼分析(如果你可以使用該工具)
許多嵌入式開發(fā)人員和團隊相當(dāng)不擅長執(zhí)行代碼分析或度量，直到在項目中為時已晚。在開發(fā)周期的早期建立靜態(tài)和動態(tài)代碼分析將有助于開發(fā)人員在開發(fā)代碼時發(fā)現(xiàn)潛在的問題并驗證是否符合編碼標(biāo)準(zhǔn)，而不是在最后。分析和度量工具——如果及早使用——可以減少bug，并幫助開發(fā)人員在問題出現(xiàn)時就發(fā)現(xiàn)它們，避免它們積累成一個龐大而難以管理的數(shù)字。
階段4–調(diào)度程序設(shè)置
設(shè)置RTOS或裸機調(diào)度程序
需要設(shè)置系統(tǒng)計時器/驅(qū)動程序
創(chuàng)建一個任務(wù)，使LED作為指示器閃爍
幾乎每個嵌入式系統(tǒng)都有一個調(diào)度程序來驅(qū)動系統(tǒng)。調(diào)度程序可以是簡單的裸機調(diào)度程序，也可以是成熟的實時操作系統(tǒng) (RTOS)。一旦調(diào)度程序就位，創(chuàng)建一個可以周期性閃爍 LED 的任務(wù)是讓嵌入式系統(tǒng)說“Hello World”的好方法。
第 5 階段 - 設(shè)置調(diào)試消息
設(shè)置調(diào)試消息
通過調(diào)試器進行 RTT
UART 驅(qū)動程序
Printf 設(shè)置或等效的 RTT
配置斷言
許多嵌入式開發(fā)人員等到發(fā)現(xiàn)軟件行為有問題時才建立調(diào)試消息或?qū)崟r跟蹤。等待問題被發(fā)現(xiàn)已經(jīng)太晚了!如果在潛在的錯誤、時間問題或其他問題第一次出現(xiàn)在系統(tǒng)中時就發(fā)現(xiàn)了它們，而不是在幾周或幾個月后才發(fā)現(xiàn)，那么捕捉這些問題要容易得多。通過設(shè)置調(diào)試和跟蹤功能以及消息傳遞打印函數(shù)因此，在編寫任何應(yīng)用程序代碼之前，RTT應(yīng)該是重中之重。
第6階段–開始開發(fā)
只有在前五個階段的任務(wù)完成后，開發(fā)人員才應(yīng)考慮開始應(yīng)用軟件開發(fā)。當(dāng)然，根據(jù)團隊的不同，這個清單可能會有所增加。本文中包含的列表提供了開發(fā)人員為了成功地開始開發(fā)過程應(yīng)該完成的最低任務(wù)集。顯然，高質(zhì)量的軟件不會自己編寫，嵌入式開發(fā)人員需要遵守紀(jì)律，使用他們建立的工具。
你認為清單中還應(yīng)增加哪些任務(wù)或軟件啟動項目?