這篇文章分享怎么寫出穩(wěn)定的單片機(jī)代碼。

我對優(yōu)秀代碼的理解，大體分為兩個部分：高效和穩(wěn)定。 兩者都能做到很好的，如果靠自己摸索，沒有刻意去練習(xí)，可能需要花10年，甚至更久。

對于單片機(jī)產(chǎn)品來說，高效可能不是剛需。

高效寫法和低效寫法，在很多功能上看不出區(qū)別，代碼執(zhí)行效率快個納秒、微秒、甚至是毫秒的時間差，對功能本身并無影響。

所以在高效和穩(wěn)定之間，我建議先提升怎么把程序?qū)懛€(wěn)定，再進(jìn)一步優(yōu)化程序效率。

如果當(dāng)下覺得自己寫的代碼比較爛，也沒關(guān)系，先多寫，再多學(xué)習(xí)高手寫的代碼，你就能看出其中的精華。

經(jīng)驗不足的時候，哪怕別人直接給你答案，你也不知道他為什么要這樣做。

我很多代碼思維和技巧，都是學(xué)習(xí)同事的代碼，我看到他們的代碼時，和無際項目特訓(xùn)營老鐵看我們代碼的感覺是一樣的，先是一臉懵逼，有些工作后，接觸項目多了，才領(lǐng)悟其中的精髓。

剛開始我也不能理解他們的代碼，感覺寫的很復(fù)雜，搞不懂明明可以寫的很簡單，為什么要繞一個彎。

不過我把他們的代碼保存起來了。

后面跳槽又做了幾年，有次，領(lǐng)導(dǎo)安排了一個復(fù)雜點的新項目，需要自己獨立從頭到尾去做。

很多功能沒做過，不知道怎么下手，摸著石頭過河，用最笨的辦法，先把功能實現(xiàn)。

后面把代碼組織在一起的時候，又發(fā)現(xiàn)整個邏輯異常混亂和沖突。

舉個簡單的例子，一個LED燈指示設(shè)備聯(lián)網(wǎng)狀態(tài)，未接連上時，每200ms閃一次，連接上wifi時，每400ms閃一次，連接上路由器時，每600ms閃一次，連接上服務(wù)器時，常亮。

固定的閃爍效果，簡單，但要考慮到通用性和擴(kuò)展性，就難很多了。

為什么我要專門給點燈，寫一個程序架構(gòu)？

是因為LED需求太多了，LED大多數(shù)產(chǎn)品都有，而且每個產(chǎn)品LED數(shù)量，需要的閃爍效果都不同，每次重復(fù)去寫，費時費力。

所以我把LED閃爍，設(shè)計成獨立的功能模塊，并考慮到了擴(kuò)展性和移植性。

需要修改LED數(shù)量，直接修改枚舉量就好了，需要增加LED閃爍效果，直接添加一個波形數(shù)組就好了，后續(xù)算法會根據(jù)數(shù)組的值，自動輸出相應(yīng)的波形。

架構(gòu)定好，下次類似產(chǎn)品功能的需求，我改一下，只需要幾分鐘。

所以，程序?qū)懙恼樱皇强创a寫得多漂亮，或者用了什么高級語法，而是看是否精準(zhǔn)解決需求。

除此以外，所有花里胡哨的技巧，都是脫褲子放屁。

代碼穩(wěn)定性，主要體現(xiàn)在一些復(fù)雜的項目上，一些簡單的項目，沒多少功能，硬調(diào)也能調(diào)出來。

所以，我覺得，想把代碼寫穩(wěn)定，最主要的就是程序架構(gòu)的設(shè)計。

如果架構(gòu)設(shè)計不好，會導(dǎo)致代碼難以維護(hù)、容易出錯、功能擴(kuò)展困難、穩(wěn)定性差、調(diào)試?yán)щy、硬件兼容性差等問題。

好的程序架構(gòu)，我覺得核心是要把控兩點：

一、程序"地基"也就是整個項目，所有功能的"管理者"。比如RTOS，就是充當(dāng)這樣的角色。

很多復(fù)雜的單片機(jī)項目，都會上RTOS，就是保證地基是穩(wěn)定，降低對工程師的技能要求。

寫一個系統(tǒng)，和移植一個系統(tǒng)用，完全不是一個難度級別。

不過，我還是比較喜歡用"裸機(jī)"寫程序，然后采用自己設(shè)計的輕量任務(wù)調(diào)度系統(tǒng)。

這是一個簡單的輪詢式任務(wù)調(diào)度系統(tǒng)，通過一個定時器中斷來觸發(fā)任務(wù)調(diào)度。相對RTOS來說，有以下優(yōu)勢：

①簡單，資源占用少不需要復(fù)雜的任務(wù)管理數(shù)據(jù)結(jié)構(gòu)和調(diào)度算法，因此占用的內(nèi)存和CPU資源較少，特別適合資源受限的單片機(jī)，之前這個架構(gòu)多次用于51單片機(jī)的項目。

