一

錯誤的示范

近公司新招了一個做嵌入式軟件開發的同事，該同事是從上海的某一個上市公司出來的，因為我們這邊人手不夠，因此把他安排了去負責一個新產品的研發，前期讓他負責加速度計、NB-IOT、舵機、外置Flash的功能測試，測試完成之后，準備讓他做一個該產品的概要設計。然后他花了2個星期的時間，給我們寫出來一個概要設計，說實話，我看到這個概要設計，我就覺得是剛畢業的大學生寫的。版本一的架構設計

2.1系統體系結構系統分為兩層：硬件驅動層、應用層。2.1.1硬件驅動層硬件驅動層包含板載硬件資源正常運行所需的所有驅動程序。1)MCU初始化2)I2C數據存取3)SPI數據讀取4)加速度計初始化5)藍牙模塊啟動6)BC95模塊啟動7)485通訊模塊啟動2.2.2應用層1)Mcu運行模式切換2)震動及傾斜3)數據解析4)開/關鎖5)數據發送6)歷史數據保存

看到版本一的架構設計之后，說實話，我還是第一次見到這樣來寫架構設計的，居然是以序號來寫的，這個讓別人讀起來，特別的別扭。版本二的架構設計

看到版本二的架構設計之后，雖然頗感欣慰，但是想到達到我們所要求的，還要很大的一段距離，該架構設計，主要有以下幾點問題：1.對架構的理解還不是很清晰，既然是做架構設計，那就應該從整體來看，而不是僅僅只是局限于一個模塊，或者功能里面。2.還是每個層次的理解也還不是很清晰，比如講MCU的初始化，歸于硬件驅動層里面。MCU的初始化，嚴格意義上來說，是屬于流程的一部分了，而不是驅動。比如電腦的開啟啟動，把這個歸于硬件的驅動里面，肯定是屬于牛頭不對馬嘴的。3.還有就是各個模塊的啟動，也是不能屬于硬件驅動層的，也都是業務流程的一部分了，都不應該屬于驅動層的一部分。4.還有就是總線數據的讀寫，雖然驅動的作用也就是讀寫，但是數據總線的讀寫不能寫成硬件驅動。5.應用層的系統參數初始化，也還是屬于流程。6.數據的解析和數據的發生，都是屬于通信功能里面的，不應該單獨獨立出來，屬于單個的應用。

二

更改版基本框架圖

（1）架構設計的目的1.應用的代碼邏輯清晰，且避免重復造輪子。2.如果沒有好的架構，移植將會是一件很痛苦的事情，因此一個好的架構設計，方便軟件的移植。3.最大限度地復用。4.高耦合低內聚。（2）設計思路如何把硬件的驅動和一個功能封裝成一個個的模塊，然后可以像小朋友搭積木一個，一個個模塊可以快速的拼接起來，組成一個個不同的模型。我們的嵌入式架構思路也是來源于此，即功能模塊化設計、分層設計。這個設計和WEB開發的MVC模式類似，都是注重分層設計。模塊化設計：將收集到的需求，進行歸類，總結和分析，將這些需求概括為一個個單獨的功能，每一個功能，做成一個單獨的功能模塊。分層設計一句話不好直接表達，其主要體現在一下幾方面：1.功能模塊對外調用的模塊封裝成一個個API，將底層驅動做個API以供功能模塊調用。（各個功能模塊可以獨立編譯（如通信模塊純ANSI C，可在任意平臺復用），或者調用驅動層接口（日志庫模塊調用了驅動讀寫Flash），總而言之，言而總之，封裝出各個功能獨立的可復用的功能模塊。）2.API分為驅動層API和應用層API，而不是所有程序都調用驅動層API。(整個應用中都調用驅動層API會導致應用中驅動調用隨處可見，無法移植和最大限度的復用)總體分 硬件驅動層-->功能模塊層-->業務邏輯層-->應用層總體結構示意框圖：

說明：1.層與層之間不能跨層調用。2.模塊與模塊各自獨立，無依賴關系。3.模塊提供統一的接口供上層調用，模塊的內外接口分明。4.模塊的功能只能增，不能改。5.各個功能模塊層也還可以進行繼續分層，比如接口層、驅動層、硬件層。（3）模塊層次說明

硬件驅動層硬件驅動層包含板載硬件資源正常運行所需的所有驅動程序并提供API給功能模塊調用。

功能模塊層功能模塊層包括實現具體功能的函數，通過調用驅動層API實現相應功能，同時提供可調用的API給業務邏輯層。

業務邏輯層業務邏輯層包括產品整體功能的各個業務流程，通過調用功能模塊層的API實現。

應用層應用層將各個業務邏輯進行整合調用，完成整個產品的功能。（4）優勢如果驅動變動了，或者換不同平臺，只需更改驅動層，應用層不受影響。如果功能模塊變動了，只需升級相應的功能模塊，其他的模塊不受影響，應用層也不受影響。按照這種邏輯設計好之后，主要的工作就是在業務邏輯層。應用層則為程序的總體流程和框架，主要調用業務邏輯層實現不同的功能。