UART RX Interrupt Problem

[Christian W. (christianw92)]

Hallo Zusammen,

ich bin gerade dabei ein bisschen mit UART herumzuspielen und habe mir 
ein kleines Programm geschrieben. Das senden funktioniert einwandfrei, 
aber wenn ich dem Controller per Terminalprogramm etwas sende, wird der 
uC angehalten, So als ob er in der Interruptrutine stecken bleibt. Habe 
ich was falsch gemacht?
Hier der Code:

#define F_CPU 16000000
#include <avr/io.h>
#include <util/delay.h>
#include <stdlib.h>
#include <stdint.h>
#include <avr/interrupt.h>


uint8_t BAUD_Wert = 103;//Baudrate (9600)
uint8_t UART_Daten = 10;

ISR (UART_RXC_vect)
{
  UART_Daten = UDR0;
}


void AVR_Init (void)
{
  
  DDRD |= (1<<PB1);// PD1 als Ausgang (TXD)
  
}


void UART_Init (void)
{
  
  UBRR0 = BAUD_Wert;//Baudrate setzen
  UCSR0B |= (1<<RXCIE0) | (1<<RXEN0) | (1<<TXEN0);// RX, TX und RX Interrupt aktivieren
  UCSR0C = (1<<UCSZ01) | (1<<UCSZ00);// 8 Bit Paketgröße einstellen
  
}




int main(void)
{
    while(1)
    {
        AVR_Init;
        UART_Init();
        sei();//Interrupts aktivieren
        
        while(1)
        {
          

          while (!(UCSR0A & (1<<UDRE0))){}
          UDR0 = UART_Daten;
      _delay_ms(2000); 
    }  
    }
}

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian W. schrieb:
> uint8_t BAUD_Wert = 103;//Baudrate (9600)
> uint8_t UART_Daten = 10;
>
> ISR (UART_RXC_vect)
> {
>   UART_Daten = UDR0;
> }

 volatile uint8_t UART_Daten = 10;

Christian W. schrieb:
> DDRD |= (1<<PB1);// PD1 als Ausgang (TXD)

 Wozu soll das gut sein ?

[M. K. (sylaina)]

Die erste while-Schleife bei dir ist ziemlich sinnlos da sie durch die 
zweite while-Schleife eh nicht Kreise ziehen wird.

Die ISR kann man so machen, ist aber ziemlich witzlos.

Am besten schaust du dir hier auf der Seite mal das UART-Beispiel in C 
genauer an.

[Stefan F. (Gast)]

>> DDRD |= (1<<PB1); // PD1 als Ausgang (TXD)
> Wozu soll das gut sein ?

Bei ATtiny und ATmega ist das nicht notwendig. Nur bei Xmega 
Controllern.

> aber wenn ich dem Controller per Terminalprogramm etwas sende,
> wird der uC angehalten

Du musst die Interrupts noch mit "sei()" freigeben. Ich denke, dein 
Programm bleibt in der Zeile "while (!(UCSR0A & (1<<UDRE0))){}" hängen, 
weil wegen gesperrter Interrupts das UDR register nicht frei wird.

[M. K. (sylaina)]

Stefan U. schrieb:
> Du musst die Interrupts noch mit "sei()" freigeben.

Hat er doch drin. ;)

Christian W. schrieb:
> ...
>         sei();//Interrupts aktivieren
> ...

[Stefan F. (Gast)]

>> Du musst die Interrupts noch mit "sei()" freigeben.
> Hat er doch drin. ;)

Oha, blinder geht nicht. Sorry.

[Stefan F. (Gast)]

Probier mal, den RXCIE0 weg zu lassen und schau nach, ob das Programm 
dann immer noch stehen bleibt. Vielleicht bringt uns das der 
fehlerursache etwas näher.

Erstelle mal ein LST File, damit wir die Interrupt-Vektoren 
kontrollieren können.

[Christian W. (christianw92)]

Hallo zusammen,

erstmal Danke für die Antworten.

1.
Marc V. schrieb:
> Christian W. schrieb:
>> DDRD |= (1<<PB1);// PD1 als Ausgang (TXD)
>
>  Wozu soll das gut sein ?

Ich hatte das mal irgendwo gelesen und dachte das braucht man.

2.
M. K. schrieb:
> Die erste while-Schleife bei dir ist ziemlich sinnlos da sie durch die
> zweite while-Schleife eh nicht Kreise ziehen wird.

