Probleme mit UART_RX mit AtMega2560

[Björn G. (tueftler)]

Hi Ihr da.

Programmiere jetzt schon ne Zeit lang an einem recht großen Programm.

Jetzt bin ich an der Stelle angekommen, bei der ich die UART0 verwenden 
muß.
Diese UART wird nur empfangen können.
Daten: 2400_8n1.

Habe schon etliches ausprobiert und komme nicht drauf was da jetzt 
falsch sein sollte.
SpeicherOszi direkt an PortPin, Signal ist TTL-Pegel und sieht auch gut 
aus.
USB2Serial converter (FT232R) dran gebaut, kommt nur Unsinn rüber.
MAX232 dran gebaut - gleicher Unsinn.
Unsinn soll heißen, ich bekomme, wenn ich einzelne Zeichen sende, nur 
quatsch in die Variable geschrieben.
Wenn ich nach jedem Byte, einen Breakpoint setze und mir die Variable im 
Debugger anschaue habe ich andauernd 255 drin stehen.
Wenn ich nach 50byte erst triggere, dann habe ich auch andere Zeichen 
drin stehen - Aber sicherlich nicht die, die es sein sollten :-(

Anbei sende ich euch den C-Code von WinAVR:

void uart_rfc2_config(void)
{
  UBRR0H = 0x01;
  UBRR0L = 0xA0;  //2400baud

         //RXD_Enabled, Interrupt enabled
  UCSR0B |= (1<<RXEN0) | (1<<RXCIE0);                          //8bit
  UCSR0C |= (1<<UCSZ01) | (1<<UCSZ00);        
}            

uint8_t data[70]; //nur für Testzwecke vor der Funktion ;-)
ISR (USART0_RX_vect)
{
  cli();

         //Fehlerbehandlung falls FramingError, DataOverRun
  if (!(UCSR0A & ((1<<FE0) | (1<<DOR0))))                          {
    uart0zaehler++;               //global
    
    data[uart0zaehler] = UDR0;
    
    if (uart0zaehler == 69)
    {    
    uart0zaehler = 0;
    }

  }
  else                                //bei UART-Error, UDR leeren DOR & FE rücksetzen
  {
    data[0] = UDR0;
    UCSR0A &= ~(1<<DOR0);
    UCSR0A &= ~(1<<FE0);
  }
  
  sei();
}

Momentan benutze ich HTerm zu senden der Daten über die 
Serielle->Max232->uC.
Daten auch hier natürlich auf 2400_8n1 eingestellt.

Es ist nur die RX-Leitung und GND angeschlossen, da ich mehr nicht habe.

Evtl. kann mir ja jemand nen Tip geben, da ich momentan echt ratlos 
bin...

Gruß, Björn

[gastq (Gast)]

Hallo,

jetzt mal rein interessehalber.

Warum deaktivierst du innerhalb der Interrupt Schleife die 
Interrupts(CLI() und dann am Ende SLI()??

Zu deinem eigentlichen Problem:
Was passiert wenn du die Routine mit der Fehlerbehandlung (Framming 
Error) weglässt?

Und natürlich noch die Standartfragen:
- Was für nen Quarz hängt den dran? Oder benützt du etwa den internen 
Osszilator?..->Dann wird das nämlich nix

gruß

uli

[Björn G. (tueftler)]

Nabend.

Ich deaktiviere diese, das kein anderer Interrupt in dieser Zeit 
abgearbeitet wird.
Hatte einmal darüber ein Artikel gelesen.

FramingError sowie DOR kommen bisher nicht vor, also ist das 
auskommentieren hierbei zwecklos.
Habe es trotzdem einmal getestet - Wie gedacht ohne Erfolg.

Quarz ist natürlich extern und 16MHz.

Björn

[Björn G. (tueftler)]

Nachtrag:

Habe nun auch mal einen anderen Rechner, wie auch verschiedene 
Baudraten, interner- und externer Quarz getestet.

Leider alles ohne Erfolg...Ich verstehs nicht :-(

Björn

[Björn G. (tueftler)]

Noch mal ein Nachtrag - Nur diesmal einer der positiven Sorte...

Da ich schon 1,5 Tage nur an diesem Fehler hänge, habe ich nun 
zusätzlich im Mikrocontroller-Chat Rat gesucht.

Binnen 15min war das Problem aus der Welt :-)

Nachdem wir mit einem Oszilloskop die Zeiten gemessen hatten, dämmerte 
es allmälich das der Controller wohl nicht mit voller Geschwindigkeit 
läuft.

Fuses waren aber in Sachen externer Oszillator richtig gesetzt.
Nach ein wenig suchen fand ich dann einen zusätzlichen 8x Prescaler in 
den fusebits.

Als ich diesen dann deaktiviert hatte lief alles problemlos.

Danke an alle die mir bei meinem Problem weiter geholfen haben und 
natürlich auch denen, die sich Gedanken drum gemacht haben, aber genau 
so ratlos waren wie ich selber, grins.

Bis demnächst,
björn

[gastq (Gast)]

Hi Björn,

Ja daran hätte ich auch denken können. Dieser blöde Prescaler hat mich 
auch schon mal 3 Tage gekostet. Ich hatte damals immer noch nen Mega 32 
nebendran bei dem es diese Fuse nicht gab und auf dem immer alles 
lief... Das war echt zum verrücktwerden.

Gruß

Uli

[Falk B. (falk)]

http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART

Ist als Prüfpunkt aufgenommen.

MfG
Falk

[Björn G. (tueftler)]

Hi ihr beiden.

@Uli: Ja dieses Fuse hatte ich bei meinen letzten Projekten mit einem 
Mega16 auch nicht entdecken können. Ich frage mich nur, warum diese 
Einstellung Standartmäßig auf true gesetzt ist. Was soll das bringen, 
außer Verwirrung bei den Programmieren. (Kenne da schon zwei Beispiele, 
grins).

@Falk: Hey, das ist ja mal ne super Sache! Bin über die Seite jedoch 
bisher nie gestolpert. Wie wäre es, wenn sie im Hauptmenü unter den AVR 
Punkt "AVR-GCC-Tutorial" kommen würde? Evtl. ist das ja auch schon 
vorgesehen...

Naja, dann kann ich ja nun endlich mal mit dem eigentlichen 
programmieren des Parsers anfangen - War das Wochenende ja doch nicht so 
um sonst :-)

Schönen Sonntag noch an alle!
Björn

[Falk B. (falk)]

@  Björn G. (tueftler)

>Einstellung Standartmäßig auf true gesetzt ist. Was soll das bringen,
>außer Verwirrung bei den Programmieren.

Der Controller läuft auch mit minimaler Spannung stabil. Atmel weiss ja 
nicht, bei welcher Spannung der AVR eingesetzt wird. Wenn der dann 
losrennt wie ein Weltmeister kann man ihn nicht stabil per ISP 
umprogrammieren.

>@Falk: Hey, das ist ja mal ne super Sache! Bin über die Seite jedoch
>bisher nie gestolpert. Wie wäre es, wenn sie im Hauptmenü unter den AVR
>Punkt "AVR-GCC-Tutorial" kommen würde? Evtl. ist das ja auch schon
>vorgesehen...

Ist doch schon drin! Unter Tips und Hinweise. Der Wald und die Bäume . . 
. ;-)

