高小公子
這個問題從兩方面來說：如果希望快速開發出來項目的話，用庫函數開發；如果希望學精、學透單片機原理的話，用寄存器開發。
一、從開發時間快慢來說，用庫函數
現在公司開發一個項目的話，都會對時間進度有很高的要求，一般都會要求快速高效的把產品做出來，而不管你用那種方式，只要保證產品的質量就行。在這種情況下，就必須找一種能夠快速開發的途徑，而庫函數正是基於這種原因創建的。芯片公司為了幫助產品工程師降低開發難度、加快開發進度，推出了各種庫函數，這些庫函數都是由專業程序設計人員編寫的，無論從代碼的穩定性、規範性、正確性方面來說，都是經過芯片廠家反覆驗證的，完全可以直接拿來就用。
當然，用庫函數有一定的缺陷，例如會導致代碼量增大，影響程序運行速度等，但是現在stm32單片機的程序空間一般都足夠大，並且每一系列裡面都有pin-to-pin的型號可以互換，如果程序空間不夠，直接替換另一個管腳兼容的，程序空間更大的即可，程序直接移植過來，幾乎不用修改。
二、從原理性學習來說，用寄存器
對於想要學習單片機的工作原理，想真正弄清楚stm32的內部結構，工作過程，底層配置這些功能的人員來說，當然是選用寄存器來開發了。
用寄存器開發，可以直接接觸到最底層的，並且用寄存器可以減少代碼量，提高程序運行速度。
老馬識途單片機
我玩stm32有三四年了，但是我並沒有用寄存器寫過代碼。
不是說寄存器不好，上面幾位我不太清楚他們玩過沒有，我是的的確確玩了很久了。所以就來回答一下。
如果你覺得你的能力足夠勝任stm32的寄存器，那用寄存器最好，如果你看了手冊以後並不能用的起來，那就用庫函數吧。
寄存器比庫函數效率高很多。
如今stm32有三種庫，最早是標準庫，然後是hal庫，後來hal可能效率太低，官方整出來個LL庫。
速度最快的要數LL庫，標準庫次之。最後是HAL。
但是，我建議是學習HAL庫。
有人問了，這貨最慢為啥學這個。很簡單，官方主推。
官方弄出來個工具叫做STM32cubeMx，這個幾乎都是hal庫，而且一鍵生成代碼，開發週期大大縮短。而且，最重要的，在一些運行效率需求比較高的地方可以選擇使用LL庫。這都是工具上自帶的。
細心的同學會發現，hal庫基本上過段時間就更新一次，更新頻率非常快，這是官方主推的，所以官方也維護的比較積極。當然，這個東西bug還是比較多。現階段已經比較穩定了。
還有個缺點，選擇功能比較多的，比如FATFS FreeRTOS STEMWIN等都加上，編譯速度非常慢。弄個程序一大半時間都在編譯中。。。
建議要配一個臺式機再玩這麼多功能咯。
中國頂級科技評論人
感謝邀請答題！這個問題很有爭議性，但是目前來說的話還是庫函數編程的人群量比較多，寄存器有許多的問題注意。下面就讓我來說下個人的看法吧。
庫函數，一般都是學習的入門首選，因為官方製作好的東西，只要拿來用，基本上問題是不大的，而且學習的效率和進度也會大大提高，對於學習和理解32是個很不錯的方式。
它的優勢體現在，對於公司來說，可以在一定的時間下縮短產品的研發週期，這點也是很多公司所青睞的，從提出想法到完成測試再到部署市場，短的研發週期可以使公司迅速立足市場，達到效益的最大化。
對於個人來說，在比賽和完成項目中是比較有優勢的，畢竟能不能做的出來很關鍵，不用太過於注意底層實現的細節。
寄存器，是那些喜歡瞭解細節和想要弄清楚整個系統是如何運行起來的，以及底層的實現原理的人所青睞的。具有挑戰性，能夠更加深入地學習32，並且採用這種學習的人的能力是很強的，但是需要花費比較久的時間。
信息化的時代，技術的變化之快，寄存器的學習方式和使用是比較吃力的。但是如果有興趣為何不嘗試一下嗎？最後個人認為，庫函數開發才是比較好的選擇！
我隊友賊厲害
庫函數。
STM32功能強大，光定時器數據手冊的說明就有100多頁，像51一樣寄存器配置來編程的話，你根本無法下手。
庫函數是ST官方出的，相當於是用字面就看得出的變量名稱，將寄存器的位封裝成相關的結構體，要配置的時候就給相關結構體的成員變量賦予相關的值，再調用寫好的函數，就達到對相應寄存器配置的效果，程序可讀性好。
當然在編程的時候要深入進去庫函數的結構體和函數，根據頭文件和數據手冊找到相關的寄存器是如何配置才能達到你想要的效果。
總而言之多看多寫多試。
低壓電器
當然是庫函數好。現在很多人學單片機都是從51單片機學起，而51單片機編寫程序就是對其寄存器進行讀寫操作。為什麼51單片機可以用寄存器的方法進行編程呢？是因為其簡單，對寄存器操作方便，而且效率高。於是，很多小夥伴從51單片機進階到stm32單片機時，都會有一種想法，那就是看它的寄存器編程，可一看卻傻眼了，stm32單片機的寄存器很多，而且操作起來還很麻煩，於是他們掙扎了一段時間後就會發現庫函數這個好東西，並且越深入瞭解庫函數，就會發現其實對庫函數操作也是對寄存器操作，只不過庫函數把對寄存器的讀寫都寫成了一個個函數的形式，大大增加了代碼編寫的效率。我們再反過來看51單片機，你也會發現，對其寄存器的操作自己也可以定義成一個個函數，方便自己移植代碼，只不過這種函數是自定義的，不像stm32的那樣，有統一的官方庫函數手冊。
一起閒說閒聊
不涉及內核的代碼建議用庫函數，庫函數代碼的可讀性寫得不錯，每個寄存器的設置也比較完整，但要想把效率和性能發揮出來，需要自己寫，庫函數只有一些外設驅動，比如內存的訪問模式這些接口是沒有的
吹過初夏的風
學習使用單片機3年了，接觸STM32也有1年多了，最近做了一個項目，就是用寄存器寫的，用keil開發，寄存器操作也是非常方便，只要寫代碼時候別直接寫數值，而是用頭文件裡的定義變量代替，比如APB2ENR=APB2ENR_GPIOA+APB2ENR_GPIOB;我覺得這樣去寫代碼，不論是代碼數量和可讀性都還是很好的。
天邊鐘聲
肯定是庫函數啊，先不說開發效率，單單是從代碼的可讀性就必須庫函數！！！我們公司早期的代碼清一色的寄存器還帶位操作，上萬行的代碼，維護起來那叫一個蛋疼，經常看代碼看著看著就要去翻寄存器手冊……影響效率不說還影響心情……
喑啞3
使用stm32 7 年，現在所有產品都用其開發。以前開發的產品也換成了這個平臺，我重來不用直接操作寄存器，說操作寄存器會更精與理解stm32 我覺得這是一個很大的誤區。現在產品更新換代那麼快，單片機就是個工具而已。有那個時間還不如多開發一個產品
