庫函式，一般都是學習的入門首選，因為官方製作好的東西，只要拿來用，基本上問題是不大的，而且學習的效率和進度也會大大提高，對於學習和理解32是個很不錯的方式。它的優勢體現在，對於公司來說，可以在一定的時間下縮短產品的研發週期，這點也是很多公司所青睞的，從提出想法到完成測試再到部署市場，短的研發週期可以使公司迅速立足市場，達到效益的最大化。對於個人來說，在比賽和完成專案中是比較有優勢的，畢竟能不能做的出來很關鍵，不用太過於注意底層實現的細節。暫存器，是那些喜歡瞭解細節和想要弄清楚整個系統是如何執行起來的，以及底層的實現原理的人所青睞的。具有挑戰性，能夠更加深入地學習32，並且採用這種學習的人的能力是很強的，但是需要花費比較久的時間。資訊化的時代，技術的變化之快，暫存器的學習方式和使用是比較吃力的。但是如果有興趣為何不嘗試一下嗎？最後個人認為，庫函式開發才是比較好的選擇！

當然是庫函式好。現在很多人學微控制器都是從51微控制器學起，而51微控制器編寫程式就是對其暫存器進行讀寫操作。為什麼51微控制器可以用暫存器的方法進行程式設計呢？是因為其簡單，對暫存器操作方便，而且效率高。於是，很多小夥伴從51微控制器進階到stm32微控制器時，都會有一種想法，那就是看它的暫存器程式設計，可一看卻傻眼了，stm32微控制器的暫存器很多，而且操作起來還很麻煩，於是他們掙扎了一段時間後就會發現庫函式這個好東西，並且越深入瞭解庫函式，就會發現其實對庫函式操作也是對暫存器操作，只不過庫函式把對暫存器的讀寫都寫成了一個個函式的形式，大大增加了程式碼編寫的效率。我們再反過來看51微控制器，你也會發現，對其暫存器的操作自己也可以定義成一個個函式，方便自己移植程式碼，只不過這種函式是自定義的，不像stm32的那樣，有統一的官方庫函式手冊。

不涉及核心的程式碼建議用庫函式，庫函式程式碼的可讀性寫得不錯，每個暫存器的設定也比較完整，但要想把效率和效能發揮出來，需要自己寫，庫函式只有一些外設驅動，比如記憶體的訪問模式這些介面是沒有的

我玩stm32有三四年了，但是我並沒有用暫存器寫過程式碼。

不是說暫存器不好，上面幾位我不太清楚他們玩過沒有，我是的的確確玩了很久了。所以就來回答一下。

如果你覺得你的能力足夠勝任stm32的暫存器，那用暫存器最好，如果你看了手冊以後並不能用的起來，那就用庫函式吧。

暫存器比庫函式效率高很多。

如今stm32有三種庫，最早是標準庫，然後是hal庫，後來hal可能效率太低，官方整出來個LL庫。

速度最快的要數LL庫，標準庫次之。最後是HAL。

但是，我建議是學習HAL庫。

有人問了，這貨最慢為啥學這個。很簡單，官方主推。

官方弄出來個工具叫做STM32cubeMx，這個幾乎都是hal庫，而且一鍵生成程式碼，開發週期大大縮短。而且，最重要的，在一些執行效率需求比較高的地方可以選擇使用LL庫。這都是工具上自帶的。

細心的同學會發現，hal庫基本上過段時間就更新一次，更新頻率非常快，這是官方主推的，所以官方也維護的比較積極。當然，這個東西bug還是比較多。現階段已經比較穩定了。

還有個缺點，選擇功能比較多的，比如FATFS FreeRTOS STEMWIN等都加上，編譯速度非常慢。弄個程式一大半時間都在編譯中。。。

建議要配一個桌上型電腦再玩這麼多功能咯。

這個問題從兩方面來說：如果希望快速開發出來專案的話，用庫函式開發；如果希望學精、學透微控制器原理的話，用暫存器開發。

一、從開發時間快慢來說，用庫函式

現在公司開發一個專案的話，都會對時間進度有很高的要求，一般都會要求快速高效的把產品做出來，而不管你用那種方式，只要保證產品的質量就行。在這種情況下，就必須找一種能夠快速開發的途徑，而庫函式正是基於這種原因建立的。晶片公司為了幫助產品工程師降低開發難度、加快開發進度，推出了各種庫函式，這些庫函式都是由專業程式設計人員編寫的，無論從程式碼的穩定性、規範性、正確性方面來說，都是經過晶片廠家反覆驗證的，完全可以直接拿來就用。

當然，用庫函式有一定的缺陷，例如會導致程式碼量增大，影響程式執行速度等，但是現在stm32微控制器的程式空間一般都足夠大，並且每一系列裡面都有pin-to-pin的型號可以互換，如果程式空間不夠，直接替換另一個管腳相容的，程式空間更大的即可，程式直接移植過來，幾乎不用修改。

二、從原理性學習來說，用暫存器

對於想要學習微控制器的工作原理，想真正弄清楚stm32的內部結構，工作過程，底層配置這些功能的人員來說，當然是選用暫存器來開發了。

用暫存器開發，可以直接接觸到最底層的，並且用暫存器可以減少程式碼量，提高程式執行速度。

肯定是庫函式啊，先不說開發效率，單單是從程式碼的可讀性就必須庫函式！！！我們公司早期的程式碼清一色的暫存器還帶位操作，上萬行的程式碼，維護起來那叫一個蛋疼，經常看程式碼看著看著就要去翻暫存器手冊……影響效率不說還影響心情……

