不會配置STM32的暫存器，而會使用官方的庫函式是不影響使用STM32微控制器的。STM32微控制器在程式設計時即可以使用配置暫存器的方式，又可以使用庫函式的方式，這兩種方式都是可以操作STM32微控制器的。

熟悉51微控制器的朋友，都知道在編寫程式時，需要配置51微控制器的暫存器。微控制器具有很多的片上資源，而片上資源要正常工作，就需要配置相應的暫存器。比如微控制器的定時器資源，在配置定時器相關的暫存器時就是配置定時器的工作方式、位數、是否使用定時中斷、配置初始值等。

而到了STM32微控制器，廠家直接提供了官方庫函式。這些庫函式的作用其實就是將暫存器的配置過程封裝了起來，使用者在程式設計的時候不需要直接和暫存器打交道，而只需要呼叫相應的庫函式就可以。這樣就可以將配置暫存器的過程分離開來，實現了硬體層面和軟體層面的簡單分離，其實就是驅動的作用。

STM32還有HAL庫，即使是使用庫函式程式設計，還是建議研究一下暫存器。

所以，不管使用庫函式，還是直接配置暫存器都是可以操作微控制器的。

用庫函式當然可以，用暫存器也可以，根據個人情況選擇，有人覺得標準庫太大，會使用HAL庫甚至LL庫，不管採用哪個，還是要透過暫存器瞭解外設的工作方式的。我個人使用C++封裝的暫存器方式，感覺比較方便。

使用STM32只會庫函式，不會暫存器，並不影響產品開發。

STM32系列專為要求高效能、低成本、低功耗的嵌入式應用設計的ARM Cortex®-M0，M0+，M3, M4和M7核心。在實際產品開發中，成熟的晶片方案商都會提供庫函式版本和暫存器版本兩個版本。最常見的是兩個版本混合，底層使用暫存器，中上層使用庫函式。

如果你只是想快速完成開發任務，建議你直接呼叫庫函式。如你還想和硬體打交道，建議你適當使用暫存器。安全高效的開發規則是，能用庫函式的必須要用庫函式，使用暫存器的必須要符合廠商Spec.。

很多產品團隊都對成員進行分組分工，例如一般劃分為驅動、系統、應用三類人員，基本上只有驅動組和系統組才允許操作暫存器，應用組只能使用已封裝好的API。這樣做最大的好處，安全且高效。

總的來說，只會庫函式而不會暫存器，並不影響開發。因為有晶片方案商已為你做好必需的工作，或者是團隊內驅動或系統組也可以為你做好必需的工作。

用STM32來做產品開發只會庫函式，卻不會操作暫存器，在大多數的專案中基本不會有什麼影響的，用庫函式寫出來的效果和用暫存器寫出來的效果完全一樣。但是在某些情況下還是有一點點影響的。如果有精力的話，我建議兩種方式都學一下。

有了庫函式以後，會讓我們的開發效率大大提高。這一點非常重要，畢竟公司做專案的時間是非常有限的，如果要去研究暫存器的使用，那真是費時又費力，STM32晶片的資料手冊動輒上千頁，這麼多的暫存器要去吃透它，在時間上面肯定不允許。

作為工程師來說，我們當然希望操作越簡單越好了，如果是傻瓜式的操作那更好。試想一下做上位機應用開發的同事，他們在需要什麼功能的情況下就去找相應的介面就好了。庫函式的操作就相當於這些介面的操作，它讓我們不需要去了解硬體的機制，只要根據功能去找到相應的操作函式就好了，這真是一件美差，何樂而不為呢。

為了讓工程師們獲得傻瓜式操作的體驗，ST公司甚至推出了HAL庫，直接在CUBEMX軟體介面一頓快速操作就能生成相應的程式碼，這簡直就是神器，工程師們都要偷著樂了，上班又有更多偷閒的時間了。

所以，我認為採用庫函式來操作的方式是完全有必要的，因為這不但加快了產品的研發的速度，還能極大的解放工程師的時間，讓他們可以花更多心思在更有意義的事情上面。

作為一個從事底層軟體開發的人，我認為還是有必要更加了解硬體的。就像練武一樣，光懂得套路還不行，如果要想達到實戰的目的，你還必要學習殺人技。現在的武術上不了擂臺，我看都是淪落於套路之中了吧。

用了庫函式的缺點就是，程式碼量會增大，庫函式會把所有情況都考慮到函數里面，沒有一擊即中的效果，有時會造成程式碼的冗餘，在程式空間吃緊的時候，你還是得乖乖最佳化成暫存器的方式。對於一些實時性要求極其嚴格的場合，直接操作暫存器無疑是更好的選擇。

