Forum: Mikrocontroller und Digitale Elektronik Attiny44A interner Takt


von Manuel (Gast)


Lesenswert?

Hallo
ich habe eine kleine Steuerung auf einem Attiny44A programmiert und nun 
eine Frage dazu:

In der ersten Zeile meines C-Programms steht:
1
#define F_CPU            1000000UL
 (da interner Takt ja 8 Mhz/8)

dann habe ich eine Funktion geschrieben, die ich öfter im Hauptprogramm 
aufrufe:
1
void LED_blink(uint8_t blinkzahl)            //Funktion Status LED blinken
2
{
3
4
  for(i = blinkzahl; i>0; i--)            //So oft blinken wie in Eingabewert vorgesehen
5
  {
6
    PORTA |= 1<<LED;
7
    _delay_ms(200);
8
    PORTA &= ~(1<<LED);
9
    _delay_ms(200);
10
  }  
11
}

Jetzt ist das komische, dass ich am Anfang nach meiner Initialisierung 
die Funktion mit
1
LED_blink(3);
 aufrufe und der Blinktakt ca. 5 mal langsamer ist, als beim späteren 
Aufrufen mit
1
LED_blink(5);
 obwohl ich am Systemtakt nichts ändere und der _delay_ms()-befehl ja 
dann einen fixen Wert haben sollte.
(Also der µC läuft am Anfang noch mit einem langsameren takt?!)
Im Datenblatt kann ich dazu nichts finden, deshalb frage ich hier ob ihr 
wisst wieso das so ist? :)

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Manuel schrieb:
> Also der µC läuft am Anfang noch mit einem langsameren takt?

Normalerweise nicht. Schön, das du das komplette Programm gepostet 
hast, so kann man ja genau sehen, ob du am CLKPR Register oder an OSCCAL 
(das sollte sich aber nicht dramatisch auswirken) rumprogrammierst. In 
welcher Umgebung programmierst du eigentlich? Wenn das eine der AVR oder 
Atmel Studio Versionen ist, sollte die CPU Frequnez auch in den 
Projekteinstellungen stehen, und nicht als #define im Programm.

: Bearbeitet durch User
von Manuel (Gast)


Angehängte Dateien:

Lesenswert?

Naja ich hab mir gedacht da is ein bisschen viel drum rum dabei, der 
wahrscheinlich nichts damit zu tun hat, aber gut hier ist der ganze 
Code^^

Mir ist klar das auch noch andere kleine Fehler im Programm sind, aber 
denen widtme ich mich später :)

ja ich schreibe im Atmel Studio und weiß aber jetzt nicht, ob da die 
richtige Freqeunz in den Programmeinstellungen steht (kann ich erst 
nachher nachsehen).

Achja man sieht ja das diese Programm schon etwas älter ist und ich 
sollte vielleicht dazu sagen, dass dieser Fehler erst seit kurzem 
auftritt.

von Falk B. (falk)


Lesenswert?

@ Manuel (Gast)

>    cgonel.txt (10 KB, 10 Downloads)

Welche Verzerrung des Raumzeitkontinuums hinderte dich daren, den 
Quelltext direkt als .c Datei zu posten? Siehe Netiquette

>Achja man sieht ja das diese Programm schon etwas älter ist und ich
>sollte vielleicht dazu sagen, dass dieser Fehler erst seit kurzem
>auftritt.

Also am _delay_ms() liegt es nicht. Möglicherweise schießt dir einer der 
vielen Interrupts dazwischen und blockiert deine CPU heftig, ohne dass 
du es merkst.

von debug (Gast)


Lesenswert?

Manuel schrieb:
> Naja ich hab mir gedacht da is ein bisschen viel drum rum dabei, der
> wahrscheinlich nichts damit zu tun hat, aber gut hier ist der ganze
> Code^^
>

Zum Eingrenzen alles aus dem Programm entfernen, daß nichts mit dem 
Blinken der LEDs zu tun hat, testen, und langsam Codeteile wieder 
zugeben.

Vrmutlich ist es so, wie oben schon gesagt wurde, daß die Interrupts das 
delay delayen.

von tictactoe (Gast)


Lesenswert?

Könnte es sein, dass du ohne Optimierung compilierst?

von Karl H. (kbuchegg)


Angehängte Dateien:

Lesenswert?

Falk Brunner schrieb:
> @ Manuel (Gast)
>
>>    cgonel.txt (10 KB, 10 Downloads)
>
> Welche Verzerrung des Raumzeitkontinuums hinderte dich daren, den
> Quelltext direkt als .c Datei zu posten? Siehe Netiquette

Es sei hiermit nachgeholt.
Dein Source Code in einer txt Datei tu ich mir nicht an.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.