Hab ich garnicht bemerkt. Ist mir anscheinend beim Kopieren aus meinem 
anderen Projekt passiert.

3.
M. K. schrieb:
> Die ISR kann man so machen, ist aber ziemlich witzlos.

Was ist daran denn falsch? Falls du meinst, weil sonst kein anderer Code 
ausgeführt wird, der kommt noch.

4.
Stefan U. schrieb:
> Probier mal, den RXCIE0 weg zu lassen und schau nach, ob das Programm
> dann immer noch stehen bleibt. Vielleicht bringt uns das der
> fehlerursache etwas näher.

Habe ich mal weggelassen. Das Programm bleibt nicht mehr stehen wenn 
etwas empfangen wird. Allerdings kann der uC nichts empfangen, weil ja 
der Interrupt deaktiviert ist.


Mein aktueller Code sieht so aus:

#define F_CPU 16000000
#include <avr/io.h>
#include <util/delay.h>
#include <stdlib.h>
#include <stdint.h>
#include <avr/interrupt.h>


uint8_t BAUD_Wert = 103;//Baudrate (9600)
volatile uint8_t UART_Daten = 10;

ISR (USART_RX_vect)
{
  PORTB ^= (1<<PB5);
  UART_Daten = UDR0;
}


void UART_Init (void)
{
  
  UBRR0 = BAUD_Wert;//Baudrate setzen
  UCSR0B |= (1<<RXCIE0) | (1<<RXEN0) | (1<<TXEN0);// RX, TX und RX Interrupt aktivieren
  UCSR0C = (1<<UCSZ01) | (1<<UCSZ00);// 8 Bit Paketgröße einstellen
  
}


int main(void)
{
  
       DDRB |= (1<<PB5);
        UART_Init();
        sei();//Interrupts aktivieren
        PORTB |= (1<<PB5);
    
        while(1)
        {
          
          while (!(UCSR0A & (1<<UDRE0))){}
          UDR0 = UART_Daten;
      
      _delay_ms(2000); 
    }  
    
}

Anscheinend habe ich die ISR falsch geschrieben. ISR (USART_RX_vect). 
Bleibt zwar nicht mehr stehen, der Code in der ISR wird aber trotzdem 
nicht ausgeführt.
Ich habe jetzt noch einen LED toggle Befehl eingefügt um optisch sehen 
zu können was passiert. Es passiert aber nichts.

[Magnus M. (magnetus)]

Welchen Controller verwendest Du?

Register wie z.B. "UDR0" klingen nach einem Controller mit mehreren 
UARTs. In diesem Fall würde ich aber für jeden UART einen eigenen 
Interruptvektor erwarten. "ISR (USART_RX_vect)" passt nach meinem 
Verständnis dann eher zu einem Controller mit nur einem UART.

[Christian W. (christianw92)]

Ich verwende einen ATmega328, der auf einem Arduino Nano sitzt und den 
ich per XLoader flashe.
Der 328 hat nur einen UART.

[Magnus M. (magnetus)]

Christian W. schrieb:
> Ich verwende einen ATmega328, (...)
> Der 328 hat nur einen UART.

Und dein Compiler haut Dir keine Fehler um die Ohren? RESPEKT!

[Magnus M. (magnetus)]

Magnus M. schrieb:
> Register wie z.B. "UDR0" klingen nach einem Controller mit mehreren
> UARTs.

Magnus M. schrieb:
> Und dein Compiler haut Dir keine Fehler um die Ohren? RESPEKT!

Sorry, vergiss bitte den Quatsch, den ich da geschrieben habe. Liege 
schon im Bett und bin nur mit dem Smartphone online.

Habe es mittlerweile dann auch geschafft mir auf dem Smartphone das 
Datenblatt anzusehen und siehe da - deine Registerbezeichnungen scheinen 
korrekt zu sein...

Asche auf mein Haupt!

Ich leg das Smartscheißding jetzt beiseite und schlaf mal ein wenig.

