不要去學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、封裝、抽象的意義。