"stm32的AFIO"是啥意思？

Posted 2023-05-06

"stm32的AFIO"意思是在程序内部，部分外设使用是复用IO口，便可以开该复用时钟。

例如在STM32F103VET6中USART3的IO口为TX/PB10，RX/PB11。假若你要是将给外设IO口映射到（TX/PC10，RX/PC11）或者（TX/PD8，RX/PD9），便需要开启AFIO时钟即可正常工作。

参考技术A

在配置PC13引脚的外部线中断时，配置其外挂时钟时用到了复用功能：

RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC|RCC_APB2Periph_AFIO,ENABLE);

原因是PC13的第一功能引脚是GPIO，第二功能引脚是TAMER-RTC1，并没有EXTI的功能，要想用它产生外部线中断，必须配置AFIO复用功能，将EXTI功能映射到PC13引脚上。

PC13引脚功能图

又例：

CAN总线用到了PB8、PB9，而这两个引脚本身没有CAN功能，需要重映射：

RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO | RCC_APB2Periph_GPIOB, ENABLE);

PB8、PB9引脚功能图

CAN&485 TR引脚图

而有的配置是不需要配置复用功能的，例如：UASRT1的引脚PA9、PA10，它们的第二功能引脚就是USART功能，所以在使用UASRT功能的时候，就不能再AFIO配置时钟。

在配置RCC外挂时钟的时候，既要配置基础的GPIO模式，又要配置其第二功能USART的时钟。

而用到了PA9的第二引脚，有一种输出模式是复用输出模式，所以要配置成复用输出模式。

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;

由于USART和GPIOA都外挂在RCC_APB2上，所以参数是两个值的组合。

/* config USART1 clock */
RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1 | RCC_APB2Periph_GPIOA, ENABLE);

也许你以为IO和AFIO是很简单的，事实上有几个误区可能很多人都没注意过，当你只用现成的开发板来学习的时候，别人已经帮你做好了资源分配.所有的外设功能学习都是照着别人给你的例程去做的，这才没让你觉得奇怪。

先问自己一个问题：STM32中，USART2和TIM2是共用相同IO的，你如何决定这几个IO到底是做USART2还是做TIM2呢？如果你要同时使用USART2和TIM2，该怎么办？

1、不是说使用了IO的复用功能就一定要启动RCC_APB2Periph_AFIO的Clock的,参考下图

只有使用了AFIO的事件控制寄存器、AFIO的重映射功能以及外部中断(EXTI)控制寄存器才需要开启AFIO的时钟，STM32参考手册从来没说过使用IO的复用功能就一定要开启AFIO时钟，这是个误区。

例如下面的，最常用的USART1，如果你的板子上，默认用的就是PA9和PA10这两个IO作为USART1的TX和TX，那么也就是没有重映射，No Remap，这种情况下根本不需要开启AFIO时钟，只要开启USART1的外设时钟就行了。这个实验很简单，自己试试就知道了。

2、从上面的图你可以看到，原来USART1是可以放在PB6和PB7上面的，只不过几乎所有的原理图封装中都不会在PB6和PB7的复用功能上标出它可以当USART1用，毕竟这种重映射的情况太多，几乎所有外设都可以重映射，每个都标出来会非常混乱。

STM32中，USART2的CTS、RTS、TX、RX和TIM2的CH1~CH4都在PA0～PA3上面，具体要如何选择这两个功能呢？

如果要使用USART2，就开始USART2的外设时钟，如果要使用TIM2，就开启TIM2的外设时钟，如果你同时开启，我也不知道会怎么样，你可以自己试试，我觉得应该是两个都不能用。如果你一定要在PA0~PA3上使用这两个功能，只能是时分复用。

正确的同时使用USART2和TIM2，应该是使用上面提到的AFIO_Remap寄存器，将其中的一个重映射到其他IO上去，当然这样其他IO的本身的复用功能你就不能开启了。

回到前面的问题，如果你不做Remap，你根本不可能同时在PA0~PA3上同时使用这两个外设，现在你的方案有两种：

一、保留USART2在PA口上，将TIM2完全重映射(Full Remap)到其他IO上，或者，如果你不用RTS和CTS的硬件流控制，PA0(CTS)和PA1(RTS)上对应的CH1和CH2是可以不用重映射的，只需要将Bit9：8改成10，也就是将CH3和CH4部分重映射到PB10和PB11上去，而CH1和CH2继续保留在PA0和PA1上。但这种情况下，PB10和PB11上的I2C2和USART3就不能用了。

二、保留TIM2在PA口，将USART2重映射到PD口上，很明显，当TIM2完全不重映射时，USART2必须的信号线只有Clock不受影响，这种情况下也没有部分映射可言了，必须将USART2完全重映射到PD3～PD7上，同样的，这种情况下FSMC就不能用了。

STM32示例中变量名开头的“uw”是啥意思？

【中文标题】STM32示例中变量名开头的“uw”是啥意思？

【英文标题】：What does the "uw" mean at the beginning of variable names in STM32 examples?STM32示例中变量名开头的“uw”是什么意思？

【发布时间】：2018-10-08 20:53:05

【问题描述】：

在阅读 STM32 示例代码时，我看到大量以 uw 开头的变量。例如：

static __IO uint32_t uwLsiFreq = 0;
__IO uint32_t uwCaptureNumber = 0;
__IO uint32_t uwPeriodValue = 0;
__IO uint32_t uwMeasurementDone = 0;

每件事背后都有一个意义或一个故事。 uw 在这里是什么意思？

示例来源：STM32Cube_FW_F2_V1.7.0/Projects/STM32F207ZG-Nucleo/Examples/IWDG/IWDG_Example/Src/main.c.Download link --> 点击“STM32CubeF2”旁边的“获取软件”按钮。

