[参考译文] TM4C129ENCPDT：TivaWare 下一版本的建议

项目1：

TivaWare 提供一个带有变量 ROM_TimerConfigure()和 MAP_TimerConfigure()的函数 TimerConfigure()。

这是一个很好的功能、但是如果你想要"拆分"定时器(例如、使用一个32位定时器作为两个16位定时器)、你必须在同一个调用中配置两个半周期。 否则、如果配置一个半计时器、例如在一个源代码模块中、然后在另一个源代码模块中配置另一个半计时器以供另一个使用、则稍后的配置将撤消部分或全部先前的配置。

为了解决这一问题并允许我的软件独立配置半定时器，我制作了一个名为 TimerConfigure()的经过修改的副本，称为 TimerConfigureHalf()。 此函数的用法与 TimerConfigure()类似，只是由于函数本身就暗示了这一点，因此无需指定 TIMER_CFG_SPLIT_PAIR。

我建议在 TimerConfigure()上面的文档块中提到它会影响定时器的两个部分。

下面是我在 TM4C129ENCPDT 和 TM4C123AH6PM 上使用的 TimerConfigureHalf()函数。 它对我来说可以正常工作、但我只对它进行了测试、因为它与我的应用有关、所以请仔细查看！！

/*！ \brief 在作为一个分离对运行时配置一个半定时器。

使用此函

数而不是 TivaWare 提供的 TimerConfigure()，因为该函数强制在同一调用中配置定时器的两个部分。 使用对该函数的两次调用
分别配置每个半定时器会导致较低的配置被
后面的配置占用。

半定时器在被配置前被禁用并且保持
在禁用状态。

根据
使用的 TM4C 器件的可用性、\param[in] ui32计时器外设的基址、如下所示之一：
TIMER0_BASE、TIMER1_base、TIMER2_base、TIMER3_base、
TIMER4_BASE、 TIMER5_base、TIMER6_BASE、TIMER7_BASE、
WTIMEER0_BASE、WTIMEER1_BASE、 WTIMEER2_BASE、
WTIMEER3_BASE、WTIMEER4_BASE、WTIMEER5_BASE。

\param[in] ui32计时器、要配置的半计时器是
TIMER_A、TIMER_B 之一

\param[in] ui32Config 配置掩码。 如果配置 Timer_A、则
会执行以下操作之一：TIMER_CFG_A_ONE_SHOT、TIMER_CFG_A_ONE_SHOT_UP、
TIMER_CFG_A_PERIODICRACY_UP、TIMER_CFG_A_PERIODICY_UP、TIMER_CFG_A_CAP_COUNT、
TIMER_CFG_A_CAP_COUNT_UP、TIMER_CFG_A_CAP_TIME、TIMER_CFG_A_CAP_TIME_UP、
TIMER_CFG_A_PWM、可选择按位或与
TIMER_CFG_A_ACT_TOINTTD、TIMER_CFG_A_ACT_NONEO、TIMER_CFG_A_ACT_TOGGLE 之一进行逻辑或 CFG_RAT_RAT_COUNT_CTLE
设置 TIMER_CFG_A_ACT_SETTOGTO、
TIMER_CFG_A_ACT_CLRTOGTO、TIMER_CFG_A_ACT_SETCLRTO 或
TIMER_CFG_A_ACT_CLRSETTO。 类似地、如果配置 Timer_B、则替换
上述的 B 变体。
/void
TimerConfigureHalf (uint32_t ui32Base、uint32_t ui32Timer、uint32_t ui32Config)
｛
assert (_TimerBaseValid (ui32Base)))；
assert ((ui32Timer = timer_A)||(u32Timer_B = timer_A






)|(u32_uCFG = uTI_timer_A)|(u32_timer_uCFG = u32a

)|(u32_uTI_timer = u32_uCFG (u32_u_u_uCFG)= 1)= u32_u32_uFF_u= u32_uCFG (u32_u= uCFG (u32_uCFG)|(u32_u32_u32_u32_uCFG (uTI_u= u32_timer = u32_uCFG)= u32_u ||
((ui32Config & 0x000000ff)=TIMER_CFG_A_PERIODICY_UP)||
((ui32Config & 0x000000ff)=TIMER_CFG_A_CAP_COUNT)||
((ui32Config & 0x000000ff)=TIMER_CFG_A_CAP_UP (u32_CFG_TIME_CFG_=





)|= TIMER_CFG_TIME_CFG_TIME_TIMER (u32_CFG__CFG_W_TIME_TIME_CFG_= 0x000000FF)|= TIMER_CFG_TIME_CFG_TIME_TIME_TIME_TIME_CFG_=(uCFG_TIME_CFG_TIME_TIME_TIME_TIME_TIME_CFG_0x000000_TIMER)|=(uCFG_TIME_CFG_TIME_CFG_TIME_TIME_TIME_TIME_CFG_TIME_TIME_TIMER)|
~(uCFG_TIME_CFG_0x000000_TIME_TIME_CFG_

//将定时器配置的全局部分设置为分离对
HWREG (ui32Base + TIMER_O_CFG)= TIMER_CFG_SPLIT_PAIR >> 24；

//如果
(class_is_TM4C129){
HWREG (ui32Base + timer_O_Tamr)=(
((ui32Config & 0x000f0000)>> 4)|
(ui32REG & 0xff)|
timer_Tamr_TA32E



+ PWMIPS (u32Config +
))+(uPWMIPS




)+(u32r + tumiConfig)+ tumiTAMIE)，则设置半定时器的配置并设置 TxPWMIE 位 (ui32Timer = Timer_B)｛
assert (
(((ui32Config & 0x0000ff00)= TIMER_CFG_B_ONE_SHOT)||
((ui32Config & 0x0000ff00)= TIMER_CFG_B_ONE_UP)|
(u32_CFG_TIME_CFG_= 0x0000FF00




)|(uCFG_UCFG_TIME_C= 0x0000FF_CTRUCFG_UCFG_UCFG_UFF00)|(= 0x0000_TIMER_CK_TIMER_TIME_CTRY_CK_TI_CFG_UCFG_UCFG_UCFG_UCFG_UCFG_UCFG_UCFG_UCFG_UFF00)|(= 0x0000_TIME_TIME_CTRY= 0x0000_CFG_UCFG_UCFG_UCFG_UCFG_UCFG_UCFG_UCFG_TIME_TIME_TIME_TIME_TIME_TIME_TIME_TIME_TIME_TIME_TIME_CFG_TIME_CK_TIME_ == TIMER_CFG_B_CAP_TIME_UP)||
((ui32Config & 0x0000ff00)== TIMER_CFG_B_PWM)
；

//禁用计时器
HWREG (ui32Base + TIMER_O_CTL)&=~(TIMER_CTL_TBEN)；

//将配置的全局部分设置为 HWREG
(uCFG_24)+ TIMER_SPLIT (split_CFG_TIMER_CO_CO_PAIR)

//如果
(class_is_TM4C129){
HWREG (ui32Base + timer_O_TBMR)=(
((ui32Config & 0x00f00000)>> 8)|
(((ui32Config >> 8)& 0xff)|
timer_TBMR
)，则设置半定时器的配置并设置 TxPWMIE 位
。}
否则｛
HWREG (ui32Base + TIMER_O_TBMR)=(
((ui32Config >> 8)& 0xff)|
TIMER_TBMR_TBPWMIE
)；
｝

｝// TimerConfigureHalf

项目2：

我们使用 map_-prefixed 函数。 据我了解、大多数映射到 TM4C12x 的 ROM、除非 ROM 函数已被 TivaWare 中的更新版本取代、否则 MAP_PREFIXED 版本将映射到未预先修复的已编译到闪存版本。

但我注意到，有些函数似乎缺少 map_prefixed 版本。 例如，TivaWare 不提供 MAP_TimerUpdateMode()。 我不知道这是故意的、但它会导致几个小问题：(1)我不记得哪些函数缺少 map_prefixed 版本、因此会导致额外的编译-错误-修复-编译周期； 此外(2)我的代码中看起来像是错误、因为它看起来好像我在一个函数调用中忘记了 MAP_前缀。

只要我发现函数缺少 map_prefixed 版本、我就添加了一个。 它只是一个定义、用于解析非预定义版本、但它为我节省了一些麻烦。 我建议为每个 TivaWare 函数提供一个 map_-prefixed 版本。

项目3：

由于我不记得的原因、我需要我的程序代码来查询计时器当前是启用还是禁用。 因此我添加了一个 TimerIsEnabled()函数：

/*！ 简要检查定时器外设是否已启用

\param[in] ui32定时器外设的基址(
timer*_BASE 定义的一个)

\param[in] ui32定时器在外设中启用哪个定时器(
\b timer_A、\b timer_B、 或\b timer_both)

\如果启用了计时器、则返回 true、如果禁用则返回 false
*/
bool TimerIsEnabled (uint32_t ui32Base、uint32_t ui32Timer)
｛
uint32_t TMrOCtl；
uint32_t Expected；

