本著授人以漁的原則，既提供我一直在用的程序架構，也講程序架構的設計思路。

如果本文內容，你都能領悟并做到，不管項目多復雜，都將游刃有余。

我研發的那幾年，接觸大多數工程師，都沒有程序架構的概念，基本一個while死循環干到底。

模塊之間也沒有封裝好，導致代碼寫好以后，擴展性和維護性太差，類似的功能代碼，也很難移植到新項目去復用。

早期我也是這樣寫的，反正實現功能就行了，代碼好不好，功能上又看不出區別。

不過，等你接觸到復雜的項目時，這招就行不通了，沒設計好程序架構，根本做不穩定。

我意識到這個問題，是碰到兩種需求的時候：

1.是做一個基于STM32的網關項目，項目做完以后，客戶老是要改功能，客戶不懂技術，在客戶眼里，覺得改一個LED閃爍效果很簡單，但對于程序架構沒設計好的工程師來說，就是一個噩夢，比如每隔5秒快閃2次這種惡心的需求，搞不好很多代碼都要重新組織。

我經常會被這種問題搞到頭痛，特別是客戶又催得急的時候，經常加班加到焦頭爛耳，越急又越搞不出來。

2.我做過的很多項目，其實很多功能都有重復的，比如很多產品都有LED、都有按鍵、都有掉電參數存儲、都有串口協議解析等等。

但是程序架構沒寫好，導致想移植代碼，過來新項目復用時，不太好改，比如老項目才1個LED，新項目有6個LED，類似的還有按鍵等等。

后面為了有更多的時間摸魚，我開始思考，怎么把程序寫得，改起功能來很方便，代碼復用性又很強那種，當時還不知道這個叫程序架構設計。

程序架構，我覺得是一個系統的學問，貫穿著整個項目，而不是具體某些細節。

就是各種功能模塊，比如LED特效功能，按鍵檢測功能，菜單功能，系統參數存儲功能、語音功能、OTA升級功能等等。

這些功能模塊的設計，我通常是采用硬件驅動代碼和功能邏輯代碼分離的方式，用大白話來說，就是一個功能模塊，我可能會分2個.c文件來寫，硬件驅動代碼我以hal_xxx.c命名，功能邏輯代碼我以mt_xxx.c命名。

硬件驅動代碼主要是和單片機外設的配置代碼，比如設置GPIO、Timer、串口、SPI這些，然后提供硬件接口給mt_xxx.c調用。

拿無際項目特訓營的項目6來舉例，這個項目可以實現遠程控制，因為加了WiFi和4G模塊。

如果你接觸過類似項目，單片機和云平臺之間，其實還有個串口通訊協議的，類似于下圖這種。

按照我的思維，我會這樣去設計程序：

單片機外設驅動的配置、串口發送數據、接收數據代碼，我都放在hal_uart.c里。

串口協議數據發送和解析的代碼，我會放在mt_protocol.c文件里。

這樣就能實現硬件驅動代碼和功能邏輯代碼徹底分離。

那這樣的好處是什么？

1.萬一要換單片機了，如果通訊協議不變的情況下，mt_protocol.c文件代碼可以不用改，只要改hal_uart.c硬件驅動程序，就能對接起來。

2.如果通訊協議格式變了，單片機不變，那只需要改mt_protocol.c文件代碼就可以了。

3.調試方便，比如mt_protocol.c的功能，可以在PC上搭建一個開發環境先調試好，再對接硬件驅動接口，對于復雜的功能，這招還是很有用的，畢竟keil仿真調試沒那么方便靈活。

這種設計，就是一種架構思維，解決了代碼擴展性和移植性的問題。

如果每個功能模塊都采用這種思維去設計，最終從整體看，你的程序架構就非常好了，就像組裝汽車一樣靈活了。

所以，要設計好程序架構，真的不是靠一個課程能搞定的，需要完整地做幾個復雜的項目，并且有資深工程師的思路和代碼，可以參考和借鑒，這樣才能高效，系統地掌握。

每個功能模塊都設計好以后，最后還需要有一個協調者。

類似于人的大腦，去協調手、腳、眼睛、耳朵、嘴巴。

這個大腦，一般就是程序的"地基"，類似于RTOS，就是"協調者"身份，負責調度協調整個項目的各個功能模塊。

RTOS本質也是一種程序架構，但是我很少用，因為它的處境，其實很尷尬。

沒那么復雜的項目，上RTOS并沒有優勢，反而為后期調試帶來不必要的麻煩，如果對系統不熟悉，就像埋了一個定時炸彈，可能會跑一段時間后死機的現象。

復雜的項目，有些直接上Linux了，現在很多***，成本也能做得很低。

所以，現在rtos的應用，我覺得主要集中在中等復雜的項目，要求實時性很高，同時工程師，又不具備設計程序架構的能力時。

不過，至今為止，我基本是用自己設計的架構去替代RTOS，目前大多數產品都夠用。

這個架構，我也錄了套系統的教程，粉絲可以找我拿去參考學習。

寫了3個多小時，腦子和手都麻了(我的意思是，可以開始點贊了^ ^)

編輯：黃飛

?