UART receive - Data Overflow

[Thomas L. (thomasblue)]

Hey Leute,
wenn ein Data Overflow beim Empfangen von Zeichenketten mittels 
Receive-ISR auftritt, woran kann das liegen (auf AT90CAN128)?

Ich habe mehrere Ideen:
1. Andere Interrupts laufen und verhindern das rechtzeitige Bearbeiten 
der ISR
2. Baudrate zu schnell
3. Fehlerhafte Kabel (durch Kabelbruch schnellere, fehlerhafte 
Flankenwechsel)
4. Abarbeitung in der ISR zu lang

Bei Punkt 3. sollte dann ja auch das Framing Error Bit gesetzt werden, 
oder?

Dazu eine generelle Frage: Soweit ich das sehe, muss man in einer ISR 
die Interrupts nicht deaktivieren, richtig?

Gibt's sonst noch andere Fehlerquellen?

[Knut B. (Firma: TravelRec.) (travelrec)]

Thomas L. schrieb:
> Dazu eine generelle Frage: Soweit ich das sehe, muss man in einer ISR
> die Interrupts nicht deaktivieren, richtig?

Nein, muss man nicht.

Zu Deiner Frage: 1, 3 und/oder 4 wären durchaus möglich.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ich schlage 2 auch noch vor... ;-)

Aber das ist einer der liebsten Fehlerursachen:
Thomas L. schrieb:
> 4. Abarbeitung in der ISR zu lang

Als Symptom kann der dann nämlich durch das Verringern der Baudrate 
evtl. umgangen werden...

[Klaus2m5 (Gast)]

Thomas L. schrieb:
> 3. Fehlerhafte Kabel (durch Kabelbruch schnellere, fehlerhafte
> Flankenwechsel

Das Timing hängt allein von der Baudrate ab, nicht von dem empfangenen 
Signal. Ob das Signal nach dem Startbit innerhalb eines Frames 1 oder 
1000 Bitwechsel enthält ist wurscht. Natürlich sind die Daten dann hin, 
aber Overruns sind dadurch nicht zu erwarten.

[Thomas L. (thomasblue)]

ok danke für eure Antworten.
Ich habe ein wenig getested:
1. Ist ausgeschlossen, habe alle anderen Quellen deaktiviert und eine 
bad isr installiert.
2. Baudrate ist bei 38,4 @ 16 Mhz AT90CAN128 - folglich auch 
ausgeschlossen
4. in der ISR wird nur noch der Buffer zugewiesen.

Wenn es nicht noch weitere Gründe gibt, kann es doch ein fehlerhaftes 
Kabel sein? Habe ich was bei der Initialierung übersehen?

#define F_CPU = 16000000UL
void rs232_0_init()
{
  UCSR0A = 0x00;
  // Communication Parameters: 8 Data, 1 Stop, No Parity
  UCSR0C = _BV(UCSZ01) | _BV(UCSZ00);
  // Set BAUD depending on F_CPU
  rs232_0_38400(); // Calculates baud (descriped in AVR manual)
  // Enable Receiver, Transmitter and Rx complete interrupts
  UCSR0B = _BV(RXEN0) | _BV(TXEN0) | _BV(RXCIE0);
}

Zur Info: Wenn nur zwei bytes hintereinander gesendet werden, ist die 
Welt in Ordnung ;-)

[Klaus2m5 (Gast)]

Thomas L. schrieb:
> Zur Info: Wenn nur zwei bytes hintereinander gesendet werden, ist die
> Welt in Ordnung ;-)

Wenn die ersten 2 Bytes O.K. sind, funktioniert die Hardware 
einwandfrei. Da der Overrun erst ab dem 3. Byte auftritt, kann man 
daraus schließen, das schon das 1.Byte nicht rechtzeitig aus dem 
UDR-FIFO gelesen wird. Ein Overrun entsteht erst, Wenn das 2 Byte große 
UDR FIFO bereits voll ist und das 3. Byte im Schieberegister vom 
nächsten Byte überschrieben wird. Also wurde innerhalb von 3 Bytes das 
UDR nicht gelesen.