Grüße
Magnus

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian W. schrieb:
> Anscheinend habe ich die ISR falsch geschrieben. ISR (USART_RX_vect).
> Bleibt zwar nicht mehr stehen, der Code in der ISR wird aber trotzdem
> nicht ausgeführt.
> Ich habe jetzt noch einen LED toggle Befehl eingefügt um optisch sehen
> zu können was passiert. Es passiert aber nichts.

 Probiere zuerst mal ohne Echo bei dir:

 int main(void)
 {
    DDRB |= (1<<PB5);
    UART_Init();
    sei();//Interrupts aktivieren
    PORTB |= (1<<PB5);
    
    while(1)
        {
           UART_Daten += 1;
           _delay_ms(10); 
        }
  }

 Dein Programm muss ganz einfach die ISR ausführen.

 P.S.
 Falls auf der anderen Seite Echo eingeschaltet ist, ausschalten.

[M. K. (sylaina)]

Christian W. schrieb:
> Was ist daran denn falsch? Falls du meinst, weil sonst kein anderer Code
> ausgeführt wird, der kommt noch.

witzlos != falsch. Witzlos ist es jedes empfangene Byte an den selben 
Speicher zu schreiben. Normalerweise schreibt man den in einen Loop 
rein, für gewöhnlich in eine Zeichenkette. Das ist schon das 
ungewöhnliche bei dir: Dein Speicher wo du das Byte reinschreibst ist 
kein char sondern ein int. Aber OK, es ist anscheinend nur zum testen.

Christian W. schrieb:
> void UART_Init (void)
> {
>
>   UBRR0 = BAUD_Wert;//Baudrate setzen
>   UCSR0B |= (1<<RXCIE0) | (1<<RXEN0) | (1<<TXEN0);// RX, TX und RX
> Interrupt aktivieren
>   UCSR0C = (1<<UCSZ01) | (1<<UCSZ00);// 8 Bit Paketgröße einstellen
>
> }

Beim Einstellen des UBRR0 empfiehlt es sich, zunächst das High-Byte zu 
setzen, dann das Low-Byte. Und BAUD_Wert sollte ein 16 bit Integer sein 
wobei man in dem Fall auch das High-Byte zunächst zu 0 setzen kann und 
BAUD_Wert dann ans Low-Byte übergibt. Es kann sonst sein, dass es nicht 
klappt. Geht denn das Senden sicher (was empfängst du wenn du eine 65 
sendest?). Möglicherweise hast du auch das Datenformat auf der 
Empfangsseite falsch eingestellt.
Paketgröße stellst du auf 8 Bit ein. Kann man machen, ist aber unnötig. 
8 Bit Paketgröße ist der Initialisierungswert. Genauer: 8N1 ist der 
Initialisierungswert des UART am Atmega328.
Und wie stehen die Fuses bei dir? Ist der Atmega auch richtig 
eingestellt sodass er mit 16 MHz läuft?

[Marc V. (Firma: Vescomp) (logarithmus)]

M. K. schrieb:
> Beim Einstellen des UBRR0 empfiehlt es sich, zunächst das High-Byte zu
> setzen, dann das Low-Byte. Und BAUD_Wert sollte ein 16 bit Integer sein
> wobei man in dem Fall auch das High-Byte zunächst zu 0 setzen kann und
> BAUD_Wert dann ans Low-Byte übergibt. Es kann sonst sein, dass es nicht

 Glücklicherweise macht das der Compiler schon richtig. Aber man sollte
 trotzdem aufpassen bei solchen Sachen.

M. K. schrieb:
> Und wie stehen die Fuses bei dir? Ist der Atmega auch richtig
> eingestellt sodass er mit 16 MHz läuft?
Christian W. schrieb:
> Ich verwende einen ATmega328, der auf einem Arduino Nano sitzt und den
> ich per XLoader flashe.

 Das wird schon in Ordnung sein.
 Ich glaube eher, dass Echo sein Problem war.

[M. K. (sylaina)]

Marc V. schrieb:
> Das wird schon in Ordnung sein.

Ist halt die Frage ob er einen Original Nano hat oder ein Clone. Bei den 
Clones hab ich es schon erlebt, dass die Megas nicht geflasht sind.

[Christian W. (christianw92)]

M. K. schrieb:
> Ist halt die Frage ob er einen Original Nano hat oder ein Clone. Bei den
> Clones hab ich es schon erlebt, dass die Megas nicht geflasht sind.

Es ist ein Nano Nachbau. Wenn der atmega nicht geflasht wäre könnte ich 
ja kein Programm über den Com Port aufspielen.

Das Programm ist vorerst nur zu Test und Übungszwecken gedacht.


