关于Gpt测不准问题
-
Gpt有两个通道：
TRM0-CH0: 无限循环，自由计数
TRM0-Ch1; 设置为50ms一次中断。测试方案：
用通道0检测通道1中断的准确性。软件平台：
threadx做os，官方例程修改// 点灯线程 void App_Led2(ULONG thread_input) { while (1){ Dio_FlipChannel(DioConf_DioChannel_D18_PTA20); /* toggle D18 */ tx_thread_sleep(100); } } // 通道1中断通知 void Gpt_Tmr1Ch1Notification(void) { debug_time[2] = Gpt_GetTimeElapsed(0)/50; // 读计数值转为us Gpt_StopTimer(0); Gpt_StartTimer(0, 0xffffffff); // 重启定时器 } // 定时器初始化 // 通道0：通用计数，不产生中断 Gpt_StartTimer(0, 0xffffffff); // 通道1：50ms定时 Gpt_StartTimer(1, 50*50000U); // 定时周期=50ms(定时器时钟=50M) Gpt_EnableNotification(1); // 使能定时器中断问题描述：
如果线程中的tx_thread_sleep(100)改为10即10ms时，测时很准就是50ms周期与设计相符；
但如果设为100ms，则显示的测量值会在35ms-65ms之间波动，但平均值应该还是50ms。这种现象肉眼可见，不知道咋回事。卡了一下午无果。 -
问题终于锁定了！可喜可贺，复盘一下：
1 - 关闭OS，裸机跑(Mcal初始化后死循环)，定时器中断周期是准的；但也发现复位后居然没有自动开狗。
2 - 开启OS，定时器中断周期不准，标准50ms，实测会在35ms-65ms浮动。
3 - 开OS后，某些情况下中断周期也是准的，比如改改app调度周期。原因分析：
1 - platform模块修改定时器中断优先级，从0开始测试，一路测试到14，问题都不存在了，也就是优先级不能为15；
2 - 把例程中已开启的其它外设的中断都关闭，Gpt模块中未使用的外设也关闭，只保留这一路定时器中断；同样满足步骤1现象，不能为15.
3 - 据此分析，想不通原因，希望官方还是核时一下吧。 -
yxydoctor 收到你的工程后，我这边复现debug这个问题，root cause如下：
你工程中使用的ThreadX OS这个操作系统初始化时没有创建任何空闲任务（idle task），导致用户任务通过调用tx_thread_sleep()睡眠后，内核的PendSV_Handler中不清除自己的中断标志（因为没有ready的task需要执行），从而CPU长期执行任务切换检查的代码而不主动退出（仅在SysTick 1ms中断和APP1和APP2两个用户任务睡眠时间tineout后才退出）。如果这时候外设中断，比如本例中的pTMR_CH0的50ms定时中断的优先级与PendSV设置相同(都是15)，那么跟PendSV相同优先级的外设中断ISR将很难被执行（仅退出PendSV_Handler时才可能）。
用户任务睡眠时间越长，这种现象越严重，这也与你反馈的，10ms睡眠时正常（我这边测试5ms，1ms， 50ms，甚至APP2 task中不睡眠都是OK的，因为pTMR_CH0的定时周期为50ms），而100ms不正常（测试500ms睡眠的话，测量的时间周期偏差更大）。
因此，解决方案有如下两种：
- 将工程中所有用到的外设中断优先级配置为高于PendSV的优先级(Cortex-M系列CPU内核的中断优先级数字越小优先级越高)
- 给ThreadX OS创建一个Idle task，并将其优先级设置为最低0（ThreadX OS的stask/thread优先级数据越大优先级越高）
帮助没办法联网的电脑使用YCT
帮助改进和优化YT CONFIG TOOL，有机会抽取YTM32B1ME0 EVB哦...