AVR-GCC gevecht

Na een paar jaar niet veel gedaan te hebben de hobby weer een beetje opgepakt met een klein AT90S2313 projectje met AVR-GCC.
Dit is mijn eerste AVR-GCC projectje (vroeger met Keil-8051 gewerkt.
Ik heb de volgende code :

uint16_t TimerSecondsCounter = 0;

TimerSecondsCounter = 254;

for(tel2=0;tel2<TimerSecondsCounter;tel2++) 
     {
     _delay_ms(100);
     tel3++;
     if (tel3 == 5)
          {
          LED_PORT ^= _BV(LED_ORANGE);
          tel3 = 0;
          }
     }
output_high(PORTD,LED_ORANGE);
output_low(PORTD, RELAY);
_delay_ms(500);
output_high(PORTD, RELAY);

Blijft de waarde van TimerSecondsCounter onder de 255 werkt het, komt hij er boven lijkt het of de FOR/NEXT loop oneindig te worden.
Waar kijk ik overheen ? ;( Dus ondanks dat hij als uint16 gedefinieerd is lijkt hij zich als uint8 te gedragen.

Wat is tel2?

Wat is tel2?

<facepalm>
//Schaam aan.

uint8

Ah PEBKAC :)

Bedankt Bas, daar zit je dan een uur kippig overheen te kijken :-(

Heb je de warnings van de compiler niet aangezet?
Die zou daar iets over moeten zeggen.

@Bas, PICNIC kan ook.

[Bericht gewijzigd door henri62 op (12%)]

Warnings? Heel tel2 wordt niet gedeclareerd (en tel3 ook niet). Errors dus.

Waarschijnlijk is hier slechts een deel van de code geplakt. Het scheelt als je een stukje code neemt dat ook echt compileerbaar is. Dan had de tel2 declaratie er ook bij moeten staan, en op dat moment had je het zelf ook al gezien waarschijnlijk.

Tipje: 

 LED_PORT ^= _BV(LED_ORANGE);

kan je vervangen door: 

 LED_PIN = _BV(LED_ORANGE);

(Als LED_PORT dan bijvoorbeeld PORTB is, dan moet LED_PIN dus PINB zijn. )

@rew: nee, dat zou zijn als er LED_PORT |= _BV.... zou staan, er staan ^= ofwel XOR. Eventueel zou hij LED_PIN = !LED_PIN; neer kunnen zetten...

Als je een bit in PINx hoog maakt, toggelt de bijbehorende uitgangspin.

Op 19 oktober 2012 10:13:07 schreef pros:
Als je een bit in PINx hoog maakt, toggelt de bijbehorende uitgangspin.

Of... om het exact te fomuleren: als je een 1 schrijft naar PINx toggled de desbetreffende bit in PORTx (ofwel: ook de pull-up enable/disable kun je hiermee doen als het een input pin is en PUD=0)

Oftewel rew heeft een punt.

Het voorkomt het probleem wat je bij een PIC wel en bij een AVR toch niet hebt dat je bij 

LED_PORT ^= _BV(LED_ORANGE);

hebt. Dit is een verkorte versie van: 

LED_PORT = LED_PORT ^ _BV(LED_ORANGE);

en dan LEES je dus de huidige waarde van de PORT. Bij een PIC is het dan zo dat je dan huidige waardes op de externe pinnen terugleest. Als je bijvoorbeeld een pittige condensator op een pin hebt, waardoor ie na het toggelen net nog als "0" leest, dan krijg je "0", waardoor er dus een "0" teruggeschreven wordt ipv de "we willen 1".

Bij een AVR beschermt het alleen tegen: 


   load PORTB, R8
   load _BV(LED), R9
   xor R9, R8
   store R8, PORTB

Als er nu tussen de eerste en de laatste instructie een interrupt plaatsvindt die ook iets met PORTB doet, dan ben je het haasje! Die verandering wordt ongedaan gemaakt door de laatste instructie hier!

Ah, oke, mijn fout. Ik heb al te lang niet meer met PIC/AVR gewerkt om dat te herinneren. Een dergelijk probleem treedt natuurlijk alleen op bij meerdere threads (lees: als je de PORT beschrijft vanuit een interrupt)

Niet als je single-instruction modifies gebruikt. SBR & CBR zijn daar geschikt voor. De gemiddelde compiler zal een bitset in de vorm PORT=PORT | <bitvalue> ook herkennen en er een single-instruction van maken. Als je meerdere bits tegelijk doet (of iets doet wat compile-time niet op te lossen is), dan heb je dat probleem.

AVR stelt je in elk geval in staat terug te lezen wat je geschreven hebt en niet wat er actueel op die poort staat. Geen RMW probleem dus.

@Jochem,

Ik had inderdaad een deel geplakt, tel2 had ik wel gedeclareerd maar als uint8, er een uint16 van gemaakt en het werkt.

en op dat moment had je het zelf ook al gezien waarschijnlijk.

Nee dat was het probleem , zelf gedeclareerd maar er vervolgens kippig overheen gaan zitten kijken.

@Rew,

Bedankt voor je tip.

Op 19 oktober 2012 16:29:15 schreef bprosman:
Nee dat was het probleem , zelf gedeclareerd maar er vervolgens kippig overheen gaan zitten kijken.

Maar toch heb je kans dat als je het hier had neergeplakt en had gezorgd dat de code-snippet op zichzelf compileerbaar zou zijn, dat je het ineens zelf had gezien. Puur omdat je een heel elementair stuk code overhoudt.

Maar ik weet hoe het gaat. Zeker op je eigen code zit je soms dagen te debuggen op iets wat een ander in 2 seconden oplost. Maar soms kun je het al oplossen door een ander stap voor stap uit te leggen wat je code zou moeten doen.

[Bericht gewijzigd door Jochem op (11%)]

Op 19 oktober 2012 13:35:30 schreef EricP:
Niet als je single-instruction modifies gebruikt. SBR & CBR zijn daar geschikt voor.

Right.... En dan denk je veilig te zijn, en vervolgens blijkt dat PORTD buiten het bereik van de SBR en CBR instructies in het IO-geheugen te zitten. Details weet ik niet meer, maar volgens mij werken dat soort instructies maar op een klein bereik van het IO geheugen, en zitten sommige poorten (of dat PORTD is, weet ik niet meer) daarbuiten..... Zucht.