M. K. schrieb:
> Geht denn das Senden sicher (was empfängst du wenn du eine 65 sendest?).
> Möglicherweise hast du auch das Datenformat auf der Empfangsseite falsch
> eingestellt.

Ich benutze das Program hterm und das empfängt alles einwandfrei vom uC. 
Es funktioniert nur das empfangen am Atmega nicht.

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian W. schrieb:
> Ich benutze das Program hterm und das empfängt alles einwandfrei vom uC.
> Es funktioniert nur das empfangen am Atmega nicht.

 Doch, das tut es.

[Christian W. (christianw92)]

Aktuell ja nicht. Der Code stoppt ja nicht mehr. Allerdings wird auch 
der Code in der ISR nicht ausgeführt.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Christian W. schrieb:
> Ich verwende einen ATmega328

Aha. Dann heisst dein ISR Vektor aber nicht richtig. Beim Mega328 muss 
der ISR Vektor

ISR(USART_RX_vect)

 heissen, wenn du die avr-libc benutzt. Den ganzen 'Du hast die Baudrate 
falsch' o.ä. kannst du in die Tonne kloppen, denn Senden geht ja 
korrekt. Ist vermutlich nur der falsche Vektorname.

Das ganze kannst du in der Online Doku zur avr-libc nachschauen:
http://nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

Den Vektor 'ISR (UART_RXC_vect)' gibt es nur bei ATmega16, ATmega32, 
ATmega323 und ATmega8.

[M. K. (sylaina)]

Matthias S. schrieb:
> Beim Mega328 muss
> der ISR VektorISR(USART_RX_vect)
>  heissen

Und wie man oben lesen kann heißt er auch inzwischen

Christian W. schrieb:
> ISR (USART_RX_vect)

Darauf wurde nämlich schon hingewiesen.

Hab das Programm mal bei mir aufgespielt. Funktioniert. Ist denn auch 
sonst alles richtig angeschlossen? Hat alles vernünftigen Kontakt? 
Funktioniert der serielle Wandler?

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian W. schrieb:
> Aktuell ja nicht. Der Code stoppt ja nicht mehr. Allerdings wird auch
> der Code in der ISR nicht ausgeführt.

 Ziehe dein USB-Kabl aus PC raus, stecke es in irgendeine PowerBank
 oder ähnliches, verbinde Rx un Tx am Nano und lasse dein korrigiertes
 Programm (USART_RX_vect) laufen.
 Wetten, dass es geht ?

[Christian W. (christianw92)]

Hallo zusammen,

ich habe jetzt mal den Code verändert. Das aktuelle Program funktioniert 
perfekt. Das heißt Senden und Empfangen geht.

int main(void)
{
  
       DDRB |= (1<<PB5);
        UART_Init();
    
        while(1)
        {
        
    while (!(UCSR0A & (1<<RXC0)));
    UART_Daten = UDR0;
    PORTB ^= (1<<PB5);
      
    while (!(UCSR0A & (1<<UDRE0))){}
    UDR0 = UART_Daten;
       
  }   
}

Ich würde aber gerne den Interrupt verwenden. Ich habe auch versucht die 
ganze main leer zu lassen und nur beim Empfangen etwas zu tun, also ohne 
echo, nur ein Pin Toggle. Aber das geht einfach nicht, aber warum.:

ISR (USART_RX_vect)
{
  PORTB ^= (1<<PB5);
  UART_Daten = UDR0;
}

[M. K. (sylaina)]

Versuche mal folgenden Code (copy&paste)

Das funktioniert hier hervorragend.

#include <avr/io.h>
#include <avr/interrupt.h>

unsigned char empfang = 'A';

