單片機用處這么廣，尤其是 STM32，這么火！如何快速上手學習呢？

“不要去學 STM32”。我不是說 STM32 不好，而是這種為了學習單片機而去學習單片機的思路不對。

你問，如何系統地入門學習 stm32？
這本身就是一個錯誤的問題。假如你會使用 8051 ， 會寫 C 語言，那么 STM32 本身并不需要刻意的學習。

你要考慮的是， 我可以用 STM32 實現什么?
為什么使用 STM32 而不是 8051? 是因為 51 的頻率太低，無法滿足計算需求?是 51 的管腳太少，無法滿足眾多外設的 IO? 是 51 的功耗太大，電池挺不住?是 51 的功能太弱，而你要使用 SPI、I2C、ADC、DMA? 是 51 的內存太小而你要存儲的東西太多?

當你需要使用 STM32 某些功能，而 51 實現不了的時候，那 STM32 自然不需要學習，你會直接去尋找 STM32 某方面的使用方法。比如要用 spi 協議的網卡、要使用串口通信、要使用 rtos 等等 ...

關于寄存器 vs 庫
我的觀點是：當你 debug 的時候寄存器很重要，當你需要理解芯片工作細節的時候寄存器很重要，當你開發的時候寄存器不重要。如果你沒有遇到非直接配置寄存器不可的情況，那么就不要直接面向寄存器層面開發， 因為面向寄存器開發獲得的好處往往抵消不掉這樣做的壞處。面向寄存器開發程序效率高，但是你需要為了提高 0.01%的效率浪費 10 倍、乃至 100 倍的時間。既然 ST 公司已經給你提供了好用的庫，沒有道理要重新造輪子。

那什么時候必須直接控制寄存器?
第一、某一個代碼塊調用非常頻繁。比如你有一個巨大的 for 循環，那么這個 for 循環中的每一步操作都應該被謹慎的優化，優化良好就可以獲得更好的性能。這種情況一般常見于圖像處理相關的代碼中。

第二、庫函數有 bug。這個遇到的概率非常低，但確實存在。不過一般來說如果 mcu 表現出預料之外的行為， 你首先要想的應該是你的代碼寫的有 bug，而不是庫函數有 bug。如果庫函數真的有 bug，你去 google 搜一下，相信你絕對不是第一個踩坑的人。

對于傳統的電子工程師來講，使用庫編程可能會感到有一點虛，感覺沒有腳踏實地的感覺。但如果你寫過 web、寫過服務器端代碼、寫過桌面端代碼的話，你就一定會理解 API、封裝、抽象的意義。

對于這個話題，看看其他老司機筒子們自己的看法：
icecut：
1. 使用 stm32 是因為功能比 avr 好,各種資源比較多 . 所以選 stm32f103，那時候芯片還沒這么多 . 還是用寄存器開發的時代。

2. 后來,103 的開發板越來越多,開始切換成使用官方庫的時代 . 的確大大提高了生產力 . 但是很多人比較保守,不愿意用庫 . 各種理由去讓自己使用寄存器 . 例如:性能差, 有 bug, 代碼量太大, 把控不好 .... 縱然這些困難存在還是讓一些初學者嘗到了甜頭 . 底層不用學的太好也可以開發了 .

3. arm 官方也開始推這種通用庫了。而此時 st 發現一劍走天涯的方法的確有很多弊端,開始了 stmcubemx 的推廣。軟件會根據你的配置和芯片,生成輕量級的代碼 . 代碼量小很多,并且有推薦 freertos,以及閉源的 ui 庫支持,做為一個多年的軟件開發者,發現新的設計的確很好 .
但是,給人的要求會更多,比如自動生成代碼,就要求你寫的代碼在固定位置,這樣才不會被覆蓋 . 如果你想發揮芯片的最大性能,軟件的枷鎖還是有一些的 . 當然,對于這種資深應用,自己也能管理好代碼框架 .

4. st 芯片的遍地開花,軟件上配合 stm32cubeMx 的開發利器,輕松生成一個好用的工程并且開發好合適的代碼 . 大大縮短調試的工作量 . 當然,帶 os 和 no os 的 開發還有很多差距,如果你想用 no os 的代碼,搬過來,直接死路一條 .... 我曾經拿著很高的工資給公司用這種方法,輕松的工作 .

5. 最近在做互聯網,所以,有時候還是手癢癢,還想弄 st 的芯片玩玩 ....

