Possible Cortex-M tickless idle OBO’s

Atmel SAM4S (CM4), FreeRTOS 7.4.2, Atmel Studio (GCC) In port.c, the systick reload value is calculated thus:
 ulTimerReloadValueForOneTick = ( configSYSTICK_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL; [code]
... which makes sense according to the datasheet (SAM4S), but later, the code calculates how many 'normal' tick periods have passed in an extended sleep time:
[code]
/* Something other than the tick interrupt ended the sleep.
Work out how long the sleep lasted. */
ulCompletedSysTickIncrements = ( xExpectedIdleTime * ulTimerReloadValueForOneTick )  - portNVIC_SYSTICK_CURRENT_VALUE_REG;
/* How many complete tick periods passed while the processor
was waiting? */
ulCompleteTickPeriods = ulCompletedSysTickIncrements / ulTimerReloadValueForOneTick;
[code]
In each of these calculations, shouldn't [b](ulTimerReloadValueForOneTick + 1)[/b] be used instead of  [b]ulTimerReloadValueForOneTick[/b] due to the fact that the period is actually one more than the reload value?
This hasn't caused any issues that I know of so far and the reload values are usually quite large so the error is small, but I thought I would ask/point this out. 
Thanks. 

Possible Cortex-M tickless idle OBO’s

Atmel SAM4S (CM4), FreeRTOS 7.4.2, Atmel Studio (GCC) In port.c, the systick reload value is calculated thus:
ulTimerReloadValueForOneTick = ( configSYSTICK_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL; 
… which makes sense according to the datasheet (SAM4S), but later, the code calculates how many ‘normal’ tick periods have passed in an extended sleep time:
/* Something other than the tick interrupt ended the sleep.
Work out how long the sleep lasted. */
ulCompletedSysTickIncrements = ( xExpectedIdleTime * ulTimerReloadValueForOneTick )  - portNVIC_SYSTICK_CURRENT_VALUE_REG;
/* How many complete tick periods passed while the processor
was waiting? */
ulCompleteTickPeriods = ulCompletedSysTickIncrements / ulTimerReloadValueForOneTick;
In each of these calculations, shouldn’t (ulTimerReloadValueForOneTick + 1) be used instead of  ulTimerReloadValueForOneTick due to the fact that the period is actually one more than the reload value? This hasn’t caused any issues that I know of so far and the reload values are usually quite large so the error is small, but I thought I would ask/point this out. Thanks.
P.S Can someone delete the previous post with bad formatting?

Possible Cortex-M tickless idle OBO’s

Thanks for pointing this out – it is not the first time I have made similar errs, and probably won’t be the last.  There is also one other change that needs to be made to the tickless implementation in the circumstance that an interrupt other than the tick brings the MCU out of low power.  I will try and address these issues shortly. Regards

Possible Cortex-M tickless idle OBO’s

Thank you. I look forward to seeing the changes and learning from your implementation.

Possible Cortex-M tickless idle OBO’s

I have refined the implementation in all the ports: http://freertos.svn.sourceforge.net/viewvc/freertos/trunk/FreeRTOS/Source/portable/GCC/ARM_CM3/port.c?revision=1957&view=markup Regards.