[参考译文] TM4C1294KCPDT：MUX 解码具有 GPIO 引脚0 (6)、ENcode 用于 APB 而不是 AHB

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/681439/tm4c1294kcpdt-mux-decodes-have-gpio-pin-0-6-encodes-are-for-apb-not-ahb

数据表在下面的语句中保留了一个字 、也许会导致  GPIO 引脚0被定义、而不是 调用中指定的特定引脚编号。  (PIN_MAP.h)的 Tivaware DMUX 值 全部设置为 GPIO 引脚0、并且应为  GPIOPCTL 0x524的 REG22中设置的物理 GPIO 引脚值。  当  通过目视检查方法调试源时、GPIOPCTL 中不应发生任何会引起任何人质疑(PIN_MAP.h)的定义。 GPIO 引脚的多路复用器解码值 必须是静态表条目 、因此通过目视检查快速检查 可以将正确匹配与呼叫中的可视端口值相关联。 为什么 地球上的任何人都会 推推推 GPIO 引脚多路复用器值的移位、这超出了任何合理 的逻辑。

下面的远距离示例是针对 PWM M0FaultN MUX 配置进行 GPIO 解码的示例、目视检查 表明 GPIO 引脚0配置(6)与数据表23.2 PWM 模块匹配。 任何人首先认为这是不对的，然后看看 GPIOConfigure() ， 划伤头在 他们的座位上。  任何曾经信任 过 GPIOPinConfigure()的人都必须显式进入 CCS 调试并验证任何一个 GPIOPCTL (PIN_MAP.h)将实际移位的 GPIO 引脚编号 定义为调用瓶胚的最后一步？？？？ 如果调用中的最后一部分 螺丝向上 移动 GPIO 端口 MUX 定义的位、那么奇怪的事情开始发生了、不发生！

GPIOPinConfigure (uint32_t ui32PinConfig)
｛
uint32_t ui32Base、ui32Shift；

//
//检查参数。
//
assert ((((ui32PinConfig >> 16)& 0xff)< 18)；
assert ((((ui32PinConfig >> 8)& 0xe3)= 0)；

//
//从输入值中提取基址索引。
//
ui32Base =(ui32PinConfig >> 16)& 0xff；

//
//获取 GPIO 模块的基址，选择 APB 或
//适当时 AHB 孔径。
//
if (HWREG (SYSCTL_GPIOHBCTL)&(1 << ui32Base))
｛
ui32Base = g_pui32GPIOBaseAddrs[(ui32Base << 1)+ 1]；
｝
其他
｛
ui32Base = g_pui32GPIOBaseAddrs[ui32Base <<1]；
｝

//
//从输入值中提取移位。
//
ui32Shift =(ui32PinConfig >> 8)和0xff；

//
//为此 GPIO 引脚写入请求的引脚复用值。
//
HWREG (ui32Base + GPIO_PCTL)=((HWREG (ui32Base + GPIO_PCTL)和
~(0xF << ui32Shift))|
(((ui32PinConfig & 0xF)<< ui32Shift))；
｝ 

23.2信号说明：
 括号(6)中的数字是必须编程到 GPIO 端口控制中的 PMCn 域中的编码
(GPIOPCTL)寄存器(785页)将 PWM 信号分配给指定的 GPIO 端口管脚。

#define GPIO_PF4_M0FAULT0 0x00051006
#define GPIO_PK6_M0FAULT1 0x00091806
#define GPIO_PK7_M0FAULT2 0x00091C06