Author Topic: TICK_RESOLUTION explanation.  (Read 5680 times)

Offline ssinfod

  • Newbie
  • *
  • Posts: 7
    • View Profile
TICK_RESOLUTION explanation.
« on: April 27, 2016, 01:55:04 AM »
Hello,

I'm using uTasker on the Coldfire M52233.
I have a question regarding this line from config.h:
  #define TICK_RESOLUTION 50

What are the "correct" values of this define ?
I'm planning to set TICK_RESOLUTION to 10 on the Coldfire M52233 with a 60 MHz clock.
Is there any problem to do this ? Would it also work if I set it to 1 ?

I see a comment on the same line but I don't fully understand its meaning and how it was calculated...
  // 50 ms system time period - max possible with M5223X at 60MHz (with prescaler) PIT would be about 70s!

Any explanations would be great.

Thanks
ssinfod

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: TICK_RESOLUTION explanation.
« Reply #1 on: April 27, 2016, 10:08:57 AM »
Hi

The TICK, defined in ms, is the period of the hardware timer's interrupt which is used to control software timers.
A value of 50ms is typically used since it allows software timer accuracy resolution on a 50ms raster, which is adequate for a lot of projects where software delays are not very short and the resolution of the shortest delay (50..100ms) is acceptable.

If the software only requires longer delays it would be possible to increase to a larger values but if the software requires shorter delays, with higher resolution, the value can also be reduced - down to 1. A value of 1 means that the software delays are defined in ms with a resolution of +0/+1ms - and the shortest SW delay would be 1ms (with accuracy 1..2ms, assuming the code that started the timer was not synchrinised to the TICK. If the code is synchronised to the TICK (eg. a software timer that fires is used to start another SW timer delay) the accuracy is also better).

The trade-off is that there is an interrupt at the TICK rate - higher accuracy requires a faster rate of interrupt, which means a little more CPU loading and also more wake up from low power mode in the process (if LP mode is used).

The software timers are based on a 32 bit value which means that the maximum delay reduces as the TICK period reduces. 4.2million seconds is max. at 1ms TICK and longer delays with larger TICK values - although this is rarely something that needs to be considered.

A PIT timer is used as TICK source for the Coldfire V2 project and the comment in the code is just stating that it would be possible to have a TICK of up to 70000ms with this timer due to the fact that it is a 32 bit timer. In comparison, some 16 bit HW timers will limit the maximum TICK to just several hundred ms at high clock rates. Therefore it is just stating that the PIT source s a very good one without any practical upper limits in this case.

Regards

Mark

Offline ssinfod

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: TICK_RESOLUTION explanation.
« Reply #2 on: April 27, 2016, 10:20:09 PM »
Mark,

I still don't understand where you get the 70000 ms in the comment.
Is it by dividing:  2^32 / 60000000 = 4294967296 / 60000000 = 71.58  seconds
 
Does it mean that we could use as a valid value: #define TICK_RESOLUTION 70000 ?


Finally, is there a relation between TICK_RESOLUTION and uTaskerMonoTimer ?
Let say that I set TICK_RESOLUTION to 10. Is there a maximum value for the uTaskerMonoTimer DELAY_LIMIT parameter ?

Thanks again,
ssinfod

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: TICK_RESOLUTION explanation.
« Reply #3 on: April 28, 2016, 09:52:05 AM »
Hi

You calculate 71.58 seconds maximum PIT period. Thsi is 71580 ms, which is about 70000ms (the comment rounds the value slightly).

Theoretically it would be possible to use a TICK_RESOLUTION of 70000 but it wouldn't be of much use.

Yes, the TICK_RESOLUTION directly determines the uTaskerMonoTimer resolution and the maximum possible timeout value is 2^32 * TICK_RESOLUTION if DELAY_LIMIT is an unsigned long.

Regards

Mark