This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
我觉得2530唤醒后工作时间的长短应该是和系统轮询及任务的处理时间有关；现在问题是系统醒来后工作时间太短，数据来不及获取并发送就又进入休眠了！
问下各位，在协议栈里是否存在某个参数或者函数可以更改或者设置唤醒后的工作时间吗？
OSAL_Clock里面
呵呵 谢谢，能具体点吗，是OSAL_Clock.c中哪个函数呢？
在这个文件内OSAL_PwrMgr.c 从void osal_pwrmgr_powerconserve( void )函数开始看
这个函数及里面调用的函数可以更改两次休眠之间的时间间隔吗？
我看过感觉里面的时间参数只是和睡眠时间有关，和休眠唤醒后到再次休眠这段时间没关系，望指教
休眠唤醒后到再次休眠这段时间是由系统时钟产生的 你顺藤摸瓜就明白了
哪有『唤醒后的工作时间』的说法，
唤醒后要等到事情都处理完了才会进入休眠状态吧，
怎么会来不及处理数据呢？
呵呵，你的观点我认同，因我是在弄低功耗下的串口通信。
这工作时间是我设想的，因为我在实验时发现串口根本来不及获取数据，即没有事情处理，就又进入休眠，更不要说可以发送串口数据了。
其实我说的那个工作时间是指怎么延长让串口去获取数据的时间，不知道我说清楚了没，O(∩_∩)O~
哦，
进入休眠模式是因为没有事件处理了，
我的做法是在规定时间内保持一直有事件状态，
就不会休眠了，
不知道可不可以这样做，
即
当要处理串口数据时，先设置串口工作时间
osal_start_timerEx(GenericApp_TaskID,UART_TIME_EVENT,2000); //假如是2秒时间
并设置
osal_set_event( GenericApp_TaskID, DUMMY_EVENT);
DUMMY_EVENT在2秒定时UART_TIME_EVENT事件到时才清除，这样又可以进入休眠模式，
而在这2秒时间内始终有DUMMY_EVENT事件，不会进入休眠
谢谢你的详细解答，你的想法不错。
但我觉得串口事件是系统事件，不能简单的作为一个周期性事件吧？
