沁恒微蓝牙 TMOS 外部中断唤醒时间问题

再来讨论一下官方示例中 TMOS 的低功耗唤醒时间 ...... 矜辰所致前言之前我们说明过沁恒微 蓝牙 TMOS 休眠流程及休眠时外部中断的使用然后也以 CH585 为例介绍测试过 TMOS 低功耗模式下串口通讯同时也说明了官方例程中 CH585 与 CH592 中休眠函数的区别。之前的文章我们测试下来 CH585 官方示例中休眠唤醒后要 20ms 串口才能收到数据最近博主正好测试了一下 CH592发现不需要那么长的时间2 ms 就可以。所以本文我们再来看看 CH585 TMOS 休眠下时间较长这个问题。相关博文沁恒微 蓝牙 TMOS 休眠流程及休眠时外部中断的使用沁恒微蓝牙 TMOS 低功耗模式下串口通讯CH592 与 CH585 TMOS 中休眠函数的区别.我是矜辰所致全网同名尽量用心写好每一系列文章不浮夸不将就认真对待学知识的我们矜辰所致金石为开目录前言一、 CH592 TMOS休眠下的串口通信1.1 测试框架1.2 CH592 接收数据时间二、 再看 CH585 休眠函数三、 其他说明结语一、 CH592 TMOS休眠下的串口通信1.1 测试框架有过之前文章《沁恒微蓝牙 TMOS 低功耗模式下串口通讯》中的测试我们直接把接收端换成 CH592使用串口自己唤醒我们测试的框架如下图需要添加的代码和之前的 CH585 代码一摸一样只是需要在 CH592 EVT 的 Peripheral 工程上修改即便是一样的我还是上传了一份 592 上面的 下载地址: https://gitee.com/qzh_projects/CH58x/tree/master/以完整示例为准下图只是一个简单框架然后发送端就使用原来的 CH585 程序最后整体测试结果图示1.2 CH592 接收数据时间上面发送端的代码延时了DelayMs(22);是当初在 CH585 上面测试的结果现在到了 CH592 我把时间放短了唤醒后我只延时了 2 ms 都能够正常接收到数据直到我减少到 1ms 才出现前面几个字节收不到的情况如下所以这里基本就确定官方 EVT 代码CH592 上外部中断唤醒后的外设能起来工作的时间很短很短。那么 CH585 为什么那么长时间呢二、 再看 CH585 休眠函数们回过头再来看看 CH585 的休眠函数这里我直接上一下导致唤醒时间长的分析一下内容为个人分析仅供学习参考本意是等待 1.4ms 等晶振稳定但是这里因为主频修改导致延时时间放长出了这种情况延时函数如下为了做测试所以我回头直接把之前的Peripheral _uart_sleep_2工程里面的延时部分修改了一下代码如下/* 10. 判唤醒源不是 RTC 唤醒 */if(!(R8_RTC_FLAG_CTRLRB_RTC_TRIG_FLAG))//非RTC唤醒{// 注意此时32M还需等待稳定也可执行一些时钟要求不高的代码// DelayUs(1400);uint32_ti1400;do{__nop();}while(--i);SetSysClock(SYSCLK_FREQ);// 重新配置系统主频SYS_RecoverIrq(irq_status);// 恢复中断此后才会进外部中断 ISRreturn0;}然后还是使用唤醒后 2ms 的发送果然可以了这个 CH585 上怎么会多一个空格还有之前也遇到过的就是前面发送的用于唤醒的any data数据偶尔能够读出来这个是细节问题在实际应用中可以使用很多方式去处理掉前面不需要的数据这里只是说明一下串口收发只是一个方面通过代码可以知道只要是非 RTC 唤醒都得需要DelayUs(1400);那么时间都需要等待 接近 20ms 的样子。三、 其他说明在休眠函数CH58x_LowPower中还有一个提前唤醒// 提前唤醒if(timeWAKE_UP_RTC_MAX_TIME){time_tigntime(RTC_MAX_COUNT-WAKE_UP_RTC_MAX_TIME);}else{time_tigntime-WAKE_UP_RTC_MAX_TIME;}其宏定义为#ifndefWAKE_UP_RTC_MAX_TIME#defineWAKE_UP_RTC_MAX_TIMEUS_TO_RTC(1600)#endif在某些特殊情况下比如有外部晶振起振慢导致跑流程会出问题可以增大这个提前唤醒的宏定义让芯片提前唤醒有更多的时间起振稳定比如下面就是加时间#defineWAKE_UP_RTC_MAX_TIMEUS_TO_RTC(16001000)但是这样会导致功耗变大因为睡眠的时间就少了嘛。结语本文通过对 CH592 休眠下的串口通信测试发现的时间问题回头再看了看 CH585 下的休眠函数做了一些修改测试 。个人观点仅供大家参考。好了本文就到这里。谢谢大家