[En-Nut-Discussion] ms / us problem in timer routines

[uprinz]

Bernd Walter-2 wrote:
> 
> You still need multiply the value with nut_delay_loops, so uint16_t
> isn't big enough to hold the intermediate result.
> Is the code really that big compared to 16bit on AVR?
> Of course cycles don't count, since it's about wasting cycles anyway.
> 
I am not shure... If you limit the valid range to a usable one than you
might stay in 16 bits.
So on an AVR with 10bit counter for systick you decode the counts per us and
just need to multiply by timeout value. Then you loop-compare until value is
reached (not to forget the overrun situation).
This stays in 16bit math. If you use an 8bit counter you stay in 16bit math
too.

On ARM/Cortex you have 32bit math available so it doesn't matter. But based
on counter calculation it will skip all those trimming and counting at the
beginning and you don't have to guess how many cycles your routine will
take.


Bernd Walter-2 wrote:
> 
>> On a slow architecture this will result less jitter caused by multiple
>> 8/16bit math.
> 
> Ok - that's a valid point.
> The cyceles required for the multiplication/division may be depended
> on the values.
> Nevertheless you still need enough space for the nut_delay_loops * us.
> 
No it isn't. If you calculate the counter value that is your destination for
timeout and then loop compare until that value is reached (or in interrupt
situation already has passed) your stay in width of the timer, so on AVR it
is 8 or 16bit. If you do an extra outer loop to allow more than only
0..1000us you could stay in 16bit to allow 65k us.


Bernd Walter-2 wrote:
> 
>> On fast machines the calculation could be done by using the system timer
>> actual value with the reload value taken into reference. Might be more
>> precise and spares the calibration loop at the timer_init.
> 
> Yes - I've often done delays using timers.
> 
This would eliminate parts of the jitter too. If you compare for timeout
target and an interrupt occurs, the timer still continues running, while a
hard NOP loop will stop. The only thing you have to keep in mind is, that if
the interrupt routine is longer than a complete timer reload cycle, you
might miss the exit point and wait twice as long. (I think I don't have to
explain that to you, Bernd. It's just in case someone else reads this and
might have a good idea)

On the other hand, who needs to use NutMicroDelay() in one part of his
software and extra long interrupt routines (time > systick time) in the
other? Doesn't make sense.

Ulrich 


-----
Best regards
Ulrich
-- 
View this message in context: http://old.nabble.com/ms---us-problem-in-timer-routines-tp31628195p31635290.html
Sent from the MicroControllers - Ethernut mailing list archive at Nabble.com.