GD32使用ST的HAL库和GD官方库的一些体会
时间：2022-08-24 13:55:47
手机看文章
扫描二维码
随时随地手机看文章
[导读]GD32作为国产MCU里的佼佼者，产品线也比较丰富，是替代STM32的一个很好的选择。前段时间有个项目用到GD32的单片机，今天来说说使用的一些体会。
GD32作为国产MCU里的佼佼者，产品线也比较丰富，是替代STM32的一个很好的选择。前段时间有个项目用到GD32的单片机，今天来说说使用的一些体会。
1.硬件我用的单片机型号为GD32F405RGT6，对应STM32F405RGT6。首先，硬件上基本兼容，有一点不同的是GD32的31和47脚为NC，STM32的为VCAP。STM32这两个引脚需要分别连接一个电容到GND，而GD32则不需要。当然，有这两个电容也无所谓，所以，硬件上GD32可以直接替换STM32。
仿真器可以使用Jlink，也可以使用STLink，但是下载程序时会弹框提示，非ST芯片。2.软件软件上，前期为了快速实现功能，直接使用ST的HAL库开发（版本为V1.27.0）。用到的外设有：外部高速时钟、Systick定时器、GPIO、串口1（DMA、中断）、SPI1、SPI2、I2C1、外部中断。用STM32CubeMx生成代码，不做任何改动，直接当做ST的芯片使用，上述外设功能都正常。说明两者的兼容性还是不错的。其它外设基本上也都是兼容的（未做测试），但USB部分貌似只能用GD官方提供的USB库。
HAL_UART_Transmit_DMA(&huart1,tx_buffer,64);
而GD的库没有现成的函数，需要自己去实现：
void usart_dma_transmit(uint8_t *pData,uint32_t num){ usart_flag_clear(USART0, USART_FLAG_TC); dma_channel_disable(DMA1, DMA_CH7); dma_flag_clear(DMA1, DMA_CH7, DMA_FLAG_FTF); dma_memory_address_config(DMA1, DMA_CH7, DMA_MEMORY_0, (uint32_t)pData); dma_transfer_number_config(DMA1, DMA_CH7, num); dma_channel_enable(DMA1, DMA_CH7);}类似的还有很多，比如I2C读写24Cxx系列EEPROM的函数，HAL库中也封装好了函数：
HAL_I2C_Mem_Write(&hi2c1, AT24Cxx_ADDR_WRITE, addr, I2C_MEMADD_SIZE_16BIT, dat, size, 0xFFFFFFFF);HAL_I2C_Mem_Read(&hi2c1, AT24Cxx_ADDR_READ, addr, I2C_MEMADD_SIZE_16BIT, recv_buf, size, 0xFFFFFFFF);GD的库也需要自己去实现，官方虽然也提供了相关的例程，但是只支持24C02等8位地址的器件，24C64等16位地址的器件就需要自己修改了。当然，HAL库虽然好用，但是效率很低。记得之前做一个低功耗的东西，用STM32L151，主频设置的较低，使用HAL库回调函数的方式写串口中断程序，竟然会出错。后来中断部分改为寄存器操作才正常了，可见其效率低下。
其次，两者的命名方式不一样。HAL库中时钟叫RCC_xxxx，而GD的库中时钟叫RCU_xxxx。还有，HAL库中的外设标号是从1开始的，比如USART1、USART2…，而GD库的外设标号是从0开始的，USART0、USART1…。用惯了ST库的朋友们，这一点在使用时要特别注意。
最后，实现相同功能的程序，两者编译后的大小也有区别。GD库编译后的大小如下：
HAL库编译后的大小如下：
可以看到HAL库编译后的代码要比GD库大了将近4KB，占用的RAM也大了1KB多。主要是因为HAL库为了不同系列芯片的兼容性好，做了很多层的封装，程序比较繁琐。3.总结总的来说，HAL库用起来方便，但效率较低。GD的库有些功能需要自己实现，但执行效率高。当然，如果用GD的芯片，我还是建议用GD官方的库，不然出了问题都不好排查。如果用ST的芯片，我建议用HAL库。很多人排斥HAL库，一方面觉得效率低，另一方面觉得封装了很多层，看起程序来比较麻烦。我倒是觉得效率低的问题可以通过局部优化来完善。（HAL库也提供了类似标准库的一些高效的底层函数，一般都是以“__HAL”开头的）。而且，现在单片机资源都比较富裕，很多时候我们也不必那么追求极致的效率。另一方面，官方一直在主推这个，这也是个趋势，我们还是与时俱进比较好。
推荐阅读：
下载文档