http://www.mikrocontroller.net/articles/AVR

MfG
Falk

[Jörg W. (dl8dtl) (Moderator)]

Falk Brunner wrote:

>>Einstellung Standartmäßig auf true gesetzt ist. Was soll das bringen,
>>außer Verwirrung bei den Programmieren.
>
> Der Controller läuft auch mit minimaler Spannung stabil.

Die Fuse ist notwendig geworden, seitdem der RC-Oszillator von vier
verschiedenen (1 MHz, 2 MHz, 4 MHz, 8 MHz), einzeln per Fuse
auszuwählenden (von denen dann nur der 1-MHz-Oszillator ab Werk
kalibriert war) auf einen einzigen (8 MHz und kalibriert ab Werk)
umgebaut worden ist.  Da 8 MHz aber zu schnell für die untere
Betriebsspannungsgrenze ist, muss der Oszillator runterskaliert
werden, und man hat sich für das Beibehalten der 1-MHz-Standard-
Frequenz entschieden, indem man für das Runterskalieren den
Taktvorteiler auf 1:8 stellt.  Anders als früher ist das aber jetzt
eine Laufzeiteinstellung, der Effekt der CKDIV8-Fuse ist nur, die
Voreinstellung des Vorteilers zwischen 1:1 und 1:8 umstellen -- zur
Laufzeit kann man sie aber immer und ganz ohne Fuse selbst ändern.

Der neue RC-Oszillator ist übrigens drastisch stabiler als der
alte.  Typischerweise bricht eine RS-232-Kommunikation noch nicht
zusammen, wenn Vcc sich von 5 V auf 3,3 V ändert.

[Björn G. (tueftler)]

Nabend!

Na gut, das ist natürlich ein Grund.

Leider ist es echt einfach darüber zu fallen ;-9

Wieder was dazu gelernt ;-)

Björn