Befehle werden übersprungen

[Haderlump (Gast)]

Hallo zusammen
Bei folgendem Programm:

#include <avr/io.h>
#include <stdint.h>
#include <avr/eeprom.h>
#define BAUD 19200
#include <util/setbaud.h>
#include <avr/interrupt.h>
 
// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.
 
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif

int usart_init(void)
  {
    
    UBRR0H = UBRRH_VALUE;
       UBRR0L = UBRRL_VALUE;
      UCSR0B |= (1<<RXC0)|(1<<RXCIE0);                           // UART TX einschalten
      UCSR0C = (1<<UMSEL01)|(1 << UCSZ01)|(1 << UCSZ00); // Asynchron 8N1
    
    return 0 ;
  }

#define UART_MAXSTRLEN 10
  volatile uint8_t uart_str_complete = 0;     // 1 .. String komplett empfangen
  volatile uint8_t uart_str_count = 0;
  volatile char uart_string[UART_MAXSTRLEN + 1] = "";

ISR(USART_RXC_vect)
{
  unsigned char nextChar;
 
  // Daten aus dem Puffer lesen
  nextChar = UDR0;
  if( uart_str_complete == 0 ) {  // wenn uart_string gerade in Verwendung, neues Zeichen verwerfen
 
    // Daten werden erst in uart_string geschrieben, wenn nicht String-Ende/max Zeichenlänge erreicht ist/string gerade verarbeitet wird
    if( nextChar != '\n' &&
        nextChar != '\r' &&
        uart_str_count < UART_MAXSTRLEN ) {
      uart_string[uart_str_count] = nextChar;
      uart_str_count++;
    }
    else {
      uart_string[uart_str_count] = '\0';
      uart_str_count = 0;
      uart_str_complete = 1;
    }
  }
}


ISR (TIMER0_OVF_vect)
{
  TCNT0 == 256-50;
}


int main(void)
{
//Initialisierungen
  int16_t impulsbreite[16];
  int16_t min_impulsbreite[16];
  int16_t max_impulsbreite[16];
  int8_t a;
  for (a=0 ; a<16; a++)
    { 
      impulsbreite[a] == eeprom_read_word (a);
      min_impulsbreite[a] == eeprom_read_word (a + 32);
    max_impulsbreite[a] == eeprom_read_word (a + 64);
    }
  usart_init();
  TCCR0A = (1<<CS01);
  TIMSK0 |= (1<<TOIE0);
  sei();
  TCNT0 == 256-50;
while(1) 
{         
     
     /* "Hauptschleife*/  
} 
return 0;

}

wird die For-Schleife (kurz nach main), mit der ich 3 Arrays 
initialisieren will, im Debuger einfach übersprungen.  Die 
Optimierungseinstellung ist -0s

Gruß Haderlump


--

Bitte in Zukunft die Formatierungstags [ c ] und [ / c ] verwenden.

-rufus

[holger (Gast)]

== nicht gleich =

[(prx) A. K. (prx)]

holger schrieb:
> == nicht gleich =

=> Warnungen einschalten und nicht ignorieren. Sollte eigentlich zu 
lesen sein.

Ausserdem werden diese Arrays erkennbar nicht genutzt, was Konsequenzen 
haben kann.

[Kaj (Gast)]

Haderlump schrieb:
> Die
> Optimierungseinstellung ist -0s
Dann stell die doch mal runter...

Haderlump schrieb:
> wird die For-Schleife (kurz nach main), mit der ich 3 Arrays
> initialisieren will, im Debuger einfach übersprungen.
Koennte daran liegen das die wegoptimiert werden. Du initialisierts die 
Arrays zwar, aber das wars dann dann ja auch, mehr passiert mit den 
arrays ja nicht, also koennen die auch wegoptimiert werden.

Schalte doch mal die Compilerflags -Wall -Wextra ein.
Ich bin mir sicher das dir der Compiler dann sowas sagt wie: "Variable 
set but not used"

Haderlump schrieb:
> TCNT0 == 256-50;
Man koennte auch einfach TCNT = 206 schreiben...

Gruesse

[(prx) A. K. (prx)]

Kaj schrieb:
> Man koennte auch einfach TCNT = 206 schreiben...

Und dafür in einen dann zwingend nötigen Kommentar wieder die 50, damit 
man später noch durchblickt???