void uart_setup (uint16_t ubbr_value) {
  UBBR0 = ubbr_value >> 8;
  UBBR0 = ubbr_value & 0xff;

  UCSR0B |= (1 << TCEN0)|(1 << RXEN0)|(1 << RXCIE0);
}
void sendChar(unsigned char charToSend) {
  //Warten, dass der Sendespeicher frei wird.
  while( !(UCSR0A & (1 << UDRE0) );
  //Und Zeichen reinschieben zum Senden.
  UDR0 = charToSend;
}

int main(void) {
  //Initialisierungen/Einstellungen des AVR
  uart_setup( 103 );
  DDRB |= (1 << PB5);
  //interrupts ein.
  sei();
  //begin der Endlosschleife/ des Programms
  for(;;) {
    sendChar( empfang );
  }
  //hier kommt man nie hin
  return 0;
}
ISR ( USART_RX_vect ) {
  //Empfangenes Zeichen speichern
  empfang = UDR0;
  //Und Pin togglen
  PORTB ^= (1 << PB5);
}

[Marc V. (Firma: Vescomp) (logarithmus)]

M. K. schrieb:
> Das funktioniert hier hervorragend.

 Bestimmt nicht.
 Ohne überhaupt näher auf deinen Code einzugehen, aber UBBR0 gibt
 es bei AVR nicht - UBRR0 vielleicht ?
 Auch ist TCEN0 etwas fraglich - TXEN0 vielleicht ?

   while( !(UCSR0A & (1 << UDRE0) );
 Wieder mal an Klammern gespart ?

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian W. schrieb:
> Ich würde aber gerne den Interrupt verwenden. Ich habe auch versucht die
> ganze main leer zu lassen und nur beim Empfangen etwas zu tun, also ohne
> echo, nur ein Pin Toggle. Aber das geht einfach nicht, aber warum.:

 Also, folgendes geht sicher:

#define F_CPU 16000000UL
#include <util/delay.h>
#include <stdlib.h>
#include <stdint.h>

#include <avr/io.h>
#include <avr/interrupt.h>


uint16_t BAUD_Wert = 103;                //Baudrate (9600)
volatile uint8_t UART_Daten = 10;

ISR (USART_RX_vect)
{
  PORTB ^= (1<<PB5);
  UART_Daten = UDR0;
}


void UART_Init (void)
{
  UBRR0 = BAUD_Wert;                                    //Baudrate setzen
  UCSR0B |= (1<<RXCIE0) | (1<<RXEN0) | (1<<TXEN0);      // RX, TX und RX Interrupt aktivieren
  UCSR0C = (1<<UCSZ01) | (1<<UCSZ00);                   // 8 Bit Paketgröße einstellen
}


int main(void)
{
  
     DDRB |= (1<<PB5);
     UART_Init();
     sei();                          //Interrupts aktivieren
     PORTB |= (1<<PB5);
    
     while(1)
     {
          
//          while (!(UCSR0A & (1<<UDRE0))){}
//          UDR0 = UART_Daten;

          _delay_ms(20); 
     }
    
}

 Beim Start muss die LED leuchten.

 EDIT:
 Jetzt ist auch die HEX-Datei dabei.
 Probieren und melden wie es geht, OK ?

[Christian W. (christianw92)]

Inwiefern unterscheidet sich das von meinem Code. Die Baudrate wird bei 
mir korrekt eingestellt. Das Senden in der Endlosschleife habe ich auch 
schon weggelassen.
Bei mir Leuchtet die Led auch beim Start, nur wird der Code in der ISR 
nicht ausgeführt.
Ich werde dein Hex File dennoch ausprobieren.

[spess53 (Gast)]

Hi

> nur wird der Code in der ISR nicht ausgeführt.

sei() vergessen?

MfG Spess

[M. K. (sylaina)]

Marc V. schrieb:
> Ohne überhaupt näher auf deinen Code einzugehen, aber UBBR0 gibt
>  es bei AVR nicht - UBRR0 vielleicht ?

Ja, hab ich aus dem Kopf getippt. Aber das funktioniert mit Sicherheit 
wenn die Rechtschreibfehler raus sind. Das garantiere ich.

#include <avr/io.h>
#include <avr/interrupt.h>

volatile unsigned char empfang = 'A';

void uart_setup (uint16_t ubrr_value) {
  UBRR0 = ubrr_value >> 8;
  UBRR0 = ubrr_value & 0xff;

  UCSR0B |= (1 << TXEN0)|(1 << RXEN0)|(1 << RXCIE0);
}
void sendChar(unsigned char charToSend) {
  //Warten, dass der Sendespeicher frei wird.
  while( !(UCSR0A & (1 << UDRE0)) );
  //Und Zeichen reinschieben zum Senden.
  UDR0 = charToSend;
}

int main(void) {
  //Initialisierungen/Einstellungen des AVR
  uart_setup( 103 );
  DDRB |= (1 << PB5);
  //interrupts ein.
  sei();
  //begin der Endlosschleife/ des Programms
  for(;;) {
    sendChar( empfang );
  }
  //hier kommt man nie hin
  return 0;
}
ISR ( USART_RX_vect ) {
  //Empfangenes Zeichen speichern
  empfang = UDR0;
  //Und Pin togglen
  PORTB ^= (1 << PB5);
}

spess53 schrieb:
> sei() vergessen?

Einfach mal den Thread lesen ;). Bist nicht der erste, der das meint und 
oben kann mans nachlesen, dass das sei() drin ist.

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian W. schrieb:
> Inwiefern unterscheidet sich das von meinem Code.
 Dadurch, dass in der main() ein '_delay_ms(20);' steht.

> Das Senden in der Endlosschleife habe ich auch schon weggelassen.
 Gerade weil du (wahrscheinlich) eine leere Schleife in der main() hast,
 wird das Ganze vom Compiler wegoptimiert, dein Program landet beim
 <exit>, da wird dann ordentlich 'cli' ausgefuhrt und ein endloses
 'rjmp .-2'.
 Also, Interrupts sind gesperrt, da kannst du ewig warten, OK ?

 Probiere es doch mal endlich.

[Christian W. (christianw92)]

Also das HEX File funktioniert.

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian W. schrieb:
> Ist das Hex file auch für den Atmega328?

 Ja, probiere es doch.
 Oder paste mein Programm.
 Oder lese meine vorherige Post.

[M. K. (sylaina)]

Marc V. schrieb:
> Gerade weil du (wahrscheinlich) eine leere Schleife in der main() hast,
>  wird das Ganze vom Compiler wegoptimiert, dein Program landet beim
>  <exit>, da wird dann ordentlich 'cli' ausgefuhrt und ein endloses
>  'rjmp .-2'.

Dann würde ich den Compiler aber wegwerfen. Der avr-gcc macht sowas mit 
Sicherheit nicht.

[Christian W. (christianw92)]

Also ich habe keine Ahnung warum aber mein Code funktioniert jetzt auch.

Hier der Code:

#define F_CPU 16000000
#include <avr/io.h>
#include <util/delay.h>
#include <stdlib.h>
#include <stdint.h>
#include <avr/interrupt.h>


uint8_t BAUD_Wert = 103;//Baudrate (9600)
volatile uint8_t UART_Daten = 10;


ISR (USART_RX_vect)
{
  PORTB ^= (1<<PB5);
  UART_Daten = UDR0;
}




void UART_Init (void)
{
  
  UBRR0 = BAUD_Wert;//Baudrate setzen
  UCSR0B |= (1<<RXCIE0) | (1<<RXEN0) | (1<<TXEN0);// RX, TX und RX Interrupt aktivieren
  UCSR0C = (1<<UCSZ01) | (1<<UCSZ00);// 8 Bit Paketgröße einstellen
  
}


int main(void)
{
  
       DDRB |= (1<<PB5);
        UART_Init();
        sei();//Interrupts aktivieren
        PORTB |= (1<<PB5);
    
        while(1)
        {
          

         
  }  
    
}

Achja wegen der Baudrate: Warum Recourcen für ein 16 Bit Integer 
verschwenden wenn ein 8 Bit auch reicht.

[Marc V. (Firma: Vescomp) (logarithmus)]

M. K. schrieb:
> Dann würde ich den Compiler aber wegwerfen. Der avr-gcc macht sowas mit
> Sicherheit nicht.

 Mit Sicherheit macht der das.
 Für Compiler ist eine leere Schleife nutzlos, nach der Schleife gibt
 es auch keine Befehle mehr, was soll der deiner Meinung nach tun ?
 Deswegen gibt es auch Optionen für Optimierung.

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian W. schrieb:
> Achja wegen der Baudrate: Warum Recourcen für ein 16 Bit Integer
> verschwenden wenn ein 8 Bit auch reicht.

 Aber nur weil sich der Compiler besser beim AVR auskennt als du.

[Christian W. (christianw92)]

Marc V. schrieb:
> Aber nur weil sich der Compiler besser beim AVR auskennt als du.

Nein. Ich weiß das das Register 16 Bit groß ist. Ich habe es ausprobiert 
und es hat geklappt. Der Compiler benutzt immer erst das Low Byte.

[Marc V. (Firma: Vescomp) (logarithmus)]

Marc V. schrieb:
> Mit Sicherheit macht der das.

 LOL.
 Nehme alles zurück.

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian W. schrieb:
> Marc V. schrieb:
>> Aber nur weil sich der Compiler besser beim AVR auskennt als du.
>
> Nein. Ich weiß das das Register 16 Bit groß ist. Ich habe es ausprobiert
> und es hat geklappt. Der Compiler benutzt immer erst das Low Byte.

 Seit wann hat ein uint8_t  auch ein High-Byte ?

[Christian W. (christianw92)]

Nicht die Variable sondern das Register

[Carl D. (jcw2)]

Marc V. schrieb:
> M. K. schrieb:
>> Dann würde ich den Compiler aber wegwerfen. Der avr-gcc macht sowas mit
>> Sicherheit nicht.
>
>  Mit Sicherheit macht der das.
>  Für Compiler ist eine leere Schleife nutzlos, nach der Schleife gibt
>  es auch keine Befehle mehr, was soll der deiner Meinung nach tun ?
>  Deswegen gibt es auch Optionen für Optimierung.

Optimierung soll einen funktionsidentischen Ersatz für das, was dasteht 
liefern. Ein Ersatz der Endlosschleife in main() durch ein return wäre 
KEIN solcher.
Wenn in der Schleife eine nicht-volatile Variable hochgezählt wird, die 
nirgends sonst benutzt wird, dann darf das weg. Nicht aber die Schleife 
selbst.
Zum Glück kennt sich der XYZ-GCC aber besser mit C* und Optimierung aus, 
als so manscher Poster hier.

[Christian W. (christianw92)]

Mein Programm funktioniert ja mit leerer Schleife.

[Christian W. (christianw92)]

Problem: gelöst. Ursache: keine Ahnung. Thread beendet.

[M. K. (sylaina)]

Marc V. schrieb:
> Mit Sicherheit macht der das.
>  Für Compiler ist eine leere Schleife nutzlos, nach der Schleife gibt
>  es auch keine Befehle mehr, was soll der deiner Meinung nach tun ?
>  Deswegen gibt es auch Optionen für Optimierung.

Quatsch. Eine leere Schleife der Form

while(1){
}

wird der Compiler nicht weg optimieren da er nicht weiß was man damit 
bezwecken will und die Schleifenbedingung immer erfüllt ist. Er müsste 
dann auch sowas wie:

while(ADCSRA & (1 << ADSC));

oder, um beim obigen Beispiel zu bleiben

while( !(UCSR0A & (1 << UDRE0)) );

Das sind nämlich auch leere Schleifen. Das Einzige, was ein Compiler 
vielleicht wegoptimiert ist ein

while( 0 );

da diese Schleife nie ausgeführt werden wird.

[M. K. (sylaina)]

Carl D. schrieb:
> Wenn in der Schleife eine nicht-volatile Variable hochgezählt wird, die
> nirgends sonst benutzt wird, dann darf das weg. Nicht aber die Schleife
> selbst.

Richtig, die Schleife selbst optimiert der gcc mit Sicherheit nicht weg.

Carl D. schrieb:
> Zum Glück kennt sich der XYZ-GCC aber besser mit C* und Optimierung aus,
> als so manscher Poster hier.

Das will ich mal schwer hoffen. Ich bin mir sicher, ich hätte sonst auch 
einige Probleme mehr. Ein Glück weis der gcc es besser als ich, deshalb 
überlasse auch ich ihm die Optimierungen.

[Carl D. (jcw2)]

M. K. schrieb:
> Carl D. schrieb:
>> Wenn in der Schleife eine nicht-volatile Variable hochgezählt wird, die
>> nirgends sonst benutzt wird, dann darf das weg. Nicht aber die Schleife
>> selbst.
>
> Richtig, die Schleife selbst optimiert der gcc mit Sicherheit nicht weg.
>
> Carl D. schrieb:
>> Zum Glück kennt sich der XYZ-GCC aber besser mit C* und Optimierung aus,
>> als so manscher Poster hier.
>
> Das will ich mal schwer hoffen. Ich bin mir sicher, ich hätte sonst auch
> einige Probleme mehr. Ein Glück weis der gcc es besser als ich, deshalb
> überlasse auch ich ihm die Optimierungen.

Das ging nicht gegen dich, sondern gegen den Urheber dieser schrägen 
Vorstellung. Wie auch immer optimiert wird, es darf nie die Semantik 
eines Programms ändern.

[M. K. (sylaina)]

Carl D. schrieb:
> Das ging nicht gegen dich

So hatte ich es auch nicht aufgefasst ;)