【編程之美】論嵌入式架構(gòu)的重要性
嵌入式架構(gòu)有多重要?
要做到嵌入式應(yīng)用的代碼邏輯清晰,
且避免重復(fù)的造輪子,
沒(méi)有好的應(yīng)用架構(gòu)怎么行?
如果沒(méi)有好的架構(gòu),
移植將會(huì)是一件很痛苦的事情。
如果沒(méi)有好的架構(gòu),
復(fù)用是最大的難題,
沒(méi)法更大限度的復(fù)用原有的代碼。
如果沒(méi)有好的架構(gòu),
一旦驅(qū)動(dòng)改了,
所有的地方都要改,
費(fèi)時(shí)費(fèi)力且很容易出錯(cuò)。
如果沒(méi)有好的架構(gòu),
應(yīng)用層中穿插著硬件驅(qū)動(dòng)層的代碼,
看著會(huì)是一片混亂,
邏輯不清,
代碼維護(hù)起來(lái)會(huì)很困難。
01
嵌入式系統(tǒng)的基本架構(gòu)
硬件架構(gòu)
軟件架構(gòu)
大多數(shù)人參與的是 嵌入式軟件設(shè)計(jì) ,更多的是接觸的是上層軟件系統(tǒng)部分,可以分為兩大類型嵌入式軟件應(yīng)用工程師以及嵌入式驅(qū)動(dòng)工程師。
前者主要負(fù)責(zé) linux APP 設(shè)計(jì),負(fù)責(zé)應(yīng)用層業(yè)務(wù)開(kāi)發(fā),主要具備如下幾個(gè)專業(yè)技能:
2.熟悉多線程管理、進(jìn)程間通信、文件IO操作
3.了解基本的shell編程
4.熟悉數(shù)據(jù)庫(kù)操作
5.了解QT或者Android
后者負(fù)責(zé)驅(qū)動(dòng)開(kāi)發(fā),更加涉及底層。
2.熟悉Linux驅(qū)動(dòng)模型
3.熟悉ARM架構(gòu)
4.熟悉基本的電路原理
02
嵌入式程序設(shè)計(jì)思路
如果功能模塊變動(dòng)了,只需升級(jí)功能功能模塊,其他的模塊不受影響,應(yīng)用層也不受影響。
休息一下,推薦一篇文章《怎樣混好嵌入式/MCU/ARM/DSP這一行?》
03
一個(gè)引以為戒的實(shí)例
一、錯(cuò)誤的示范
版本一的架構(gòu)設(shè)計(jì)
2.1系統(tǒng)體系結(jié)構(gòu)
系統(tǒng)分為兩層:硬件驅(qū)動(dòng)層、應(yīng)用層。
2.1.1硬件驅(qū)動(dòng)層
硬件驅(qū)動(dòng)層包含板載硬件資源正常運(yùn)行所需的所有驅(qū)動(dòng)程序。
1)MCU初始化
2)I2C數(shù)據(jù)存取
3)SPI數(shù)據(jù)讀取
4)加速度計(jì)初始化
5)藍(lán)牙模塊啟動(dòng)
6)BC95模塊啟動(dòng)
7)485通訊模塊啟動(dòng)
2.2.2應(yīng)用層
1)Mcu運(yùn)行模式切換
2)震動(dòng)及傾斜
3)數(shù)據(jù)解析
4)開(kāi)/關(guān)鎖
5)數(shù)據(jù)發(fā)送
6)歷史數(shù)據(jù)保存
版本二的架構(gòu)設(shè)計(jì)
1.對(duì)架構(gòu)的理解還不是很清晰,既然是做架構(gòu)設(shè)計(jì),那就應(yīng)該從整體來(lái)看,而不是僅僅只是局限于一個(gè)模塊,或者功能里面。
2.還是每個(gè)層次的理解也還不是很清晰,比如講MCU的初始化,歸于硬件驅(qū)動(dòng)層里面。MCU的初始化,嚴(yán)格意義上來(lái)說(shuō),是屬于流程的一部分了,而不是驅(qū)動(dòng)。比如電腦的開(kāi)啟啟動(dòng),把這個(gè)歸于硬件的驅(qū)動(dòng)里面,肯定是屬于牛頭不對(duì)馬嘴的。
3.還有就是各個(gè)模塊的啟動(dòng),也是不能屬于硬件驅(qū)動(dòng)層的,也都是業(yè)務(wù)流程的一部分了,都不應(yīng)該屬于驅(qū)動(dòng)層的一部分。
4.還有就是總線數(shù)據(jù)的讀寫,雖然驅(qū)動(dòng)的作用也就是讀寫,但是數(shù)據(jù)總線的讀寫不能寫成硬件驅(qū)動(dòng)。
5.應(yīng)用層的系統(tǒng)參數(shù)初始化,也還是屬于流程。
6.數(shù)據(jù)的解析和數(shù)據(jù)的發(fā)生,都是屬于通信功能里面的,不應(yīng)該單獨(dú)獨(dú)立出來(lái),屬于單個(gè)的應(yīng)用。
1.應(yīng)用的代碼邏輯清晰,且避免重復(fù)造輪子。
2.如果沒(méi)有好的架構(gòu),移植將會(huì)是一件很痛苦的事情,因此一個(gè)好的架構(gòu)設(shè)計(jì),方便軟件的移植。
3.最大限度地復(fù)用。
4.高內(nèi)聚低耦合。
(2)設(shè)計(jì)思路
如何把硬件的驅(qū)動(dòng)和一個(gè)功能封裝成一個(gè)個(gè)的模塊,然后可以像小朋友搭積木一個(gè),一個(gè)個(gè)模塊可以快速的拼接起來(lái),組成一個(gè)個(gè)不同的模型。
我們的嵌入式架構(gòu)思路也是來(lái)源于此,即功能模塊化設(shè)計(jì)、分層設(shè)計(jì)。
這個(gè)設(shè)計(jì)和WEB開(kāi)發(fā)的MVC模式類似,都是注重分層設(shè)計(jì)。
模塊化設(shè)計(jì):將收集到的需求,進(jìn)行歸類,總結(jié)和分析,將這些需求概括為一個(gè)個(gè)單獨(dú)的功能,每一個(gè)功能,做成一個(gè)單獨(dú)的功能模塊。
分層設(shè)計(jì)一句話不好直接表達(dá),其主要體現(xiàn)在一下幾方面:
1.功能模塊對(duì)外調(diào)用的模塊封裝成一個(gè)個(gè)API,將底層驅(qū)動(dòng)做個(gè)API以供功能模塊調(diào)用。(各個(gè)功能模塊可以獨(dú)立編譯(如通信模塊純ANSI C,可在任意平臺(tái)復(fù)用),或者調(diào)用驅(qū)動(dòng)層接口(日志庫(kù)模塊調(diào)用了驅(qū)動(dòng)讀寫Flash),總而言之,言而總之,封裝出各個(gè)功能獨(dú)立的可復(fù)用的功能模塊。)
2.API分為驅(qū)動(dòng)層API和應(yīng)用層API,而不是所有程序都調(diào)用驅(qū)動(dòng)層API。(整個(gè)應(yīng)用中都調(diào)用驅(qū)動(dòng)層API會(huì)導(dǎo)致應(yīng)用中驅(qū)動(dòng)調(diào)用隨處可見(jiàn),無(wú)法移植和最大限度的復(fù)用)
總體分 硬件驅(qū)動(dòng)層-->功能模塊層-->業(yè)務(wù)邏輯層-->應(yīng)用層
總體結(jié)構(gòu)示意框圖:
1.層與層之間不能跨層調(diào)用。
2.模塊與模塊各自獨(dú)立,無(wú)依賴關(guān)系。
3.模塊提供統(tǒng)一的接口供上層調(diào)用,模塊的內(nèi)外接口分明。
4.模塊的功能只能增,不能改。
5.各個(gè)功能模塊層也還可以進(jìn)行繼續(xù)分層,比如接口層、驅(qū)動(dòng)層、硬件層。
(3)模塊層次說(shuō)明
硬件驅(qū)動(dòng)層包含板載硬件資源正常運(yùn)行所需的所有驅(qū)動(dòng)程序并提供API給功能模塊調(diào)用。
功能模塊層包括實(shí)現(xiàn)具體功能的函數(shù),通過(guò)調(diào)用驅(qū)動(dòng)層API實(shí)現(xiàn)相應(yīng)功能,同時(shí)提供可調(diào)用的API給業(yè)務(wù)邏輯層。
業(yè)務(wù)邏輯層包括產(chǎn)品整體功能的各個(gè)業(yè)務(wù)流程,通過(guò)調(diào)用功能模塊層的API實(shí)現(xiàn)。
應(yīng)用層將各個(gè)業(yè)務(wù)邏輯進(jìn)行整合調(diào)用,完成整個(gè)產(chǎn)品的功能。
(4)優(yōu)勢(shì)
如果驅(qū)動(dòng)變動(dòng)了,或者換不同平臺(tái),只需更改驅(qū)動(dòng)層,應(yīng)用層不受影響。
如果功能模塊變動(dòng)了,只需升級(jí)相應(yīng)的功能模塊,其他的模塊不受影響,應(yīng)用層也不受影響。
按照這種邏輯設(shè)計(jì)好之后,主要的工作就是在業(yè)務(wù)邏輯層。應(yīng)用層則為程序的總體流程和框架,主要調(diào)用業(yè)務(wù)邏輯層實(shí)現(xiàn)不同的功能。
04
給嵌入式代碼也來(lái)個(gè)分層
一、遇到的問(wèn)題
代碼結(jié)構(gòu)也會(huì)有缺陷:
(1)開(kāi)發(fā)效率低:每次使用片內(nèi)的某一資源(例如定時(shí)器等),筆者都要去查詢CC2430中文手冊(cè),比較eggache~
正是由于以上問(wèn)題,筆者決定暫停了該系列博文的續(xù)寫,抽出時(shí)間來(lái)思考一下解決辦法。
二、由網(wǎng)站分層引起的思考
筆者在學(xué)習(xí)嵌入式編程之前,曾有過(guò) ASP.NET 網(wǎng)站開(kāi)發(fā)經(jīng)驗(yàn),對(duì)其分層理論也有所實(shí)踐,下面簡(jiǎn)單提一下:
一般的有一定復(fù)雜度的網(wǎng)站可分為以下三層:
總之,分層以后,大大提高了代碼的復(fù)用性與擴(kuò)展性。
那么在嵌入式開(kāi)發(fā)中,能否也利用分層的思想,來(lái)提高開(kāi)發(fā)效率,增強(qiáng)其可維護(hù)性與可擴(kuò)展性呢?下面,是一些筆者思考后的淺見(jiàn)。
三、嵌入式項(xiàng)目也來(lái)分個(gè)層
當(dāng)然不能照搬ASP.NET 的具體分層思想,具體問(wèn)題得具體分析嘛~
首先,嵌入式開(kāi)發(fā)的核心就是芯片,它提供固定的片內(nèi)資源共開(kāi)發(fā)者使用。而且它具有一個(gè)很重要的特點(diǎn)就是,不隨項(xiàng)目的需求變動(dòng)而變動(dòng)。所以應(yīng)將其作為最底層,為上層提供基礎(chǔ)支持。我們將其命名為 硬件抽象層(Hardware Abstract Layer)。
芯片有了當(dāng)然還不夠,通常我們會(huì)在片外擴(kuò)展一些功能模塊來(lái)滿足具體的項(xiàng)目需求,例如:傳感器、鍵盤、LCD屏等。這一層的特點(diǎn)是,隨項(xiàng)目的變動(dòng)而以模塊為單位動(dòng)態(tài)增減。這一層的運(yùn)作需要芯片內(nèi)部資源的支持,所以應(yīng)處于硬件抽象層之上,并為上層調(diào)用。我們將其命名為 功能模塊層(Functional Module Layer)。
OK,現(xiàn)在原材料都準(zhǔn)備齊了:芯片+擴(kuò)展模塊,接下來(lái)就要開(kāi)始真正的加工了:我們需要靈活調(diào)用之前兩層所提供的接口,實(shí)現(xiàn)具體的項(xiàng)目需求。我們將其命名為應(yīng)用程序?qū)樱ˋpplication Layer)。
圖文:
(1)硬件抽象層(HAL)
實(shí)現(xiàn)對(duì)片內(nèi)資源 (如定時(shí)器、ADC、中斷、I/O等) 的通用配置,隱藏具體的SFR操作細(xì)節(jié),為上層提供簡(jiǎn)單清晰的調(diào)用接口。
嵌入式開(kāi)發(fā)的核心就是芯片,它提供固定的片內(nèi)資源(常用的有I/O,ISR,TIMER等,稍微好點(diǎn)的還有ADC,SPI等硬件資源,不需要芯片外圍ADC采集芯片或模擬SPI)共開(kāi)發(fā)者使用。而且它具有一個(gè)很重要的特點(diǎn)就是,不隨項(xiàng)目的新增需求變動(dòng)而變動(dòng)。所以應(yīng)將其作為最底層,為上層提供基礎(chǔ)支持。
(2)硬件驅(qū)動(dòng)層(HDL)
嵌入式開(kāi)發(fā)基本都會(huì)使用片外資源,如AT24C02,W25Q128等常見(jiàn)的外圍EEPROM芯片,需要SPI通信(硬件SPI或I/O模擬的SPI)發(fā)送相應(yīng)指令驅(qū)動(dòng)該芯片,實(shí)現(xiàn)該芯片能正常工作。因此驅(qū)動(dòng)這部分的API函數(shù)實(shí)現(xiàn)程序即為硬件驅(qū)動(dòng)層。即使換了MCU,也只需將調(diào)用過(guò)硬件抽象層的API函數(shù)替換即可。
(3)功能模塊層(FML)
通過(guò)調(diào)用 HAL,實(shí)現(xiàn)項(xiàng)目中所涉及到的各片外功能模塊,隱藏具體的模塊操作細(xì)節(jié),并為上層提供簡(jiǎn)單清晰的調(diào)用接口。
硬件抽象層和驅(qū)動(dòng)層主要就是為功能模塊層提供的,實(shí)現(xiàn)該項(xiàng)目需要的功能,比如KEY、LED和EEPROM等功能,其中LEY、LED基本調(diào)用硬件抽象層的API函數(shù)(更復(fù)雜的可能通過(guò)片外芯片獲取/控制等,因此可能也需要使用硬件驅(qū)動(dòng)層),EEPROM調(diào)用硬件驅(qū)動(dòng)層的API函數(shù),即使EEPROM芯片更換(AT24C02或W25Q128等),也不影響EEPROM之前編寫含的功能代碼程序(前提是AT24C02,W25Q128提供的API函數(shù)提供的是統(tǒng)一標(biāo)準(zhǔn))。
(4)應(yīng)用程序?qū)樱ˋPL)
通過(guò)調(diào)用 HAL 與 FML,實(shí)現(xiàn)最終的應(yīng)用功能。
負(fù)責(zé)的就是功能模塊的使用和之間的邏輯關(guān)系處理等等,比如用戶交互界面應(yīng)用程序可能需要KEY、LED、LCD等。
四、硬件抽象層和硬件驅(qū)動(dòng)層的主要區(qū)別
硬件抽象層使用的芯片內(nèi)本身的資源(芯片手冊(cè)都有介紹),而硬件驅(qū)動(dòng)層使用的是芯片本身不存在的資源,而且需要編寫相應(yīng)代碼才能實(shí)現(xiàn)的資源。
比如正點(diǎn)原子STM32中CAN使用的TJA1050芯片,CAN屬于STM32的片內(nèi)資源,TJA1050屬于片外資源,但由于TJA1050不需要額外的代碼就能通過(guò)STM32中CAN本身提供API函數(shù)正常 工作;因此可以認(rèn)為TJA1050不屬于硬件驅(qū)動(dòng)層,而若使用TJA1041,則需要編寫額外代碼才能使正常工作才能使STM32中CAN本身提供API函數(shù)正常工作,因此可以將TJA1041歸為硬件驅(qū)動(dòng)層。
若不要分這么細(xì),可以將硬件抽象層和硬件驅(qū)動(dòng)層統(tǒng)一歸為硬件抽象層。
五、功能模塊層和硬件抽象層、硬件驅(qū)動(dòng)層的主要區(qū)別
功能模塊層是按照項(xiàng)目需求提取出來(lái)的功能,需要硬件抽象層和硬件驅(qū)動(dòng)層的硬件支持才能實(shí)現(xiàn),功能模塊層根據(jù)項(xiàng)目的功能需求改變而改變,而硬件抽象層和硬件驅(qū)動(dòng)層則是項(xiàng)目需求書中的功耗等硬件相關(guān)的需求變動(dòng)而改變,當(dāng)然,若子功能的增加而硬件不支持,則也需更換硬件驅(qū)動(dòng)。
比如項(xiàng)目中的數(shù)據(jù)儲(chǔ)存功能,硬件支持有AT24C02、W25Q128和芯片本身的FLASH,都可以支持?jǐn)?shù)據(jù)儲(chǔ)存功能,即使后期因?yàn)楣幕蚬?jié)約成本等問(wèn)題,硬件的更換也不影響數(shù)據(jù)儲(chǔ)存功能的實(shí)現(xiàn)(前提規(guī)劃好標(biāo)準(zhǔn)規(guī)范的API函數(shù)定義)且避免了重寫該功能代碼所帶來(lái)的各種問(wèn)題,保證了該功能的穩(wěn)定性。
分層結(jié)構(gòu)示意圖
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問(wèn)題,請(qǐng)聯(lián)系我們,謝謝!