Re: [avr-libc-dev] Optimization safe access to the timers

[Enoch H. Wexler]

Hi Paulo,


Strange, the problem does not show in my simplified test... but here's
some real code excerpt and its disassembly (compiled with -Os using
avr-gcc 4.1.0):

(1) Using TCNT3 directly:

when = TCNT3 + (7200 / 9 * 10 - 1); /* > 1 sec delay */
while (when - TCNT3 >= 0)
    UDR1;

000013ce <kuku>:
    13ce:    80 91 88 00     lds    r24, 0x0088
    13d2:    90 91 89 00     lds    r25, 0x0089
    13d6:    80 91 88 00     lds    r24, 0x0088
    13da:    90 91 89 00     lds    r25, 0x0089
    13de:    83 b1           in    r24, 0x03    ; 3
    13e0:    fa cf           rjmp    .-12         ; 0x13d6 <kuku+0x8>

(2) Using the "safe" TCNT(3), i.e.:

typedef volatile int16_t (*pTCNT);
#define TCNT(n) *(pTCNT)(&TCNT ## n)

<snip>

when = TCNT(3) + (7200 / 9 * 10 - 1); /* > 1 sec delay */
while (when - TCNT(3) >= 0)
  UDR1;  

000013ce <kuku>:
    13ce:    20 91 88 00     lds    r18, 0x0088
    13d2:    30 91 89 00     lds    r19, 0x0089
    13d6:    21 5c           subi    r18, 0xC1    ; 193
    13d8:    30 4e           sbci    r19, 0xE0    ; 224
    13da:    01 c0           rjmp    .+2          ; 0x13de <kuku+0x10>
    13dc:    83 b1           in    r24, 0x03    ; 3
    13de:    80 91 88 00     lds    r24, 0x0088
    13e2:    90 91 89 00     lds    r25, 0x0089
    13e6:    b9 01           movw    r22, r18
    13e8:    68 1b           sub    r22, r24
    13ea:    79 0b           sbc    r23, r25
    13ec:    77 ff           sbrs    r23, 7
    13ee:    f6 cf           rjmp    .-20         ; 0x13dc <kuku+0xe>
 
It's not a problem any more... I'm just puzzled.

Thanks, Enoch.

> Enoch H. Wexler wrote:
>> Hello libc maintainers,
>
> Hi, Enoch.
>
> Not a libc maintainer, more of a lurker, but maybe I can help ;)
>
>> May I suggest adding to libc an optimization safe access method to the
>> timers, for example:
>>
>> typedef volatile int16_t (*pTCNT);
>> #define TCNT(n) *(pTCNT)(&TCNT ## n) /* e.g., TCNT(3) */
>>
>> Without this a 100 "tick" delay loop like this would run forever:
>
> Have you verified this?
>
> It shouldn't run forever since TCNT3 should already be declared as
> volatile, like all the hardware registers that can change value
> without the compiler knowing.
>
> If for some reason it is not declared volatile, that would be a bug.
>