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，都是能够直接使用的。

代码架构

对于库开发方式，若是是学习，则每一个外设功能一个项目目录便于理解。

若是是产品开发，则为一个项目目录，方便各模块调用。