學習使用微控制器3年了，接觸STM32也有1年多了，最近做了一個專案，就是用暫存器寫的，用keil開發，暫存器操作也是非常方便，只要寫程式碼時候別直接寫數值，而是用標頭檔案裡的定義變數代替，比如APB2ENR=APB2ENR_GPIOA+APB2ENR_GPIOB;我覺得這樣去寫程式碼，不論是程式碼數量和可讀性都還是很好的。

但實際上，這兩種都有它的實用範圍，

我先簡單說下這兩個方案，大家都知道的特點：

韌體庫，優點是，前期開發簡單，容易較快實現專案所需要功能。缺點，程式碼量大。精細化功能實現。

暫存器，前期開發複雜，前期除錯時間對比韌體庫。

就我個人而言，我目前主要使用暫存器，當時有一個專案，在做微控制器選型時候。採集高頻率的方波，誤差要求正負3，使用韌體庫，編譯時間很長，誤差只能說在正負3 ，4的樣子。

後面在真正上專案的時候，發現編譯下來的執行檔案很大，超出了128k，升級同系列256k的stm32，

又因為成本控制，試想下，每個晶片差幾毛錢，每年一百多萬臺的銷售量，就等於差了好幾十萬塊錢，沒辦法，就最佳化程式碼，使用暫存器，終於最終編譯下來的code在100k左右，而且發現採集零度在正負2左右，精度也提升了，皆大歡喜。

上面我說不是說韌體庫不好，畢竟我現在在有些部分也是呼叫別人寫好的程式碼，比如usb部分，還有fatfs等，自己寫太麻煩了

整體來說我是暫存器為主，韌體庫為輔，兩者都有用。在除錯分析程式碼時候也得心應手。

如果對於成本不是很敏感，功能要求不非常精細，都是可以選用韌體庫的。各個工程師也各有喜好習慣。

以上是根據自身的情況來表述，難免偏頗，望見諒。

我學微控制器已經已經四年了，用的一直是標準庫函式。

庫函式和寄存操作到底哪個好，這個不好說，只能說根據個人情況和應用場合吧。比如說我，雖然說我一直用的是標準庫函式，但是我也不只是用標準庫，偶爾在需要的時候會用暫存器操作，因為暫存器操作的效率更高。

庫函式和暫存器操作的區別可能和 C 語言與組合語言的區別差不多吧，都是跟效率有關，但有時候效率並不是唯一指標。

我們都知道 C 語言的效率要比彙編低，但是現在絕大多數嵌入式開發人員用的還是 C 語言！為什麼，因為它簡單易學，容易跨平臺，移植性好，這是很大的優勢，而彙編就不同了，它針對的是某一款核心進行開發，比如51組合語言、ARM組合語言，一旦核心變了，如果你的程式碼採用純彙編寫的程式碼，那幾乎所有的程式碼都不適用了。但是使用 C 語言編寫程式碼就不同，你在 51 微控制器寫的程式碼也能在 STM32 微控制器中使用，你要做的工作就是把涉及到底層硬體的程式碼稍微修改一下就可以了，這種工作量很少，你的程式碼寫得足夠好的話，是很容易的，這稱之為移植。那為什麼 C 語言可以做到跨平臺呢？我們知道微控制器最終還是要透過組合語言執行的，所有的 C 語言其實都會透過編譯器進行轉化的，也就是說你寫的 C 語言程式會經過一種稱為編譯器的東西轉為對應的組合語言，比如說你的 C 語言程式要執行在 51 微控制器上，你就要用對應的編譯器編譯，如果要執行在 STM32 上，你也要用另一個對應的編譯器才行，這就是 C 語言能跨平臺的秘密！跨平臺的工作是交給了編譯器，而不是說 C 語言真的能直接在各種微控制器上執行！

但是真正的微控制器程式並不是只有 C語言的，在進入 C 的世界之前，其實是有一段程式碼的，這稱之為啟動程式碼，但是這段程式碼很少！

庫函式和暫存器的區別也是如此，庫函式類似於 C 語言，而暫存器就類似於彙編。

使用庫函式的好處就是你不用深入每一個暫存器操作的細節，而是把工作重心放在功能實現上。所有的暫存器細節都由封裝好的函式去實現，你要做的就是合理的呼叫它。但也正因為細節進行了封裝，所以在編寫庫函式的時候會考慮更多，這就會導致庫函式的程式碼比較臃腫，效率比較低下，但是它的好處就是方便移植、修改，就是說即使庫函式程式碼真出現了問題，你也只是找對應的函式進行修改就可以了，其他的函式基本可以不用動。

正因為庫函式和暫存器操作各有優勢，所以真正的高手一般都會結合這兩種寫法，比如在一般程式碼中使用庫函式編寫，遇到關鍵程式碼採用暫存器操作，比如說中斷函式這種關鍵部分，一般都會使用暫存器的方式。

以上！

能用庫函式當然庫函數了，可以節約大量時間精力，要不然STM32暫存器這麼多，你去查吧，至於程式碼量和執行效率問題我認為不用考慮，畢竟STM32記憶體和執行速度在那的；還有STM32庫函式後面有大量的人在維護最佳化，你自己寫的不一定有庫函式程式碼量少。當然，你如果想學精STM32的話 暫存器程式設計肯定要看的，單純做工程的話肯能庫函式優先。