ATmega / falsche delay-Zeiten

[__Son´s B. (bersison)]

Hallo, finde folgenden Fehler nicht heraus;
(1) LED blinkt nicht im 200ms- sondern im 2Sek-Takt
(2) Warnmeldungen bei den Variablen, Bsp: "conflicting types for 
'warte_ms'
(3) Kann man alle Variablen-Def., zur besseren main-Lesbarkeit in einer 
"Variablen"-Funktion unterbringen?
_____________________________
#include  <avr/io.h>
#define    F_CPU 8000000Hz
#include  <util/delay.h>

int main(void)
{
  DDRA = 0x00;
  DDRB = 0xFF;
  int led_nr =0;
  int mil_sek =0;
  int zaehler =0;

  start:;
  PORTB = 0b11111111;

  while (PINA != 0b11111110)
  {
      blink_led(0);
  }

  goto start;
  return 0;
}


void blink_led(led_nr)
{
  PORTB ^= (1<<led_nr); // toggel
  warte_ms(200); //200ms
}

void warte_ms(mil_sek)
{
  for (int zaehler=0; zaehler<=mil_sek; zaehler++)
    _delay_ms(1); //1ms
}

[Karl H. (kbuchegg)]

__Son´s Bersi__ schrieb:
> Hallo, finde folgenden Fehler nicht heraus;
> (1) LED blinkt nicht im 200ms- sondern im 2Sek-Takt

Das kann man mit zugekniffenem Auge als einen Faktor 8 werten.


> #define    F_CPU 8000000Hz

Womit diese Angabe unglaubwürdig wird.
Dein AVR läuft nicht mit 8Mhz sondern mit 1Mhz. Also 8-mal langsamer als 
gedacht. Und dann stimmt wieder alles.

Also. Fuses kontrollieren. Bei F_CPU kannst du hinschreiben was dir 
gefällt. Das juckt den AVR wenig. Der richtet sich nach seinen Fuses wie 
schnell er wirklich läuft. Und nur dann, wenn F_CPU mit dieser Realität 
übereinstimmt, dann stimmen auch die delay Zeiten.

[Karl H. (kbuchegg)]

Und kauf dir ein C-Buch und arbeit6e es von vorne bis ungefähr zum Ende 
des ersten Drittels durch.
Du kannst nicht einfach Dinge hinschreiben wie du sie denkst und hoffen, 
dass der Compiler schon was draus machen wird. Auch Programmiersprachen 
haben so etwas wie eine Grammatik, die man lernen muss.

[Karl H. (kbuchegg)]

#define    F_CPU 8000000

#include  <avr/io.h>
#include  <util/delay.h>
#include  <stdint.h>

void warte_ms(int mil_sek)
{
  for (int zaehler = 0; zaehler < mil_sek; zaehler++)
    _delay_ms( 1 ); //1ms
}

void blink_led(uint8_t led_nr)
{
  PORTB ^= (1<<led_nr); // toggle
  warte_ms( 200 );
}

int main(void)
{
  DDRA = 0x00;
  DDRB = 0xFF;

  while( 1 )
  {
    PORTB = 0b11111111;

    while ( PINA != 0b11111110 )
    {
      blink_led( 0 );
    }
  }

  return 0;
}

In deinem eigenen Interesse streichst du jetzt erst mal das Wort 'goto' 
aus deinem Wortschatz. Wenn du in einem halben Jahr etwas Erfahrung 
gesammelt hast, kannst du es wieder mit aufnehmen. Aber dann wirst du 
gelernt haben, dass du es eigentlich nie brauchst. Es gibt derartige 
Fälle - sie sind aber selten. Ich hab in 30 Jahren 
Industrieprogrammierung ein einziges mal einen goto eingesetzt. Und 
selbst der war eigentlich unnötig und in 5 Minuten ausgebaut und durch 
etwas besseres ersetzt.

[__Son´s B. (bersison)]

Karl Heinz Buchegger schrieb:
> Du kannst nicht einfach Dinge hinschreiben wie du sie denkst und hoffen,

Wenn du die Variabl. meinst, die wollte ich blockartig = übersichtlicher 
deklarieren. Fehler?

Zur weiteren Transparenz, hatte ich das main nach oben geschrieben. 
Fehler?

[Mike R. (thesealion)]

__Son´s Bersi__ schrieb:
> Karl Heinz Buchegger schrieb:
> Wenn du die Variabl. meinst, die wollte ich blockartig = übersichtlicher
> deklarieren. Fehler?

Kurz: Ja
Etwas länger: So wie du deine Variablen deklariert hast machen sie 
keinen Sinn. 100% davon sind in main sogar unnötig und werden überhaupt 
nicht verwendet.

> Zur weiteren Transparenz, hatte ich das main nach oben geschrieben.
> Fehler?

Kurz: Ja
Länger: Eigentlich müsste dir der Compiler hier einige Warnung zeigen, 
da er von oben nach unten arbeitet und damit zum Beispiel "blink_led()" 
nicht kennt, wenn du es in main aufrufst.

[Stefan (Gast)]

Variablen, die Du innerhalb einer Funktion deklarierst, sind auch nur 
dort erreichbar. Sie liegen im STACK Bereich des RAM. Dass heisst, 
sobald die Funktion verlassen wird, gibt's die Variablen auch nicht 
mehr. Ihre Werte gehen verloren. Diese Variablen werden nicht 
automatisch initialisiert, wenn Du keinen Startwert angibst.

Variablen, die Du außerhalb jeder Funktion deklarierst, sind im ganzen 
Programm erreichbar. Sie werden VOR dem Start der main() Funktion 
automatisch initialisiert, auch wenn Du keinen Startwert angibst 
(Default=0).

