Add function for return of Timer overflow counter (ticks).

[GoogleCodeExporter]

What change would like to see?

Add function ticks() that returns the timer0 overflow counter.
Here is the code inside wiring.c:

//--------------------------------------------
unsigned long ticks()
{
    unsigned long t;
    uint8_t oldSREG = SREG;
    cli();
    t = timer0_overflow_count;
    SREG = oldSREG;
    return t;
}
//--------------------------------------------

Why?

This function gives maximum accuracy and better granularity in time measurement 
and in timed based events. 

Would this cause any incompatibilities with previous versions?  If so, how can 
these be mitigated?

This function does not cause any incompatibilities.

Original issue reported on code.google.com by arkali...@gmail.com on 1 Sep 2011 at 12:57

[GoogleCodeExporter]

Can you give an overview of the use cases you imagine for such a function (i.e. 
cases you've run into where you needed the increased precision over micros())?  

In general, I'd rather avoid this sort of system and hardware dependent 
function, in favor of something with general meaning (i.e. micros()).  

Original comment by dmel...@gmail.com on 1 Sep 2011 at 2:49

• Added labels: Component-Core

[GoogleCodeExporter]

I have a project that a specific test must be done continuously, but the timing 
is very critical. The period is about 100 Hz but the critical is the 
accumulated error of time interval. To make things clear, lets say that I need 
to make something every 10 ticks (~97 Hz), eg at tick 100, 110, 120 etc... it 
is no problem to have an inaccuracy of +/-1 tick, but this inaccuracy must be 
not accumulative, for example 100, 111, 120, 131, 140... etc is OK. It is very 
easy to work with tick numbers instead of millis due to rounding errors and 
smaller numbers used. In addition, this function is faster than millis because 
has no additional calculations. 

I understand that this function will have different meaning in different boards 
(with different crystals) and also, the returning number will be somehow 
cryptical for beginners. From the other side the function is very small.

Original comment by arkali...@gmail.com on 1 Sep 2011 at 3:15

[GoogleCodeExporter]

1) millis() no longer does any math, so it is the same speed as the proposed 
new function.
2) millis() should not be accumulating error more than +/-1 ms.  Do you have 
evidence that it is doing so?  If so, I would count that as a separate bug...
3) I wish timer0_overflow_count had gone away when the fraction-based ISR was 
added, but so many people accessed timer0_overflow_count directly, I guess that 
was impossible.  Maintaining two 32bit counters in the ISR is pretty expensive.
4) Note that you too can access timer0_overflow_count directly (yes, this is 
counter to the way things should be done, these days...)

Original comment by wes...@gmail.com on 2 Sep 2011 at 12:07

[GoogleCodeExporter]

Thanks for the info. I will make some tests with millis to see the results.
Oh! I didn't notice that timer0_overflow_count is visible, but as you mention, 
this is not good practice to use this variable.

Original comment by arkali...@gmail.com on 2 Sep 2011 at 12:34

[GoogleCodeExporter]

It sounds like millis() or micros() should work for you, if you're working at 
100 Hz.  As westfw says, if they are accumulating error, that's a problem we 
should fix, but not necessarily a need for a ticks() function.  Do you agree?

Also, westfw, I don't think we kept timer0_overflow_count for compatibility 
with people accessing this internal variable but rather to use in micros().  I 
personally wouldn't have a problem with breaking code that relied on 
timer0_overflow_count, if there was a good reason to remove it.

Original comment by dmel...@gmail.com on 2 Sep 2011 at 2:26

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 16 Dec 2011 at 10:31

• Changed state: WontFix