STM32CubeMX设置PC13和PA1为推挽输出，速度50M，用LL库生成的代码如下:

1. void MX_GPIO_Init(void)
   
2. {
   
3. 
   
4.   LL_GPIO_InitTypeDef GPIO_InitStruct;
   
5. 
   
6.   /* GPIO Ports Clock Enable */
   
7.   LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_GPIOC);
   
8.   LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_GPIOD);
   
9.   LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_GPIOA);
   
10. 
    
11.   /**/
    
12.   LL_GPIO_ResetOutputPin(GPIOC, LL_GPIO_PIN_13);
    
13. 
    
14.   /**/
    
15.   LL_GPIO_ResetOutputPin(GPIOA, LL_GPIO_PIN_1);
    
16. 
    
17.   /**/
    
18.   GPIO_InitStruct.Pin = LL_GPIO_PIN_13;
    
19.   GPIO_InitStruct.Mode = LL_GPIO_MODE_OUTPUT;
    
20.   GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;
    
21.   GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
    
22.   LL_GPIO_Init(GPIOC, &GPIO_InitStruct);
    
23. 
    
24.   /**/
    
25.   GPIO_InitStruct.Pin = LL_GPIO_PIN_1;
    
26.   GPIO_InitStruct.Mode = LL_GPIO_MODE_OUTPUT;
    
27.   GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;
    
28.   GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
    
29.   LL_GPIO_Init(GPIOA, &GPIO_InitStruct);
    
30. 
    
31. }

复制代码

但是调试后发现寄存器配置不对，GPIOC寄存器如图：

PC13被初始化成模拟输入了，而PC5没有设置却变成了推挽输出了。

PA1倒是没有错误，GPIOA寄存器如图：


总结：
      后面又试了几个引脚，发现用LL库高位的引脚(GPIO8-15)初始化会有问题，像PC13,PB13这样的高位引脚，设置后实际改变的是对应低位的引脚PC5和PB5，而想要配置的引脚却变成其他模式了。如果初始化是低位的引脚(GPIO0-7)不会有错误，像PA1，PB1就能被正确初始化。
大家有没有遇到这样的问题呢？

先质疑自己，再质疑别人

经测试，STM32F103的LL库的确是坑，玩不起来。
环境STM32CubeMX 4.24.0，MDK 5.24

你的STM32F1是哪个系列的，具体什么型号？F1的型号太多了。

感觉不至于出现这样的问题呀，发个工程上来瞧瞧

LL库没玩过，不过我常用的F103系列中，印象是PC13速度不超过2MHZ，具体出自哪里，一时没找到。

我用HAL是好的，前几天刚测试过“YD-STMF1系列核心板”，就是某宝上出现最多的那个STM32F103C8T6小板板，上面的LED用的就是PC13，闪灯灯好着呢。

toofree 发表于 2018-2-23 00:17
你的STM32F1是哪个系列的，具体什么型号？F1的型号太多了。

感觉不至于出现这样的问题呀，发个工程上来瞧 ...

HAL库出来很久了，用了没啥问题，STM32F1的LL库最近才出的，发现有这个现象才来问问大家的。

衔胆栖冰 发表于 2018-2-23 08:57
先质疑自己，再质疑别人

没有质疑，只是有疑问，有什么不当的地方请指出

有！同样的BUG，今天用LL库初始化UASRT1，发现PA9和PA10都被初始化到了相应的PIN-8上，上面那个人说话真看不惯，你要么也去测试，要么帮忙分析一下可能的问题，别把自己摆的高高在上来一句先质疑自己。我们提问题都是经过思考的，另外今天第一次使用LL库，分别在F407的LL库上发现一个BUG，407的BUG是使用HSE的时候stm32f4xx_conf.h里面的HSE_VALE的宏会被LL库中的宏替代，而STM32CUBEMX不会去修改这个宏，所以导致UART使用的是25M配置的，导致传输错误的情况，库版本1.19，另外，STM32F1刚刚调试发现的BUG，我刚描述了，和你的情况一样，现在正尝试修复，库版本1.60

跟踪进去，错误发生在stm32f1xx_ll_gpio.c的184行的pinpos = POSITION_VAL(GPIO_InitStruct->Pin);这一句没有得到正确的GPIO管脚顺序，跟踪进这个宏，具体实现是先反向，然后计算前导0的个数(由注解直译理解)，继续跟跟踪到__clz这个，然后就跟踪不了他具体实现了，

xulei007 发表于 2018-2-23 20:13
跟踪进去，错误发生在stm32f1xx_ll_gpio.c的184行的pinpos = POSITION_VAL(GPIO_InitStruct->Pin);这一句没 ...

不好搞，用了很多宏，有的还是编译器的关键字，晦涩难懂，最好等官方完善了。还是标准库好，简单的封装，使用稳定。现在为了可视化出了cubemx和这两个库，碎片化严重。

哀歌与世无争 发表于 2018-2-23 22:16
不好搞，用了很多宏，有的还是编译器的关键字，晦涩难懂，最好等官方完善了。还是标准库好，简单的封装， ...

可以试着修复一下嘛~我直接改pinpos并不能正确初始化，后面还有一个currenpin，应该是指向正确的寄存器位置，然后我干脆寄存器初始化了，后面又发现USART那似乎也存在问题，这里用似乎哈，昨晚太晚没深究。