②能完全掌控代碼都是自己寫的，相對移植RTOS來說，更能掌控，減少由于對系統(tǒng)不熟，給產(chǎn)品埋雷的風(fēng)險。任務(wù)也是按順序執(zhí)行的，沒有復(fù)雜的任務(wù)切換，調(diào)試時更容易跟蹤和分析問題。 ③任務(wù)分離通過任務(wù)創(chuàng)建函數(shù)OS_CreatTask，將不同的功能分配給不同的任務(wù)。這種分離確保了每個任務(wù)只關(guān)注一件事情，提高了代碼的可讀性和可維護(hù)性。

④靈活性創(chuàng)建任務(wù)時，可以為每個任務(wù)分配不同執(zhí)行頻率，從而調(diào)整任務(wù)執(zhí)行順序，可以很靈活地控制任務(wù)執(zhí)行，也非常適合周期性的任務(wù)。

⑤減少CPU占用，響應(yīng)更快雖然在這個架構(gòu)中沒有明確的任務(wù)優(yōu)先級，但可以通過調(diào)整任務(wù)的執(zhí)行頻率或順序，來間接實現(xiàn)優(yōu)先級控制。

傳統(tǒng)while(1)死循環(huán)的用法，CPU一直在忙碌地執(zhí)行某個代碼塊，而輪詢式架構(gòu)可以讓CPU在沒有任務(wù)執(zhí)行時，處于空閑狀態(tài)，一旦任務(wù)準(zhǔn)備好執(zhí)行，它可以立即開始運行，減少響應(yīng)時間。 不過有一點，需要人為控制每個任務(wù)的代碼效率，盡量不要有延時高的代碼。 ⑤擴(kuò)展性強(qiáng)雖然架構(gòu)簡單，但通過增加任務(wù)和調(diào)整調(diào)度邏輯，系統(tǒng)仍然可以擴(kuò)展以支持更多的功能，比如增加現(xiàn)場切換功能和任務(wù)優(yōu)先級管理，即是最精簡的RTOS系統(tǒng)。 這種輪詢式任務(wù)調(diào)度系統(tǒng)，雖然不支持真正的并發(fā)執(zhí)行，但以更簡單，高效的方式來管理多個任務(wù)，對于大多數(shù)的單片機(jī)項目來說，其實也夠了。至少我還沒碰到過，非要上RTOS才能完成的產(chǎn)品。

這個架構(gòu)也有配套的開源視頻，是我2018年錄著玩的，不過代碼已申請版權(quán)，非學(xué)員不能直接用于自己項目，可以學(xué)習(xí)這種編程思維，要的找我安排。

二、功能模塊化如果是項目功能比較多，一定要采用模塊化的方式，以便于后期的代碼維護(hù)和移植。 拿我們無際特訓(xùn)營項目6的代碼舉例，創(chuàng)建了3個任務(wù)，分別管理硬件層、中間層、應(yīng)用層的功能。

1.硬件層主要是單片機(jī)外設(shè)，以及一些外圍芯片的驅(qū)動程序，比如定時器、LED、語音輸出、按鍵、串口、ADC、EEPROM。

然后不同的硬件驅(qū)動程序也是相互獨立的。

2.中間層主要是一些協(xié)議的解析，比如mqtt、lora、4G等，還有就是一些硬件層的應(yīng)用程序，比如屏顯示圖案，電池電量檢測邏輯，外電檢測邏輯等。

不同的功能程序也是相互獨立的。

3.應(yīng)用層就是具體的產(chǎn)品邏輯功能實現(xiàn)代碼，比如菜單系統(tǒng)，防盜報警模式邏輯等等。

我們在做功能的時候，也要有架構(gòu)的思維，需要考慮到后續(xù)功能的擴(kuò)展和移植。

比如我們做菜單的時候，會考慮到后期如果項目需要增加或刪減界面，怎么設(shè)計比較方便靈活。

我們目前的做法是通過結(jié)構(gòu)體數(shù)組來管理每個界面，然后通過雙向鏈表讓各界面建立聯(lián)系。

類似的還有很多，比如說LED，按鍵這種，基本也是每個產(chǎn)品的剛需。

三、怎么去鍛煉架構(gòu)思維和能力？一般的工程師，會在工作了3,4年左右，才能意識到程序架構(gòu)的必要性，也取決于你什么時候能有機(jī)會獨立完成復(fù)雜的項目，這個時候你會發(fā)現(xiàn)，原來的知識體系不夠用。

心態(tài)上不用太著急和焦慮，按照正確的方向努力，很快就能具備架構(gòu)設(shè)計能力。

一般流程是這樣的。1.先實現(xiàn)功能先不要考慮架構(gòu)，先把功能實現(xiàn)出來，再從功能里面找規(guī)律。

比如一個按鍵檢測代碼，和10個按鍵，其實也就是加個for循環(huán)，代碼就能復(fù)用。

比如LED燈的特效，其本質(zhì)就是輸出的高低電平波形持續(xù)的時間不一樣，我們是否能用一個數(shù)組來存儲波形數(shù)據(jù)，通過定時器配合小算法來輸出波形呢？ 這些代碼，都是要一步步迭代的，可能修改10次，就比較完美了，不要要求一寫就接近完美，容易自閉。 還有就是多接觸優(yōu)秀的工程師和項目，沒條件的可以看看STM32固件庫代碼，看看藍(lán)牙協(xié)議棧，看看RTOS，這些都是開源的產(chǎn)品級代碼。