【问题讨论】：

可能：“uw”代表某种Hungarian notation中的“无符号字”

【参考方案1】：

好的，我想发布我自己的更完整的答案。感谢@njuffa 在我的问题下方的评论中指出“可能：uw 代表某种Hungarian notation 中的'无符号字'”，感谢@PeterJ_01 的pointing out Stack Overflow 的首席执行官拥有关于此事的一些意见，并感谢@Sigve Kolbeinson 在 PeterJ_01 的回答下的评论中指出 Stack Overflow 的 CEO 的名字是 Joel Spolsky（如链接中所示），他实际上并不讨厌匈牙利符号，而是只是破坏了它的有限和损坏形式 [Systems Hungarian] 获得了一段时间的关注，并为我们提供了实际的link to the article，因此我们可以了解更多信息并自己阅读文章。

1。这是我回答我的问题的结论：

uw 在许多 STM32 示例变量的开头肯定必须在逻辑上表示“无符号字”，在这种情况下，“字”是 32 位。当我阅读代码时，知道这一点会增加很多清晰度，并消除对名称的一些混淆，所以我很高兴知道这一点。

在这种情况下，这是 Systems Hungarian 用法的一种类型，对于具有显式类型的语言（例如 C 和 C++）通常不鼓励使用，因为它是多余的并且几乎没有增加价值。将此与我在下面描述的 Apps Hungarian 进行对比，Joel Spolsky（Stack Overflow 的首席执行官）strongly promotes 是一种帮助“错误代码看起来错误”的方法。

2。以下是我通过他们的 cmets 和他们提供的链接从 @Sigve 和 @njuffa 那里学到的一些额外见解（主要是关于匈牙利符号）：

您可以将本节称为“计算机编程中的匈牙利符号到底是什么？”

Hungarian notation 存在（我之前不知道），是指在每个变量和/或函数名称的开头添加一些额外字符的概念，以提供有关变量或函数的附加信息，例如它的用途，它的类型，或者它的返回类型。 无意中这也回答了我关于 FreeRTOS 命名约定的问题。现在我明白了！他们也使用[主要是系统]匈牙利符号。这里有一些链接。请注意，在第一个链接中，您将看到 FreeRTOS 中所有匈牙利符号用法的列表。这种表示法几乎完全是 Systems Hungarian 表示法，但可以说在指定 文件名 时也使用了一点 Apps Hungarian 表示法，其中在函数或宏名称中定义了函数和宏。 FreeRTOS Hungarian Notation what is v and x means in freeRTOS task creating or used in it? https://www.freertos.org/FreeRTOS-Coding-Standard-and-Style-Guide.html#NamingConventions 匈牙利符号有两种主要形式：Systems Hungarian 和 Apps Hungarian。查看他们的差异here。 Systems Hungarian 本质上是对“匈牙利”符号的原始意图的破坏，该符号的创建者 Charles Simonyi 在他的描述中错误地使用了“类型”一词而不是“种类”（ source)。 Charle 的初衷是将附加信息编码为编程语言本身不固有的变量名。但是，Systems Hungarian 表示法基本上表示将变量的 type 存储到变量名中。例如：unsigned long myVar 现在变为 unsigned long ulMyVar。大多数人似乎认为这是有限的使用或完全没有价值。 Joel Spolksy 不支持这种形式的匈牙利符号as indicated in his article，但他支持 Apps Hungarian 风格。其他意见可以在"Notable opinions" section of the Wikipedia article here中找到。 Apps Hungarian 描述了将附加信息存储到变量名称前面的概念，否则很难推断出这些信息，例如使用 us 表示“unsafe string”和s 表示“安全string”。许多人要么对这种方法感到更中立，要么喜欢并推广它。 Joel Spolsky（Stack Overflow 的首席执行官）和 Steve McConnel 都认为这是一个好主意并推广它的使用。

注意，这是来自Joel's article 的有用摘录：

有人在某处读过 Simonyi 的论文，他在其中使用了“类型”一词，并认为他的意思是类型，就像类，就像在类型系统中一样，就像编译器所做的类型检查一样。他没有。他非常仔细地解释了“类型”这个词的确切含义，但没有帮助。伤害已经造成。

Apps Hungarian 有非常有用且有意义的前缀，例如“ix”表示数组的索引，“c”表示计数，“d”表示两个数字之间的差异（例如“dx”表示“宽度”），等等。

Systems Hungarian 有用处不大的前缀，例如“l”代表 long，“ul”代表“unsigned long”，“dw”代表双字，也就是说，实际上，呃，一个无符号长。在 Systems Hungarian 中，前缀告诉您的唯一信息是变量的实际数据类型。

这是对西蒙尼的意图和做法的微妙但完全的误解......

（强调）

【参考方案2】：

在此命名约定中表示无符号单词。现在几乎不用了。但是有些人喜欢它，因为它向他们展示了变量的类型。其他人讨厌争论这是最糟糕的编程习惯之一（包括 Stack Overflow 的创建者）。 海事组织没关系

【讨论】：

可能值得一提的是，不喜欢通常仅限于将变量名称中的变量类型编码为编码约定，但类型系统未捕获的编码信息被视为更有用（特别是如果经过深思熟虑），详见此处：joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong

您的链接是我在回答中提到的 SO 创建者的意见。 IMO 很麻烦，通常问题来自其他地方。如果编码人员知道他在做什么并且选择的命名约定对他来说更容易，我没有任何反对意见。我反对其中的任何***。 （顺便说一句，许多理论***分子在现实生活中都是可怕的程序员）