rtel wrote on Friday, September 27, 2013:
- Looking at the case where a timer is started, which handles the return value of prvInsertTimerInActiveList():
When xTimerStart() is called a message is sent to the timer task. The xMessageValue member of the message is set to the tick count to mark the time at which the message was sent. When the message is handled prvInsertTimerInActiveList() is called with xNextExpiryTime calculated as the time the message was sent plus the period, and xCommandTime set to the time the message was sent. These two parameters are used to determine if the timer expired between the message being sent and the message being processed.
- Looking at the case you highlight where the period of a time is changed. Semantically it is difficult to know what changing the period of a timer means - relative to what because the new period could be longer or shorter than the old period? In this case changing the period of a timer causes the timer to restart afresh.
When xTimerChangePeriod() is called a message is sent to the timer task. The xMessageValue member of the message is set to the new period value (note this was not the case when the timer was started). When the message is handled prvInsertTimerInActiveList() is called with xNextExpireTime set to the current time plus the timer new period, and xCommandTime set to the current time. Therefore the next expiry time can only be in the future because zero is not a valid timer period - as the expiry time can only be in the future prvInsertTimerInaCtiveList() will never return without placing the timer in a list, so there is no fail case to handle.
Do you agree with this? If so, I don’t think there is a bug, but please let me know if you are thinking of a different scenario.