Er sollte sich eher den CTC Mode ansehen.

[Haderlump (Gast)]

Danke ür die schnellen Antworten.
Das Programm steckt natürlich erst in den Anfängen. Die Arrays werden 
später natürlich genutzt. Offensichtlich werden sie wohl wegoptimiert.
 Zu 256-50:
Natürlich könnte man auch 206 schreiben. Aber der wert 50 hat ja auch 
seine bedeutung, und da muss ich dann noch mit rumexperimentieren. und 
da ist es für mich übersichtlicher, als wenn ich das jedesmal wieder neu 
ausrechnen muß.

[Justus S. (jussa)]

Haderlump schrieb:
> Die Arrays werden
> später natürlich genutzt. Offensichtlich werden sie wohl wegoptimiert.

immer noch nicht den Unterschied zwischen = und == verstanden?

[Karl H. (kbuchegg)]

Haderlump schrieb:
> Danke ür die schnellen Antworten.
> Das Programm steckt natürlich erst in den Anfängen. Die Arrays werden
> später natürlich genutzt. Offensichtlich werden sie wohl wegoptimiert.
>  Zu 256-50:
> Natürlich könnte man auch 206 schreiben. Aber der wert 50 hat ja auch
> seine bedeutung, und da muss ich dann noch mit rumexperimentieren. und
> da ist es für mich übersichtlicher, als wenn ich das jedesmal wieder neu
> ausrechnen muß.


SChon klar. Du kannst aber auch ganz einfach

  TCNT0 = -50;

schreiben und kriegst genau dasselbe Ergebnis.

Trotzdem sollte man den CTC Modus nicht aus den Augen verlieren, wenn 
der µC den auf diesem Timer kann.

[Udo S. (urschmitt)]

Haderlump schrieb:
> Offensichtlich werden sie wohl wegoptimiert.

Weshalb man fürs debuggen günstigerweise die Optimierung abschaltet.

[Thomas H. (Firma: CIA) (apostel13)]

Hat der GCC mittlerweile eigentlich einen Deppenmodus der die 
wilkürliche Verwendung von == und = automatisch korrigiert und aus einem 
Vergleich eine Zweisung und Vice versa macht??

[Dussel (Gast)]

Thomas Holmes schrieb:
> Hat der GCC mittlerweile eigentlich einen Deppenmodus der die
> wilkürliche Verwendung von == und = automatisch korrigiert und aus einem
> Vergleich eine Zweisung und Vice versa macht??
Schlag das mal den Entwicklern von Malbolge vor :D
Die Warnung ist absolut ausreichend.

[Johann L. (gjlayde)]

Thomas Holmes schrieb:
> Hat der GCC mittlerweile eigentlich einen Deppenmodus der die
> wilkürliche Verwendung von == und = automatisch korrigiert und aus einem
> Vergleich eine Zweisung und Vice versa macht??

Nein, und wird er auch nicht bekommen.

Das Programm hat immer noch der Programmierer zu schreiben.  Davon ab 
ist ein = ein = und kein ==, und ein == ist ein == und kein =.

Du würdest ja auch nicht wollen, dass ein Compiler +1 durch -1 ersetzt, 
weil er ganz schlau ist und denkt: Das '+' ist überflüssig und daher 
hast du doch ganz bestimmt ein '-' gemeint?

Drittens werden die Stellen vom Compiler gewarnt, und wer Warnungen 
abschaltet oder ignoriert ist selber Schuld.

Viertens kann die Verwendung gewollt sein wie im Beispiel

    (void)
      (1 == (a = fun ())
       && (var1 = foo ())
       && (var2 = bar ())
       && (var3 = buh ()));

das genau so gemeint ist wie es da steht und nicht irgendwie vom 
Compiler gepimpt oder hochgeskillt.  Dass solche Idiome eher selten 
verwendet werden und viele länglichen Code wie den folgenden vorziehen 
ist Entscheidung des Anwenders und nicht Belang eines Compilers!

    a = fun();
    if (a == 1)
    {
        var1 = foo();
        if (var1)
        {
            var2 = bar();
            if (var2)
                var3 = buh();
        }
    }

Fünftens schließlich:  Wenn diese Funktionalität so essenziell wäre und 
so oft nachgefragt würde, gäbe es einen Markt dafür und z.B. 
Eclipse-Plugins, die den Code entsprechend verschlimmbesserten.