[参考译文] TM4C1294KCPDT：重新启用边沿计数强制禁用中断。

从上限(TnILR)中减去另一个有趣的发现自由运行边沿计数值(TNV)、生成计数直到向量入口点、将在同一中断上下文中提供(0x0)。

然而、从另一个中断上下文(而不是边沿计数)发出的相同指令在更高频率优先级的组中断开始生效之前、CnMIM 操作器会提供非常准确的结果。 数据表似乎不完全 符合实际 情况、或者 NVIC 组 INT 优先级可能存在 任何人从未测试过的运行应用程序的问题。 供参考： 边沿计数 = 211每个 CnMIM 矢量调用对 NVIC 中断置为有效非常慢。 因此、在进入 CnMIM 中断上下文时、TNV 值应高于211个边沿、而不是0x0。

/*在递减计数模式中、可以
通过从
GPTMTBPR (预分频)
*和 GPTMTBILR 寄存器组合组成的值中减去 GPTMTBR *或 GPTMTBV 来获得输入*事件的当前计数。 /*

获取 GPTMTBV 自由运行计数值。 //
ui32TBVEdgeCount = HWREG (TIMER0_BASE + TIMER_O_TBV)；
//获取 GPTMTBILR 开始计数加载值，超时事件的上限*/
ui32TBILREdgeCount = HWREG (TIMER0_BASE + TIMER_O_TBILR)；
//确定 ISR 入口和 INT 边沿之间的累积。 */
ui32EdgeCount = ui32TBILREdgeCount - ui32TBVEdgeCount； 

您好 BP101：

 [引用 user ="BP101"]向下沿计数模式 根据设计会在超时时清除 GPTMCTL_TBEN 位，似乎 设计操作 也会 同时重置 CBMIM 中的 CBECINT 清除位。

 我不清楚你要做什么。 这是边沿计数模式。 如果没有边沿、则计数器甚至不会计数。 为什么它会超时？ 数据表显示：

"在递减计数模式中达到匹配值后、计数器将使用该值重新加载
在 GPTMTnILR 和 GPTMTnPR 寄存器中、并且由于 GPTM 自动清零而停止
GPTMCTL 寄存器中的 TnEN 位。"

因此、TnEN 被清零的唯一时间是发生匹配时、而不是发生超时时时。 我只能想象您将匹配计数设置为等于0或非常小的值。  

 

您好、Charles、

[引用用户="Charles Tsaaa"]因此，TnEN 被清除的唯一时间是发生匹配时，而不是发生超时时时[/引用]边沿计数模式 是对 CCP 输入信号的边沿进行计数。 因此、我不明白为什么您认为它不会计数或超时、即使在某些奇怪的情况下也是如此。

似乎我应该说的是匹配计数，而不是超时。 虽然这实际上 无关紧要、 在 匹配计数(0x1)调用一个捕捉事件中断后、NVIC 仍然忽略正在被置位或清零的 CBMIM。 该测试的优点(低于捕捉)证明了边沿计数保持不变、即使 NVIC 加速 较高频率优先级 以及  较低优先级组中的捕捉事件也是如此。 缺点是即使    使用 了 GPMT 500ms OneShot 计时器、NVIC 也会加速处理第1个和第2个上下文中断、从而降低 TBILR 值。 无法保证 任何加载计数值始终在中断矢量中产生相同的 OneShot 周期、因此超时也会受到影响。 NVIC 以 GPTM 定时器中断事件为代价引发了火灾。   

打样 TBILR TBV 也 会产生 (0x0)边沿、这些边沿在配置的捕捉事件的同一中断上下文中计数。 边沿计时模式也不会产生 稳定的边沿时间、这些值都是来自同一输入信号的、该信号用于计算非常相同的211个边沿。 边沿时间 TNR 和 TNV 在捕获事件的同一中断上下文中非常不稳定、因此不能用于确定 来自相同 CCP 正边沿输入信号的边沿时间。 基本上、计数/时间模式(递减计数)之间的所有变化都是 TnCMR 位设置、 ILR 装载值以及捕获事件和 匹配的中断清除方法。