不過不需要也不建議剛開始學習STM32微控制器的時候就使用暫存器的方式，可以先嚐試使用庫函式的方式來操作。這樣子入門會更快。等到除錯的時候也會跳到暫存器內部，到時候再對著資料手冊來分析也可以對暫存器有更好的瞭解。

操作暫存器就等於學習功夫的心法，如果你把STM32的暫存器都掌握得很好了，那你再去學習別的微控制器的時候那就是小菜一碟了。

你好，看了已有的回答，多是認為沒有影響，我和他們持相反的立場，我認為肯定有影響。下面我以下兩個方面進行論述：

HAL庫函式是ST開發的，也是人寫出來的程式碼，既然是程式碼，那就有存在BUG的可能，而且像這些經過ST除錯過的程式碼，更可能隱藏深層問題，這些都需要透過修改暫存器配置來除錯定位。

也許你是找FAE來現場支援，把問題解決了，但決不能對問題的根因雲裡霧裡，一知半解，作為合格的員工，需要對問題有深入的思考，這不僅是對公司負責，更是對自己負責，只能這樣你的技術才能提高一個層次，越來越進步。當然這不是要求你對CPU的所有暫存器都瞭解，但是要能看懂暫存器，會用暫存器，這是作為一位技術人員的基本素養。

有影響，影響你的除錯速度和能力，除錯模擬時檢視暫存器引數可能可以快速幫助你找到問題所在。俗話說程式碼三分寫七分調。有時候遇到一句庫函式或者hal庫的bug，可能必須得用到暫存器了。

影響就是，別人用1系列能完成的任務，你可能要用4系列。如果是藍海產品還能活一陣，如果是紅海產品，中間這十幾塊錢的差價要了老闆的命。

話說用stm32的有藍海嗎？

搞了十多年微控制器，建議您不要止步於庫函式。像意法這樣的公司程式碼質量非常好，但是有些產品可能因為成本會考慮使用中國產微控制器，小廠中國產的給庫函式可能會有bug，甚至沒有庫函式可用，技術支援也不咋地，如果只會用庫函式就傻眼了。

在中國做專案一開始自己配置暫存器來開發是行不通的，週期太長,除非你有提前準備。當然用庫函式開發最終也是配置暫存器，只不過是人家提前幫你配置好了而已，我們純粹就是拿來主義，這樣大大的縮短開發週期，

有會不會這個問題嗎?什麼是會什麼是不會，努力吧少年。你問這個問題就像同樣是5000，可人家拿的大歐，而你只是rmb。

你要這麼想，別人用java開發應用，卻不知道作業系統的原理，有影響嗎？事實就是，沒什麼影響。時代在發展，做產品講究的是應用，而不是花大量時間先研究一遍暫存器，等你研究出來黃花菜都涼了，能更好更快的出產品才是王道，不然人家這個寫個庫給你幹嘛？未來不止是庫，功能模組給你封裝好都有可能，你要做的只是"搭積木"。

都是可以的，看個人喜好。喜歡研究比較底層邏輯的傾向於暫存器開發，喜歡省力的用庫函式，都可以。但是要說開發出來的程式效率，一般暫存器是會高點的，從編譯時間就可以體現出來，因為越方便的庫函式勢必留了許多介面方面的東西方便使用者簡單配置，所以冗餘的東西會比較多

都是可以的，看個人喜好。喜歡研究比較底層邏輯的傾向於暫存器開發，喜歡省力的用庫函式，都可以。但是要說開發出來的程式效率，一般暫存器是會高點的，從編譯時間就可以體現出來，因為越方便的庫函式勢必留了許多介面方面的東西方便使用者簡單配置，所以冗餘的東西會比較多

看完回答，我就暈了，你們不知道還有實時作業系統這種東西？專案大，你怎麼管理各種資源？靠手，你有三頭六臂？你覺得彙編除了教學，能寫出真正的商業軟體不？庫都讓你們說的那麼不堪，更不要提作業系統了，你們只編過教學用的Demo吧？

看完回答，我就暈了，你們不知道還有實時作業系統這種東西？專案大，你怎麼管理各種資源？靠手，你有三頭六臂？你覺得彙編除了教學，能寫出真正的商業軟體不？庫都讓你們說的那麼不堪，更不要提作業系統了，你們只編過教學用的Demo吧？

記得有次用飛思卡爾的mke02開發，底層用售後提供的庫，結果有個IO出現問題，找問題很久，最後深入到庫裡，參考開發手冊，才發現是暫存器配置錯了。所以你說有沒有問題，我只能說沒出現問題的時候問題不大，但一旦出現問題那就是大問題了。