Dear Albert ARIBAUD,
In message 4D3B568D.3080903@free.fr you wrote:
You see the problem?
Actually no, I don't. As a reminder, I am considering the following definitions:
#define time(n) (ticks-n) #define ms_to_ticks(ms) (ms * fast_tick_rate) / CONFIG_SYS_HZ
Ah, I see. Well, I have to admit that I did not see this part; but then, it is still similar to what the current get_timer(t) call is doing (at least in it's reference implementation on PowerPC, cf. arch/powerpc/lib/interrupts.c), except that no set_timer(t) is provided.
In acy case - I vote to get rid of this funktion to set some "time base value", and provide a plain void call interface to get_timer() [or whatever the corresponding function would be called].
Also, I vote to always explicitly write the timeout loop as I gave in the example, because this makes the meachnism clear to the reader of the code - hiding it in macros or functions may only lead to conusions or different (and broken) implementations across architectures.
Neither of these has any side effect, so I am at loss as to why that would break when used in nested loops; each loop has its own reference
My reading was that "time(0)" would perform some reset of a variable to give a wrap-around free starting point. Sorry for not reading all of the previous context.
start time by assigning time(0) to its own variable (then and then_nested), and each has its own elapsed time computation by passing its own variable to time() and comparing with its own constant timeout
I don't see any use of the extra argument to the time() function / macro, nor any need / use for such a function / macro at all.
Best regards,
Wolfgang Denk