stm32 f1和f4開發模型

硬件區別

http://www.stmcu.org/module/forum/thread-582410-1-1.html

軟件區別

http://forum.eepw.com.cn/thread/230356/1/

開發模型

抽象化

若是拿來一個開發板學習，目前通常採用標準庫方式來入門。那麼咱們在用標準庫來學習時到底在學什麼？本質上咱們是在學驅動開發。

通常咱們在學習某個外設的時候會創建這樣的文件，bsp_xxx.h和bsp_xxx.c，xxx指某個外設，而後在main文件裏調用上述頭文件，main函數裏寫些測試代碼。這裏bsp_xxx基於庫開發的針對特定板載硬件的驅動程序，而main函數裏面纔是最終咱們要作的應用開發。

因爲mcu的功能衆多，不可能爲每一個功能單獨拉出管腳，對於實現一個功能，好比led，你用哪一個gpio均可以，若是須要用UART，i2c等，由於存在多個這樣的外設，你用哪一個均可以，這就不開避免的產生硬件結構的差別化，進而帶來驅動的一致問題。通常採起的方式是，在頭文件裏定義和具體管腳、接口相關的宏，在c文件裏儘可能避免帶來和硬件相關的移植問題。這樣，針對某個特定mcu開發的驅動就能夠很容易的移植到另外一個板子。

還有一種外設相關的驅動，好比用i2c，這種外設是通用外設，你是用它來操做EEPROM仍是控制傳感器、傳輸數據均可以，但具體到驅動細節就須要根據操做的對象分別來實現。這時候，咱們儘可能把通用外設的操做和具體外設的操做區分開來，好比i2c共有的代碼單獨放到一個文件，針對eeprom的操做單獨放在一個文件去引用i2c的代碼，其它外設如傳感器控制採用類型方式。

另外一個問題，就是多個同類外設，好比UART，會有UART1，UART2……等多個UART，若是咱們在定義宏、函數名的適合，不加區分，如UART_xxx(),那當咱們同時使用UART1和UART2時這時就有命名衝突。由於UART1和UART2對應的管腳不同，甚至有的同類外設時鐘等也不同，這時候咱們最好進一步對管腳進行抽象，如定義UART1相關的宏或管腳結構體，儘可能作到面向對象編程中的類和對象模型，方便同類芯片不一樣板子的移植工做。

標準化

雖然stm32外設衆多，管腳複用繁雜，可是不一樣外設的使用方式上仍然有不少功能的地方，如須要先定義GPIO初始化結構體，外設初始化結構體，開啓對應的GPIO和具體外設時鐘，配置GPIO輸入輸出模式結構體，配置外設結構體，配置或使能GPIO複用功能等，這些操做對於不一樣外設都有相似的模式。另外，不一樣的板子的驅動，若是對方抽象的比較好，好比把移植相關的代碼都定義在了頭文件，那咱們也是能夠直接拿來簡單修改便可以使用。尤爲是官方的參考實例，一些簡單的協議咱們能夠本身理解後本身編寫，對於複雜的通訊協議，好比USB等，若是沒有移植問題，確定要參考已有的示例。

命名上，建議和驅動相關的文件以bsp_xxx方式命名，這些代碼若是用於移植到某個rtos，都是能夠直接使用的。

代碼架構

對於庫開發方式，若是是學習，則每一個外設功能一個項目目錄便於理解。

若是是產品開發，則爲一個項目目錄，方便各模塊調用。