Parameter von Funktionen müssen einen Typ haben, deswegen erhälst Du 
eine Fehlermeldung.

Falsch: void warte_ms(mil_sek)

Richtig: void warte_ms(int mil_sek)

Goto führt in größeren Programmen sehr oft zu mangelhafter Lesbarkeit. 
Deswegen lernt man, goto wie die Pest zu vermeiden. Endlosschleifen kann 
man alternativ so schreiben (erzeugt den selben Maschinencode):

while (1) {
  ...
}

Oder:

for (;;) {
 ...
}

Wobei die Variante mit while häufiger anzutreffen ist.

[Stefan (Gast)]

By the way:

_delay_ms kann auch 200ms lang warten. Die Doku sagt dazu:

> The maximal possible delay is 262.14 ms / F_CPU in MHz.

Und weiter heisst es:

> When the user request delay which exceed the maximum possible one,
> delay_ms() provides a decreased resolution functionality ...
> providing delays up to 6.5535 seconds.

[Karl H. (kbuchegg)]

__Son´s Bersi__ schrieb:
> Karl Heinz Buchegger schrieb:
>> Du kannst nicht einfach Dinge hinschreiben wie du sie denkst und hoffen,
>
> Wenn du die Variabl. meinst, die wollte ich blockartig = übersichtlicher
> deklarieren. Fehler?

Die erste Frage lautet: brauchst du denn die Variablen überhaupt?
Schau dir mein Programm an: Weit und breit nichts von diesen Variablen 
zu sehen.


Der nächste Punkt ist: Variablen haben einen Gültigkeitsbereich und 
damit gekoppelt einen Sichtbarkeitsbereich. Grob gesagt: Variablen sind 
in dem Block gpltig und sichtbar, in dem sie definiert sind (und in 
allen darin enthaltenen Blöcken. Der Block begrenzt die Sichtbarkeit - 
ausserhalb des Blockes existiert die Variable schlicht und ergreifend 
einfach nicht.

void foo()
{     // <----- hier beginnt ein Block, Block A

  int wert;    // <--- diese Variable ist nur innerhalb des Blockes
               //      bekannt, in dem sie definiert wurde

  if( ... )
  {              // ein weiterer Block (in den aeusseren reingeschachtelt)
                 // beginnt. Block B

    int j;       // diese Variable ist innerhalb von Block B definiert.
                 // Ihre Lebensdauer und damit ihre SIchtbarkeit wird
                 // durch diesen Block begrenzt.

    j = wert;    // das ist ok. j ist innerhalb von Block B definiert
                 // und wert ist eine Blockebene 'höher' definiert, weil
                 // ja Block B in Block A eingeschachtelt ist.
                 // Man kann es auch so sagen: einfach die Blockstruktur
                 // nach 'aussen' verfolgen und nachsehen ob es in diesem
                 // Block die angegebene Variable gibt

  }           // <--- hier wied Block B (der vom if) wieder geschlossen
              //      Alle Variablen in diesem Block existieren danach
              //      nicht mehr.
              //      In diesem konkreten Beispiel gibt es daher
              //      danach keine Variable j mehr

}         // <---- Der Block A wird geschlossen. Alle in diesem BLock
          //       enthaltenen Variablen gibt es danach nicht mehr.
          //       D.h. hier endet die Lebensdauer und damit auch
          //       Sichtbarkeit von wert. Ausserhalb dieses Blocks gibt
          //       es keine Variable 'wert' und wenn es doch eine Variable
          //       dieses Namens gibt, dann handelt es sich dabei
          //       um eine andere Variable.

> Zur weiteren Transparenz, hatte ich das main nach oben geschrieben.
> Fehler?

Lies deinen Code von oben nach unten. So wie es auch der Compiler macht. 
Und halte dich an den einfachen Grundsatz: Benutzt werden kann nur das, 
was auch bekannt ist. Wenn du eine Funktion aufrufen willst, dann hat 
die eine Funktionssignatur. Die muss bekannt sein, ehe man sie aufruft.
Durch die Reihenfolge

void foo( void )
{
  ...
}

int main()
{
  foo();
}

ist automatisch die Funktionssignatur dem Compiler bekannt gemacht 
worden, ehe die Funktion benutzt wird. Schreibst du das anders rum

int main()
{
  foo();
}

void foo( void )
{
  ....
}

dann zwingst du den Compiler dazu, Standardannahmen zu treffen, wenn der 
den Aufruf der Funktion behandeln soll, ehe er die Funktion selbst zu 
Gesicht bekommt. Und in deinem Fall waren diese Standardannahmen eben 
falsch.

Lösen kann man das entweder durch Umdrehen der Reihenfolge, oder in dem 
man mittels eines Prototypen dem Compiler die Funktionssignatur bekannt 
gibt, ehe man die Funktion das erste mal aufrufen will

void foo( void );     // Ein Protoyp. Es gibt eine Funktions namens foo
                      //  und so sieht ihr Funktionskopf aus

int main()
{
  foo();              // Durch den Protoypen weiß der Compiler, wie er
                      // das hier behandeln muss und braucht keine
                      // ANnahmen treffen
}

void foo( void )      // Aber irgendwann muss natürlich auch mal die
{                     // Funktion selbst kommen. Bisher war da ja nur
   ...                // der Prototyp
}

Aber warum erklär ich dir das eigentlich (halbherzig), wo du das in 
jedem noch so grindigem C-Buch auf dutzenden Seiten in aller 
Ausführlichkeit nachlesen kannst?
Kauf dir ein C-Buch!

[__Son´s B. (bersison)]

DANKE euch Beiden! Sehr aufschlussreich.

Toller Tip: while(1) statt goto

Hatte Warnmeldungen ignoriert, da hex-Programme einwandfrei liefen - 
werde ich ab jetzt korrekt schreiben.