STM32HAL库写CAN通信程序最近遇到了难题，有谁有具体例子不

别人写的你参考一下：半年前接触STM32，刚开始MCU用的32F1，库用的标准外设库35，写过一些简单的东西。再后来发现ST还有一个软件叫做STM32CUBEMX，可以自动的生成初始化程序，对于我这个32新手来说无疑是天降福音！终于不用为繁琐的配置而苦恼了（其实就是自己对各项配置不熟，而且没有自己积累的程序可以CtrlC+CtrlV）。虽然CUBE用的是ST新出的HAL库，与以前的标准外设库完全不兼容，甚至基本的I/O *** 作都变了，会让习惯了标准外设库的人很苦恼。但是我对标准外设库也不是很熟，而且CUBE的界面化设计真的让配置工程变得很方便，再加上它还有一个类似于FPGA的引脚分配界面，让资源分配，PCB布局布线也方便了不少，于是我选择了用CUBE，用HAL库。很早就开始的写32的朋友有不少，他们也试过HAL库，可最后无一例外都选择了继续使用标准外设库。他们表示完全不习惯HAL库，另外HAL库不太好，毕竟是自动生成的配置，没有自己手动配置的来得熟悉来得透彻，谁知道软件是怎么给你配置的工程。另外CUBE就是给那些不会写32的人用的（ST的官方的说法似乎也是HAL是为了方便做嵌入式相关且对底层不熟的人设计的，但想不通他为何要把两个库做得不兼容）。前面一直在画PCB，调PCB，做机械之类的，没有写程序。最近又开始写32，现在用的MCU是32F4，库是HAL/F4库160。可是我发现我连GPIO的上拉输出都实现不了，无论如何I/O始终默认输出低电平（ *** 作I/O可以实现电平跳变），这个问题我昨天查了一天，从库到最底层的寄存器都看了，可没发现什么问题。周围用HAL库的就我一个。。。有些无奈了，难道HAL库真有什么问题吗？如果真有这么明显的问题，ST官方肯定早就发现了。已经下好了标准外设库，打算换标准外设库，工程从头到尾都自己配置，这样出了问题也更方便找。可是我始终有一点想不明白，既然ST官方在推HAL库，那肯定也有他的道理，我们也应该勇于接受新事物，为何身边的朋友却都不愿意接纳HAL库。

是的，HAL里面这个HAL_UART_Receive()函数已经明明白白地写了，它是阻塞式查询工作方式，只要标志不置位或者超时不结束，就干等到天荒地老。

如果你不需要阻塞式查询工作方式，就应当选用中断工作方式，改用 HAL_UART_Receive_IT()函数并配置对应的NVIC模块、调用对应的中断服务函数并且钩上对应的回调。

将下载好的固件库添加到工程目录中，并在工程中添加相应的文件，以闪烁LED灯为例子。

新建user、proj文件夹。

复制 STM32Cube_FW_F1_V140\Drivers\STM32F1xx_HAL_Driver\Inc 里的 stm32f1xx_hal_conf_templateh 到user目录中，并重命名为stm32f1xx_hal_confh。

复制 STM32Cube_FW_F1_V140\Projects\STM32F103RB-Nucleo\Templates\Src 文件夹里面的 stm32f1xx_itc 以及 STM32Cube_FW_F1_V140\Projects\STM32F103RB-Nucleo\Templates\Inc 文件夹里面的 stm32f1xx_ith 到user文件夹中。如果stm32f1xx_itc 中SysTick_Handler 为空的话，请在该文件的放置头文件的地方添加#include "stm32f1xxh" 如下图所示：

，

并在SysTick_Handler 函数中添加HAL_IncTick(); ，如下图所示：

。

新建一个C文件，输入例程。

添加程序代码， STM32Cube_FW_F1_V140\Drivers\STM32F1xx_HAL_Driver\Src文件夹里面的单片机驱动程序(根据需要添加)、 STM32Cube_FW_F1_V140\Drivers\CMSIS\Device\ST\STM32F1xx\Source\Templates 文件夹里面的 system_stm32f1xxc 、 STM32Cube_FW_F1_V140\Drivers\CMSIS\Device\ST\STM32F1xx\Source\Templates\arm 文件夹里面的启动文件(根据实际情况添加)、 user 文件夹里面的 stm32f1xx_itc 和 gpio_democ 添加到工程的程序文件如下图所示：

添加的头文件路径如下图所示：

在c/c++编译器选项宏定义一栏中添加STM32F103xE,USE_HAL_DRIVER (查看stm32f1xxh)，如下图所示：

编译

U盘在出现问题前是因为前期的 *** 作导致的，有可能是数据丢失了，不能正常使用，只要物理没有被损坏，桌面右下角还能看到USB设备符号，找不到盘符等问题。我倒有一个法可以解决。就是给U盘重新设置驱动，（注意：这样的 *** 作只能使U盘能够正常使用，之前所放的文件数据是无法找回的）可以尝试用磁盘驱动做为U盘驱动，这样就能正常看到U盘盘符，但是还是不够使用的，现在的U盘显示应该容量为0，不能储存和使用，然后找一个和主控型号一样的量产工具进行再次量产，量产成功就OK，一切正常能使用，量产失败，那就再找量产工具吧，和主控型号差不远的量产工具也是可以的，只要能量产成功就可以了。因为之前我有个U盘也是被我非法 *** 作把U盘数据丢失了，拿给专业的维修点进行维修连他们都说没有其他法维修，我就自己尝试着修复“不能维修的U盘”结果为了修复这个U盘，电脑系统被重装过好多次，因为给U盘设置驱动需要一个一个的试，导致了电脑蓝屏，死机等问题。试过之后只有磁盘驱动符合U盘做驱动，我狂汗~！然后我就按照以上的方法把我的哪个U盘修复了，用到现在一点问题都没有，这是我自己亲身体验过来的实际 *** 作现在拿来和大家分享，希望对大家有帮助。

在 STM32 的 HAL 库和标准外设库中，都存在一个名为 `RESET` 的常量。该常量的含义是复位标志，用于指示芯片是否发生了复位。具体来说，当芯片发生复位时，系统会将存储器中的所有变量清零，并将 `RCC_CSR` 寄存器中的复位标志位置 1，以便以后的 *** 作可以检测到芯片的复位状态。在 HAL 库和标准外设库中，可以通过读取 `RCC_CSR` 寄存器中的复位标志（即 `RESET` 常量）来检查芯片是否发生了复位，从而进行相应的处理。

需要注意的是，`RESET` 常量的值并不是 0 或 1，而是一个特殊的值 `0x01U`，代表着复位标志位被置为了 1。因此，在使用 `RESET` 常量时，需要将其与 `0x01U` 进行比较，来判断复位标志位是否被置为了 1。例如，可以使用如下代码检测复位标志位是否被置为了 1：

```c

if (__HAL_RCC_GET_FLAG(RCC_FLAG_RESET) == RESET) {

// 处理复位状态

}

```

其中，`__HAL_RCC_GET_FLAG(RCC_FLAG_RESET)` 函数用于读取 `RCC_CSR` 寄存器中的复位标志（即 `RESET` 常量），`RCC_FLAG_RESET` 参数用于指示要读取复位标志。如果返回值等于 `RESET` 常量（即值为 `0x01U`），则说明芯片发生了复位。

以上就是关于STM32HAL库写CAN通信程序最近遇到了难题，有谁有具体例子不全部的内容，包括:STM32HAL库写CAN通信程序最近遇到了难题，有谁有具体例子不、STM32HAL轮询模式串口接收函数超时等待问题、如何配置stm32f1的hal库等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！