菜鳥同學：
單片機本身沒啥好折騰的，重點還是軟件架構，針對項目設計軟件，深度研究一種單片機，其他單片機都大同小異，大多數菜鳥都把時間荒廢在單片機本身應用上，然后會幾個外設就說的很簡單怎么樣，這個就是為什么現在單片機開發人員混雜的原因，都認為很簡單，但是大部分都是蜻蜓點水，讓其開發個項目試試，簡直慘不忍睹，如果讓其換一個芯片，這貨估計就要折騰一個星期來熟悉芯片，所以大部分看到如此提問的我都不好意思回答。

lxyppc：
剛開始發現一款比較有意思的產品，主控用的是 avr，把里面的代碼反編譯之后就想抄了，仔細想想要是還用 avr 很快也會被別人給抄去，這個時候發現了 stm32 這個片子，還帶 USB，于是乎就把反編譯出來的代碼移植到了 stm32 上，把通信接口由 uart 改成 USB。

江楓漁火：
說句公道話：花一個星期或者更多時間熟悉芯片很正常。每個芯片公司的芯片還是有風格和使用上的差異。實際用一個不曾慣用的芯片的時候，都是對著數據手冊上寄存器寫的。

樓主后面的話說起庫和寄存器開發方式了，恐怕又引起一陣論戰。不過我只是說說自己的感受，先聲明，我沒怎么用 STM32 開發過東西。

我用 ATMEL 的芯片，用寄存器操作方式。我不可能用官方庫。

但我可以將用寄存器寫的功能進行封裝成函數或模塊。

冰零分子：
1. 首先了解下芯片架構，看看這個芯片都能干什么事

2. 然后跟視頻或教程通看一遍，了解下實現一個功能大致需要的步驟

3. 其次選一個項目直接實踐，只要知道大致步驟，庫函數配置網上一搜一大把

做項目的同時會解決各種各樣的問題，這就是提高的過程，這個項目做完基本外設配置過程就熟悉了

4. 最后再做個項目盡量不去參考教程或網上的配置過程自己獨立完成，加深印象。這個過程可以結合寄存器配置了解底層運作原理
總的來說，我的學習過程是先觀其廣再究其深。

弈涯：
剛開始接觸 STM32 是正點原子的 MiniSTM32，那時候在學校有的就是時間，當時就用寄存器將提供的所有例程，自己重新對照著 DataSheet 敲一次，根據自己的想法做一些改變。

從 C 到編程思想再到 STM32 的了解，都有了較大的進步。現在在單位也在做 STM32 的編程，不過都不用寄存器了，但是感覺之前敲的例程還是對現在的工作有了很大的幫助。覺得吧，還是得多動手，基礎的東西還是得自己去完整的過一遍。

Larm1：
1. 剛開始使用寄存器配置時，感覺要看的文檔，花的時間確實比較多；

2. 后來官方退出了固件庫，剛開始使用的時候感覺又不踏實，后來習慣了，省了很多的時間；

3. 現在都是直接找官網的相關功能外設代碼直接測試、調試，不懂得才去看文檔，時間長了覺得對硬件資源都生疏了許多；

4. StmCube 由于沒有帶系統，沒怎么使用過；

5. 以后的路還長著呢 ...

shizaigaole：
和學其他單片機一樣：

1. 買塊開發版，熟悉編譯，下載環境

2. 寫個跑馬燈，自己感受一下

3. 把 STM32 的中斷，尤其是定時中斷搞清楚

4. 作為硬件應用來說，一定還要仔細看看 IO 管叫相關電氣方面的參數。

到這一步就基本入門了。

但是要熟練使用 STM32，還要踏踏實實的把 stm32 的文檔手冊讀一遍。

然后學習編譯器自帶的例程，把這些例程精簡以后移植到自己得開發版上去跑一跑。

其實做幾個模塊后，就基本熟悉了。

以后要用的就再去啃手冊和例程

shizaigaole：
說白了三句話：

1. 熟悉編譯下載環境

2. 啃手冊

3. 研習官方例程

feilusia：
這是我自己的學習路線：

1、51 學習寄存器操作（網上資料大把，不局限誰的資料）

2、stm8 學習寄存器和庫操作（看風馳電子的資料）

3、stm32 學習寄存器和庫操作（看正點原子的資料）

4、CC2541 學習協議棧（看 amo 的資料、看我寫的資料）

5、安卓入門學習（看《第一行代碼》）………………（目前我所處階段）

6、安卓藍牙學習（未知）

ywlzh：
哈哈哈 我路過，也說說吧，

初學 stm32,我也是從 8 位，16 位單片機走過來的，學習的第一步，就是點亮個燈。

有人是只管點亮就行了，有人是會繼續深究為什么會點亮。

目的是一樣的，但有人是走個過場，有人能舉一反三。

審核編輯黃宇