[STM32F072 Nucleo ] 开发板 CubeMX与FW操作GPIO的差异

wenyangzeng

    昨天用STM32CubeMX 对开发板进行编译下载收到满意的结果。其中对PA5的操作是使用直接寄存器模式：GPIOA->ODR |= 0X0020; //置1
GPIOA->ODR &= ~0X0020;//置0

今天打算用F0库操作模式来进行：

GPIO_SetBits(GPIOA ,GPIO_Pin_5);
GPIO_ResetBits(GPIOA ,GPIO_Pin_5);

    不料，上面2条语句编译却报错，用STM32CubeMX生成的函数库竟然不支持F0函数库对GPIO的置位清零。有点纳闷，CubeMX同样是ST的软件包，为何自家人要各立门派，相互不兼容。其实F0和F1的函数库也有这个问题，有许多操作相同功能函数，它们的函数表达式却有少许差异，这给使用者软件移植带来诸多不变。
   阅读STM32CubeMX生成的函数库，才发现这2条函数表达式如下：
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_SET);
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_RESET);
在此分享，望各位少走弯路。

CubeMX生成的系统时钟配置的函数如下，各位可以看出其中的差异：
void SystemClock_Config(void)
{

  RCC_OscInitTypeDef RCC_OscInitStruct;
  RCC_ClkInitTypeDef RCC_ClkInitStruct;

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = 16;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
  HAL_RCC_OscConfig(&RCC_OscInitStruct);

  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_SYSCLK;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
  HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0);
  __SYSCFG_CLK_ENABLE();

}



真希望ST能把STM32CubeMX升级一下，把这些差异兼容掉。

巅峰残狼

总得有个过程，毕竟是新东西，以后应该会有更新的，客户用着爽才是王道

arm8686

使用 HAL （硬件抽象层），应该是 ST 公司今后的代码风格吧。

wenyangzeng

arm8686 发表于 2014-12-9 11:28
使用 HAL （硬件抽象层），应该是 ST 公司今后的代码风格吧。

谢谢楼上的指教

ilovestmcu

hal库文件少很多功能,郁闷啊.
想用cubemx,但感觉还不是时候

wambob

看CUBEMX与MFC何其相似,但却没MFC强大,说是新生事物吧,偏偏象MFC

wenyangzeng

wambob 发表于 2014-12-25 20:04
看CUBEMX与MFC何其相似,但却没MFC强大,说是新生事物吧,偏偏象MFC

   其实CUBEMX完全可以将库函数语法做成与STM32函数库语法相兼容的。这样可以让用户很快就能适应。当初STM321.0库过渡到2.0-3.0库就让用户经历了一次痛苦的过程了。

织梦狼

差异化太大反而没人意用，就像winXp和win8一样所以中间有个Win7。win8是失败的产品，win7起码有企业愿意掏钱买单。win8只有在那些山寨触摸平面见到身映。

770781327

所以现在cubemx只能用来玩玩

AndyYau-268557

还没玩过这种板，帖子很及时。看来得记下来，少走弯路。谢谢楼主