ISR fuer UART in AVR

[Owen S. (senmeis)]

Hallo,

ich benutze AT90CAN128 von Atmel und habe eine ISR-Funktion und eine 
User-Funktion für UART geschrieben. Baudrate = 19,200 bits/s, Quarz = 8 
MHz.

SIGNAL(SIG_UART0_RECV)
{
  receive_uart_data = UDR0;  // Datenbyte speichern
  new_receive_uart_data = 0x01;  // Mitteilung vom neuen Datenbyte
}

void user_application()
{
  if (new_receive_uart_data == 0x01)  
  {
  // Datenbyte bearbeiten
  new_receive_uart_data = 0x00;
  }
}

Frage : Kann das passieren, dass UART-Daten verloren gehen, wenn 
UART-Daten zu schnell ankommen ?

Gruss
Senmeis

[Falk B. (falk)]

@ Owen Senmeis (senmeis)

>SIGNAL(SIG_UART0_RECV)

Das heisst beim aktuellen AVR-GCC ISR(), siehe Doku.

>Frage : Kann das passieren, dass UART-Daten verloren gehen, wenn
>UART-Daten zu schnell ankommen ?

Ja, wenn dein Programm zu viel Zeit zur Verarbeitung braucht, siehe 
Interrupt.

MFG
Falk

[Stefan B. (stefan)]

Ja. Es können Verluste an mehreren Stellen auftreten.

1/ Die ISR läuft und es kommt ein neues Zeichen in der UART Hardware an. 
Wenn das nicht gespeichert werden kann, geht es verloren. Eher 
unwahrscheinlich bei Baudrate = 19,200 bits/s, Quarz = 8 MHz, aber je 
nach dem Restcode kann man das provozieren.

2/ user_application() wird zu selten ausgeführt. Der Puffer 
receive_uart_data ist nur ein Byte gross. Wenn zwischen zwei ISR 
Aufrufen kein user_application() Aufruf ist, geht das ältere Byte 
verloren.

3/ Man sieht die Definition von new_receive_uart_data nicht, 
insbesondere ob es volatile typisiert ist. Der Compiler kann in 
user_application() Code produzieren, der nicht berücksichtigt, dass eine 
ISR diese Variable zu einem beliebigen Zeitpunkt ändert.

[Owen S. (senmeis)]

Hallo,

danke für die Hinweise.

Noch eine Frage zur angegebenen Anleitung "Interrupt". Zitat aus der 
Anleitung:
"D.h. während der UART selbsttätig das Zeichen sendet ist die CPU zum 
Warten verdammt."

Im Gegensatz habe ich immer folgenden Code benutzt, um ein Byte zu 
senden, also keine Interrupts.

// einzelnes Senden
void USART0_Tr_UINT8(UINT8 num8)
{
  while(!(UCSR0A&(1<<UDRE0)));
  UDR0 = num8;
}

Kann das Programm hier blockiert werden? Bisher habe ich noch keine 
Probleme gehabt.

Gruss
Senmeis

[STK500-Besitzer (Gast)]

>Kann das Programm hier blockiert werden? Bisher habe ich noch keine
>Probleme gehabt.

Nein, eigentlich nur, wenn das Senden nicht gestattet ist (TXEN muß zum 
Senden gesetzt sein).

>Der UART ist ein oft benutztes Modul eines Mikrocontrollers. Anfänger >nutzen ihn 
meist im sogenannten Polling Betrieb (engl. to poll, abfragen).
>"D.h. während der UART selbsttätig das Zeichen sendet ist die CPU zum
>Warten verdammt."

Aus dem Zusammenhang gerissen kann man einen anderen Sinn hinter der 
Aussage vermuten.

>Im Gegensatz habe ich immer folgenden Code benutzt, um ein Byte zu
>senden, also keine Interrupts.

Bei einem gepufferten UART (zwei Bytes werden gespeichert) und geringer 
Datenmengen spricht nichts gegen die Poll-Methode.
Wenn man aber viele Daten (vielleicht auch noch relativ schnell) 
verschicken will, sollte man das "im Hintergrund" per ISR und 
Daten-Puffer lösen. Der Controller führt zwischen zwei Interrupts 
mindestens eine Anweisung aus.

[Falk B. (falk)]

@ Owen Senmeis (senmeis)

>Kann das Programm hier blockiert werden?

Sicher durch die While-Schleife. Wobei das keine Blockieren im Sinn von 
endlos festfressen ist, sondern halt warten bis der FIFO des UARt 
leer ist.

> Bisher habe ich noch keine Probleme gehabt.

Das hat ja auch keiner behauptet, aber die CPU muss dennoch warten, wenn 
du z.b. einen String mit 10 Zeichen senden willst.

MFG
Falk