[报价用户="Charles Tsaaa">在递减计数模式中达到匹配值后，计数器将使用该值重新加载
在 GPTMTnILR 和 GPTMTnPR 寄存器中、并且由于 GPTM 自动清零而停止
GPTMCTL 寄存器中的 TnEN 位。"[/quot]

不是 完全正确、因为 TnILD 位 在 POR 上默认清零。定时器将 在下一个时钟周期重新加载 TnILR (加载计数)。 如果 TnILD 位置位、 TnILR 将在下一个超时事件发生时重新加载。  TnILD   位清零时、也称为立即加载更新。 想知道    在 CCP 捕获中断事件 上下文中 TnILD 位是否对计数=(TNV - TnILR)产生任何影响？

[引用 user="BP101"]我似乎应该说匹配计数，而不是超时。

感谢您的澄清。 匹配计数和超时之间存在巨大差异。 如果输入为稳定状态、则计数器根本不会移动。 边沿计数的整个目的是对边沿进行计数、而不是对从一个边沿到另一个边沿的时间进行计数、在这种情况下很容易发生超时。  

再说一次、重点是数据表跳过一些细节、计时器仍会超时已配置的模式。 因此、当一个信号被应用到 CCP 时、输入超时将/确实发生、因为向下/向上计数增量与设定的值相匹配。 如果在边沿计数/时间模式中忽略 TnILD 位、则数据表必须明确地将此点清零、但不会将其清零。

由 CnMIM/TnMIM 位屏蔽的匹配/捕获事件可在计时器完成前一个计数周期时快速通知 NVIC。 TnILD 位的设置决定了在任何模式下何时重新加载。 与 POR 设置 TnILD 位0x0 (默认值)的情况一样、定时器随后重新加载(更新) TnILR"立即"、但仅在下一个时钟周期之后。 因此、计时器超时始终在事件匹配或事件捕获中断上发生、并且在任何一种模式下仅分别设置 TnMCINT 或 CnMCINT 位。

TnILD 位(置位)的用途通常是停止定时器负载更新、这种更新会对 CCP I/O 造成电气干扰、也可能导致故障、看门狗会在计数过程中从(干扰)重新加载计数值复位。 因此、PWM CCP 输出模式更容易给出 TnILD 位的设置、尤其是在产生高频 PWM 时。 TM3A 500ms OneShot 延迟进入第二个上下文时、即使 TnILD 位已置位也会卡住。

>>我只能将匹配计数设置为等于0或非常小的值。

如果匹配计数发生在事件匹配期间接近超时周期、则这会引发一个有趣的问题、"即使设置了 TnILD 位(下一次超时重新加载)"也可能会导致未记录的中断问题。 例如、在第1到第2个中断处理程序内禁用/重新启用 CnMIM 之前、CnMCINT 会在 NVIC 中重新挂起先前的抢占。 这将解释为什么 NVIC 忽略了 CnMIM 标志的启用/禁用....

[引用 user="BP101]*再说一次、重点是数据表会跳过一些细节、计时器仍会超时所配置的模式。 因此、当一个信号被应用到 CCP 时、输入超时将/确实发生、因为向下/向上计数增量与设定的值相匹配。 如果在边沿计数/时间模式中忽略 TnILD 位、则数据表必须明确地将此点清零、但不会将其清零。[/引用]

同样、如果您将超时作为匹配事件、那么根据您对超时的解释、这是可以的。 对我来说超时不同于匹配事件、尤其是在边沿计数模式下。 如果您有一个扁平线 CCP 输入、那么计数器永远不会递减、因为没有检测到边沿。 这与边沿计时模式下的超时时间远不相同、在该模式下、一旦检测到边沿、计数器就会继续递减计数。 如果下一个边沿从未出现、则定时器超时、因为它计数为零而不会看到边沿。 以下摘自数据表。

在递减计数模式中达到匹配值后、计数器将使用该值重新加载
在 GPTMTnILR 和 GPTMTnPR 寄存器中、并且由于 GPTM 自动清零而停止
GPTMCTL 寄存器中的 TnEN 位。 一旦达到事件计数、所有后续事件
被忽略、直到通过软件重新启用 TnEN。 在递增计数模式中、定时器重新加载0x0
并继续计数。

[引用 user="BP101]POR 会额外设置 TnILD 位0x0 (默认值)、然后重新加载(更新) TnILR"立即"、但仅在下一个时钟周期之后。 因此、计时器超时始终在事件匹配或事件捕获中断上发生、并且仅在任何一种模式下分别设置 TnMCINT 或 CnMCINT 位。[/引用]

我不明白您要做什么。 如果您想使用边沿计数模式、那么在您启用定时器之前、您是否不会先将 TnILD 中的负载计数设置为非零值(如在递减计数模式中)？ 为什么在递减计数模式中将 TnILD 启动为零、然后启用计时器？

有关边沿计数模式、请按照数据表中的说明进行操作。 在任何配置完成之前、TnEN 首先在步骤1中被禁用。 第5步、在第7步中再次启用 TnEN 之前配置加载计数和匹配寄存器。

13.4.3输入边沿计数模式
定时器按以下顺序配置为输入边沿计数模式：
1：在进行任何更改之前、确保定时器被禁用(TnEN 位被清零)。

2.向 GPTM 配置(GPTMCFG)寄存器写入0x0000.0004。

3.在 GPTM 定时器模式(GPTMTnMR)寄存器中、向 TnCMR 位域写入0x0、向 TnMR 位域写入数据
域设为0x3。

4.通过写 GPTM 的 TnEVENT 位域来配置定时器捕获的事件类型
控制(GPTMCTL)寄存器。

5.根据计数方向对寄存器进行编程：
■在递减计数模式中、GPTMTnMATCHR 和 GPTMTnPMR 寄存器配置为相同的值
注意 GPTMTnILR 和 GPTMTnPR 寄存器中的值与之间的差异
GPTMTnMATCHR 和 GPTMTnPMR 寄存器等于必须发生的边沿事件的数量
计数。
■在向上计数模式下、定时器从0x0开始计数到 GPTMTnMATCHR 和中的值
GPTMTnPMR 寄存器。 请注意、执行递增计数时、GPTMTnPR 的值
GPTMTnILR 必须大于 GPTMTnPMR 和 GPTMTnMATCHR 的值。

如果需要中断、将 GPTM 中断屏蔽(GPTMIMR)寄存器的 CnMIM 位置位。

将 GPTMCTL 寄存器的 TnEN 位置位、即可使能定时器并开始等待边沿事件。

8。查询 GPTMRIS 寄存器的 CnMRIS 位或等待中断的产生(如果使能)。
在这两种情况下、通过向 GPTM 的 CnMCINT 位写1来清除状态标志
中断清除(GPTMICR)寄存器。

在输入边沿计数模式下递减计数时、定时器在设定的数量之后停止
检测到边沿事件。 要重新启用计时器、请确保 TnEN 位清零、然后执行
重复步骤4至8。

[引用用户="Charles Tsaaaa">我不明白您要做什么。 [/报价]

您好、Charles、

提及 TnILD 是 POR 默认 (0x0) GPTM 计数行为的要点不会与 配置的其他模式发生任何变化。 同样、数据表中还保留了重要的计时器重载详细信息、 例如您认为为什么会忽略 TnILD 位。  

在边沿计数中断处理 程序周期中禁用定时器、在另一个 GPTM 延迟中断上下文中启用定时器。 然而 、随着 PWM0驱动直流逆变器、边沿计数速度增加、但是 匹配计数中断 的 值始终相同(TnBR)。  这个问题使得 难以理解  相同数量的边沿是如何加速产生 的、在计数器中断上下文之外的不同匹配计数时序。  CCP 输入源 在55Hz 以上没有变化、但是 PWM0 更高的频率(12.5KHz)以某 种方式触发禁用定时器中的边沿计数。 这使得重新加载相对于 TnILD 位设置的 TnILR 看起来是在 CCP 输入上引起了电气问题。  在 PWM 模式 部分中没有一个警告、在 CCP 上的这个电气噪声点。

然而、即使 移除 输入信号 CCP 和 将 GPIO 输入引脚接地、也仍然会发生订购边沿计数。  因此、在  中断 事件的禁用定时器周期内、CCP 边沿事件计数如何仍然发生毫无意义。   

[引用 user="BP101]\n 即使 删除 输入信号 CCP 和 接地 GPIO 输入引脚、仍需订购边缘计数。  因此、在  中断 事件的禁用定时器周期内、CCP 边沿事件计数如何仍然发生毫无意义。   [/报价]

我无法理解您描述的行为。 在 CCP 输入接地的情况下、您会得到一个边沿计数？ 您能在 LaunchPad 中重复一下吗？ 我真的不知道为什么您的系统的行为与 LaunchPad 有很大不同。 不幸的是，我没有提出任何建议。  

您好、Charles、

[报价用户="Charles Tsaa"]当 CCP 输入接地时，您得到的是边沿计数？

当    出现另外两     个 GPTM OneShot 开始计数、400us 和40us 周期时、CCP1 PL5内部触发相同的结果。   GPIOPinConfigure() 和(PIN_MUx.h)的唯一逻辑解释是如何 跨接 GPIOPCTL 寄存器或 数字多路复用器中的 CCPn 端口。  否则、在    其他两个计数器 每个 OneShot 触发的中断开始生效之前、不会发生"过度"触发的错误计数边沿。 这就是它 使它看起来像是一个中断 NVIC 优先级问题的原因。  我怀疑 其他两个定时器可以通过 GPIOPCTL 寄存器进行 CCPn 分配、例如在每个孔径的表面架构上。

下面 请注意 GPIOPinConfigure() 使 ui32Base = 0x0用于 CCPn 解码。    对     传递 的 ui32PinConfig 进行16个位置的所有 pin_mux.h CCPn 解码是否都正确移位(>>)？ 为什么不简单地为 所有解码创建 ui32Base 0x0？ 正如 论坛中的其他人报告的、SYSCTL_GPIOHBCTL 必须存在 TM4C1294、以选择 AHB 阵列解码 GPIO.c 端口 A-J/K-T 顶部的内部指针 数据表显示了具有 AHB 后缀的 GPIO、 但 GPIO.c 省略了端口 K-T  未保持 AHB 一致性数据表 PinMux 工具 和 /或 GPIOPinConfigure()槽口。 看起来 <16 使得 GPTM0B/CCCP1：0xA1403 = 0x00C00000、 >> 16移位0xA 的点是什么？  在 后来的行动中，也许实际的 ui32基础是谨慎的，而不是在下文中所述的行动？

我向 论坛报告了2015端口 K-T 省略  了 GPIO.c 表指针的 AHB 顶部、可能已添加到 Tivaware 的后续版本中。  这仍然 不允许 GPIOPinConfigure() 选择 APB 或 AHB 总线、 如方框图图图1所示。 显然、APB 仍然位于 AHB 槽旁边、两个总线分别连接到 GPIO/GPTM 外设。  

 [引用用户="Charles Tsaaa"]您描述的行为让我无法理解[/引用]

然而 、为什么对于 GPTM0B CCP1 (PIN_MUx.h) 0xA1403、ui32Base = 0x0？ APB 或 AHB 解码的基地址是如何的？

void
GPIOPinConfigure (uint32_t ui32PinConfig)
｛
uint32_t ui32Base、ui32Shift；

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

//
//从输入值中提取基址索引。
// 0x0适用于所有 AHB 管脚复用编码。
//
ui32Base =(ui32PinConfig >> 16)& 0xff；//CCP1 = 0xA1403 >> 16 = 0xA、& 0xff = 0xA 

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

[报价用户="Charles Tsaaa"]您能否在 LaunchPad[/quot]中重复此操作？

LaunchPad 首先出现问题、并欺骗我、它已部分 纠正 、但未纠正。  我的器件上的错误假设编码、   并且只通过在 OneShot 中断延迟期间将精度降低70%来屏蔽加速边缘计数问题。 当  一个模拟端口 AIN16也可能受到同样 的 GPIOPTCL 问题的困扰 、同时也影响 固定 CCPn 边沿计数的频率时、这显然不是一个实用的解决方案。  

问题似乎来自为  APB 槽上的 ui32Base 选择表项、而不是 AHB。   配置端口 A-J 可能无法 正确设置 GPIOPCTRL (REG22)位域、数字多路复用 器可能会进入模拟领域、反之亦然。  

假设 TM4C1294没有 GPIO_HBCTL 寄存器和(其他)默认值。 因此、为任何已配置端口 A-J 选择 APB 总线槽地址时、不会在 GPIO 多路复用器中获得所需的 GPIOPCTRL 条目。 因此，我们配置 了下面几个端口 K，但 似乎通过 GPIOPinConfigure()存在于 APB 槽中，除非 在下面进行了修补。  由于索引 0-20 (ui32Base=0xA/10)和 APB 端口 K 具有与 AHB 端口 K 相同的地址 、 因此从下表中选择 APB 地址时从未考虑到较低端口 A-J。

//
//
//所有 GPIO 模块的基地址。
提供 APB 和 AHB 孔径//。
////
*****************
静态常量 uint32_t g_pui32GPIOBaseAddrs[]=
｛
GPIO_Porta_base、GPIO_Porta_AHB_BASE、
GPIO_PORTB_BASE、GPIO_PORTB_AHB_BASE、
GPIO_PORTC_BASE、GPIO_PORTC_AHB_BASE、
GPIO_PORTD_BASE、GPIO_PORTD_AHB_BASE、
GPIO_Porte _BASE、GPIO_Porte AHB_BASE、
GPIO_PORTF_BASE、GPIO_PORTF_AHB_BASE、
GPIO_PORTG_BASE、GPIO_PORTG_AHB_BASE、
GPIO_Porth_BASE、GPIO_Porth_AHB_BASE、
GPIO_PORTJ_BASE、GPIO_PORTJ_AHB_BASE、
GPIO_PORTK_base、GPIO_PORTK_AHB_BASE、
GPIO_PORTL_BASE、GPIO_PORTL_AHB_BASE、
GPIO_PORTM_BASE、GPIO_PORTM_AHB_BASE、
GPIO_PORTN_BASE、GPIO_PORTN_AHB_BASE、
GPIO_PORTP_BASE、GPIO_PORTP0_AHB_BASE、
GPIO_PORTQ_BASE、GPIO_PORTQ0_AHB_BASE、
GPIO_PORTR_BASE、GPIO_PORTR_BASE、
GPIO_PORTS_BASE、GPIO_PORTS_BASE、
GPIO_PORTT_BASE、GPIO_PORTT_BASE
、｝； 

上面的(else)修补 程序校正了较低 A-J 端口地址的 GPIOPCTL 条目，这是对 GPIOPinCofigure()进行正确 AHB 调用所必需的。  以某种方式、补丁 会停止最后配置 的 ADC 通道 AIN16 (PK0)。 奇怪 的是 APB - AHB 地址 表指针 拆分的确切位置(J-K)。  根据数据表、如果 GPIOPinConfigure() 仅访问  AHB 地址范围 A-J、 那么 GPIOPCTL 不能 为 TM4C123端口 A-J 的 APB 索引地址范围设置位字段、这很简单。   在 Tivaware 调用 GPIOPinConfigure()和数据表图1-1时、主题 APB-AHB 被误导。   

 TM4C1294 数据表是否提供准确而详细 的地址范围 (GPIOPCTL REG22) 和 APB - AHB 通风口、如图1-1所示？  电气规范和 GPIO 文本确实与所有 GPIO 或 GPTM CCP 端口都被强制使用 AHB 相矛盾 、而图1-1 表明这些外设也可以访问 APB 槽。 如果图1-1 不 是实际的 GPIO、则不应将 GPTM 说明为仍然连接到 AHB 和 APB 通风口。

数据表文本 表示 REG22不能使用  (  GPIP.c)索引表指针顶部的 TM4C123下部 APB 孔径端口(A-J) 来调用 GPIOPinConfigure()。 GPIOPinConfigure() 和 AHB 槽地址表查找端口(A-J)需要  TM4C1294 MCU 中不存在的 GPIO_HBCTL 寄存器。  Tivaware 和数据表表示 永远不会触摸 GPIOPCTL 位字段、因为 APB 端口 A-J 是 GPIO_HBCTL、因此不存在。  同样 、CCS 调试也是解决问题的最后手段、而不是第一道防线、以证明数据表符合事实或不符合事实。

也许 TM4C1294数据表仅失真 APB-AHB 主题并 忽略了所需事实任何良好的检测必须修复怀疑导致硬件故障的软件问题？   也许 TI 选择了遵循不准确 的文档方法来处理 这些架构变化？

您好 BP101、

是的、数据表正确。 我已经在 以下网站上评论了您对 TM4C129x 器件上 APB 的担忧：https://e2e.ti.com/support/microcontrollers/other/f/908/p/782356/2922470#2922470

我想我理解您的混淆来源、它与 GPIO 端口定义的命名规则有关、我们在这些端口定义了 GPIO_PORTK_base 和 GPIO_PORta_AHB_BASE 等名称

 为什么 GPIO_PORta_AHB_BASE 通过 GPIO_PORTJ_AHB_BASE、然后从 GPIO_PORTK_base 以及之后 AHB_BASE 标签被丢弃、这是一个具有历史意义的原因。

根据我的调查结果、原始 Stellaris LM3S 器件在端口 J 停止运行、由于互操作性原因、在 GPIO_PORTJ_AHB_BASE 停止的命名规则被保留(当时不在团队中)、因为 TivaWare 最初是 StellarisWare。

不过、如果您看看 TivaWare 中的定义、您仍然可以看到从 GPIO_PORTJ_AHB_BASE 到 GPIO_PORTK_BASE_GPIO_BASE_REQ 完全遵循数据表：

#define GPIO_PORTJ_AHB_BASE 0x40060000 // GPIO 端口 J (高速)
#define GPIO_PORTK_base 0x40061000 // GPIO 端口 K

希望这有助于解决您对该主题的困惑、并帮助您再次对我们的数据表的准确性更有信心。

您好、Ralph、

您似乎错过了我的点、表左侧的 GPIOPinConfigure()端口(A-J)用于 TM4C123地址、并且被错误地选择用于配置 GPIOPCTL REG22。 同样、TM4C123中也存在 GPIO_HBCTL、因此调用 GPIOPinConfigure()默认为(else)、该调用会错误地从 GPIO_c 中的表中选择 APB 地址、而这些地址甚至在 TM4C1294中不存在。

首先配置的引脚类型(数字)无关紧要、但是我们必须从 GPIOPinConfigure()正确地为 TM4C1294 GPIO 的 REG22寻址、或者之前配置的引脚 A-J 将与 GPIO 模拟多路复用器重叠。 根据数据表地址映射披露、TM4C1294中的端口 A-J 的 GPIOPCTL 位字段未设置！

就 StellarisWare 而言、10636版是支持 LM3S MCU 的最后一个 driverlib。 Tivaware driverlib 与 LM3S MCU 不兼容

未披露 GPIO 端口地址 TM4C1294数据表存储器映射。

hw_memmap.h

#define GPIO_Porta_base 0x4000// GPIO 端口 A
#define GPIO_PORTB_BASE 0x40005000 // GPIO 端口 B
#define GPIO_PORTC_BASE 0x40006000 // GPIO 端口 C
#define GPIO_PORTD_BASE 0x40007000 // GPIO 端口 D
#define GPIO_Porte _BASE 0x40024000 // GPIO 端口 E
#define GPIO_PORTF_BASE 0x40025000 // GPIO 端口 F
#define GPIO_PORTG_BASE 0x40026000 // GPIO 端口 G
#define GPIO_Porth_BASE 0x40027000 // GPIO 端口 H
#define GPIO_PORTJ_BASE 0x4003D000 // GPIO 端口 J 

您好 BP101、

我想您已经从 Amit 看到了这篇文章、其中说我们删除了该注册、以便明确使用 AHB： e2e.ti.com/.../1316370

因此、TivaWare 工作正常、它不会默认为您所暗示的 TM4C129x 的 else 语句、但正如 Amit 在您之前和看到的一篇文章中所述、该寄存器未列在 D/S 中

很抱歉、我以为您已经看到并理解了这一点。

[引用用户="Ralph Jacobi"] 为什么通过 GPIO_PORTJ_AHB_BASE 连接 GPIO_PORTA_BASE_AHB_BASE、然后从 GPIO_PORTK_BASE_AND 开始、AHB_BASE 标签被丢弃的原因是一个具有历史意义的标记。[/QUEST]

AHB 不应该 被丢弃在端口 K 上、因为它是一个一直到 端口 Q 的 AHB 端口。 上面发布的阵列表顶部(GPIO.c)对于 TM4C1294地址映射是正确的、如数据表中所披露。  为什么在地球上 、当 K-Q 作为 AHB 存在时、任何人都以任何其他名称象征性地称呼 AHB 端口？  似乎  不会从索引中选择正确的 GPIO PCTL 地址字段。 我们必须在 else 中的每个移位中添加+1、以便在 TM4C1294的数组表中指定更高的地址范围 。  同样 、TM4C1294中不存在 GPIO_HBCTL 寄存    器、因此(IF)测试将传递给(其他)、并且在写入错误时、选择上面发布的 TM4C123的较低 APB A-J 地址。

if (HWREG (SYSCTL_GPIOHBCTL)&(1 << ui32Base))
｛
/* TM4C123 MCU 的 AHB 槽 GPIO 基址*/
ui32Base = g_pui32GPIOBaseAddrs[(ui32Base << 1)+ 1]；
｝
其他
｛
//将 TM4C1294的 AHB 孔径范围设置为
*端口数组索引中的 GPIO 基址。 *
ui32Base = g_pui32GPIOBaseAddrs[(ui32Base << 1)+ 1]；//[ui32Base << 1]
｝ 

模拟端口 似乎仍然正常工作 、但是  GPIOPCTL 和 GPIO 模拟多路复用器设置的数字隔离栅将与 A-J 重叠 、因为它们从未配置为数据表 GPIO 端口 地址映射所示。  如果 数据表中的 GPIO 端口地址映射不完整、 可能会说明 TM4C123 APB 槽地址(A-J)如何 仍然能够在 TM4C1294中设置 GPIO_PCTL。 这种欺骗不 是一种直观的做法、浪费可能会导致您/我们跟踪 CCP 内部边沿计数触发器问题！     

[引用 USER="Ralph Jacobi"]因此 TivaWare 工作正常、它不会默认为您所暗示的 TM4C129x 的 else 语句

很抱歉、不同意、但如果测试 无法 从 TM4C1294数据表 寄存器映射中未列出的寄存器中找到或返回 GPIOHBCTL 地址位字段、

[引用 USER="Ralph Jacobi"]我认为您已经从 Amit 看到过这篇文章，说我们删除了该寄存器，以便明确使用 AHB[/引用]

Amit 进行了重复 叙述、而其他 人则 PM 我 认为 Amit 推断的 GPIOHBCTL 在 TM4C1294中为只读状态、 但寄存器映射中仍然未列出。  

法律制度将 Amit 在论坛上所说的内容称为"传闻"、在任何美国法院都不认为可受理的证据。  也称为 非感知、假设、除事实以外的任何东西。 如果它不是以书面形式写入、则在微处理器逻辑门、存储器地址或特殊功能打开和打开时不存在。

其次、如果 SYSCTL_GPIOHBCTL 确实退出、它将作为 RO 存储器映射地址出现在 CCS 调试 GEL 文件中。

#define SYSCTL_GPIOHBCTL 0x400FE06C // GPIO 高性能总线控制 

您好 BP101、

进行了进一步的测试、结果有一些混合。 使用 TivaWare 构建以及直接包含的驱动程序库来调试 driverlib 函数、我检查了 GPIOPinConfigure API。 正如我所预期的那样、GPIOHBCTL 确实会返回一个值、但它会清除相关的 AHB 位以进行 GPIOPinConfigure 中的比较。 因此、我确实看到在 GPIOPinConfigure 结束时、它似乎正在配置寄存器0x4000.4000。 我需要进一步研究这一点、以了解对0x4000.4000进行编程时会发生什么情况。 我今天实际上不在现场、因此我明天将进一步调查。

不过、我要说的是正在进行的任何操作、如果您看到 PORta_AHB 寄存器配置、尽管基址不是"正确"、但它仍然得到了正确配置。 因此、我怀疑器件中有一个内部映射、任何进入0x4000.4000的内容都会被转发到0x4005.8000、以此类推其他端口。

您好、Ralph、

[引用 USER="Ralph Jacobi"]因此我怀疑器件中有一个内部映射、即0x4000.4000的任何内容都将转发到0x4005.8000、以此类推其他端口。

但 TM4C1294数据表中没有提及 省略 GPIOHBCTL REG22或 Amit 对海报的回答。 海报将 TM4C123G 代码 迁移到 TM4C1294。  然而、Amit 没有提到 AFSEL 位 和通过 APB 的 GPIOPCTL 、这似乎 会导致 AHB 上的低端口地址重叠。  

即使 CCP1 (PL5)输入接地、边沿计数也在内部触发(GPIOMUX)、似乎 与 AHB/APB 槽问题对齐。 您  提到的一个或多个内部映射可能 不正确？ 我们 通过 AHB 命名规则分配所有 GPIO 引脚类型、 端口 K-Q 缺少 Tivaware (v12753/v21171) (hw_memmap.h)。  仅在 论坛(2014年)报告后添加了 AHB K-Q、 AHB 地址缺失。  这可能会使您提到的内部映射失败吗？    根据图1-1、当端口实际使用 AHB 槽时、在应用中使用一些没有 AHB 的端口似乎很荒谬。  添加 K-Q 地址似乎是  TM4C123G 文本(下表)端口 K-Q 默认为 AHB 是一个显而易见的事情。 如果   两个 MCU 类别 都锁定到 AHB 槽中、为什么 Tivaware 未包含在(hw_memmap.h) AHB 端口 K-Q 中？  不是很重要 、除非 GPIO 名称很重要、端口地址映射也不重要。   

总之 、下面是 GPIO 端口的 TM4C123G 存储器映射 和 SYSTRL_GPIOHBCTL 寄存器检查。  

 PL5输入为集电极开路、 最初 具有外部20k pu +3v3 、但通过内部 WPU 产生相同的奇数边沿计数结果。 请注意、所有模拟输入 AMSEL 位字段均已通过验证、设置 正确、可从 CCS 调试寄存器视图中查看。

当  模拟信号上升到1400mV 以上时、模拟领域中的某些器件可能会影响 PL5数字隔离？ 我脑海中的问题 是：" 当模拟输入经证明  能够抵抗任何信号交叉 进入高达3V3的数字 GPIO 多路复用器时、这种情况会如何发生？"

任何人都会认为 、WPU 轨 与模拟/数字 GPIO 引脚多路复用器在内部隔离。  也许  某些其他 GPIO 引脚上的 WPU  可能会怀疑小于1400mV 的模拟信号如何 在  该过程中轻松旁路数字隔离栅？  同样、当接地时、PL5输入仍然对从49.5Hz 开始的边沿进行计数、并且 当  看似 PWM0 12.5kHz 或许多其他 GPTM/GPIO 引脚置为有效时、加速中断计数。 PL5 CCP1边沿计数 保持 准确的预期边沿数量 、但是随着  其它外设在 AHB 槽上开始有效的 GPIO 速度而加速。