//检查参数
assert (_TimerBaseValid (ui32id)(ui32b
)= uTimer= u32b)|(uTimer= ui32b)|(uTimer= ui32b)= uTimer= uTimer= u32b)|(uTimer= uTimer= u32u32b)|(u

//确定指定的定时器是否被/被启用
TmrOCtl = HWREG (ui32Base + TIMER_O_CTL)；
Expected = ui32Timer &(TIMER_CTL_TAEN | TIMER_CTL_TBEN)；

return ((((TmrOCtl & Expected)= Expected))？ True：false；
｝// TimerIsEnabled

项目4：

GPIOPadConfigSet()包含多个用于配置仅出现在 TM4E111和更高版本器件类上的寄存器的 for 循环。 这些 for 循环附近的注释指出、这是对旧器件的无害写入。

如果程序代码只在初始化时调用 GPIOPadConfigSet()，那么这并不是一个大问题，但我的代码有时会由于各种原因而即时更改引脚配置。 为了提高性能、我用对 class_in_TM4C129的检查将这些 for 循环打包在一起、以避免不必要地执行该代码。

[引用用户="Ralph Jacobi"]

您好、12月12日下午、

非常感谢这些建议！

关于项目#2、我认为所发生的是在 ROM 冻结后添加的新函数未获得 MAP_前缀、这可能是因为忘记了添加。 我这样说是因为我甚至不想将 MAP_前缀添加到我们添加的三个新 API 中。 :)将其放在待办事项列表中。

关于项目4：这似乎是合理的、我不会看到添加它有问题。 将进一步调查。

我喜欢 TimerConfigureHalf 的想法、并将对此进行更深入的研究。 无论采用哪种方法、我们都可以更新有关同时配置两个计时器的需要的文档。

在评论之前、需要进一步研究#3。

[/报价]

当然可以。 如果您有任何疑问或需要更多信息、请告诉我。 如果我想了解其他内容、我会将其发布在这里。

谢谢

您好、12月12日下午、

2号和4号已经被执行(嗯、4号需要进行测试构建、正如我刚才所做的那样、但是它将是！)

说到#4、看起来这不是 TivaWare 中的目标、但它并没有正确地被排除在公共编译之外。 哎呀。

对于#3、我不确定添加该 API 有多大价值、但我将在下一次审查会议中由 Bob/Charles 进行运行。

我们还将回顾并讨论#1、然后再讨论。

作为#2的副作用、我还注意到我们的许多 TivaWare 示例使用 ROM_而不是 MAP_调用、因此也要尝试清理它。

[引用用户="Ralph Jacobi"]

说到#4、看起来这不是 TivaWare 中的目标、但它并没有正确地被排除在公共编译之外。 哎呀。

[/报价]

你确定吗？ 我认为这些环路适用于 TM4C129器件。

[引用用户="Ralph Jacobi"]

对于第一个问题、我们在这个问题上处于了关键位置、因为我们可以看到这个问题的价值、但到目前为止、我们还没有遇到任何客户因这个问题而遇到的真正问题。

[/报价]

我除外。 :-)

[引用用户="Ralph Jacobi"]

不过、您努力实现这项功能、然后分享这项功能、这一点非常值得赞赏。 我们现在决定在即将发布的 TivaWare 中不会实现该功能、但我们会在资源列表中为该帖子添加书签。 如果我们最终发现我们在评估它的效用时出错、那么我们可以在将来再次考虑它。

[/报价]

足够公平。 感谢您的考虑。

[引用用户="Ralph Jacobi"]

再次感谢您提出#2和#4、因为这些是我们可以做出的重大改变、如果您不提出这些改变、我们将完全错过这些改变。 我最后总共增加了24个 MAP_函数。