UART Übertragungsproblem

[Daniel H. (daniel1412)]

Hi Zusammen, bin jetzt seit ca. 2 Wochen fleißig dabei mich in die Welt 
der Microcontroller einzuarbeiten. Habe bis jetzt auch alles soweit 
geschafft ohne doofe Fragen in das Forum zu schreiben.

Aber jetzt ist es doch so weit.

Also ich habe ein kleine Programm geschrieben welches mir nur Testweise 
ein 8-Bit Wert senden soll.
Benutze auch einen Externen Quarz (Fuses gesetzt), da es ja mit dem 
Internen immer wieder Probleme wegen Kalibrierung gibt.

So weit so gut, ich bekomme auch immer einen Empfang in HTERM (oder auch 
Hyperterminal) aber das Zeichen ist nicht das was ich gesendet habe.
Ich weiß das meistens der Fehler in fehlerhafter Baudrate liegt, aber 
ich finde ihn einfach nicht. Habe auch schon mit dem Oszi nachgemessen 
ob die Eingestellte Baudrate auch wirklich rauskommt, und das scheint zu 
stimmen.


C-Code:

#include <avr/io.h>
 
#define F_CPU 3686400UL      // 3686400 Systemtakt in Hz - Definition als unsigned long beachten >> Ohne ergeben Fehler in der Berechnung
#define BAUD 4800UL         // Baudrate
#define UBRR_VAL 47      // Wert für Baudrate bei der Frequenz aus Datasheet

 
int main(void)
{
  UCSRB |= (1<<TXEN);    // Senden eingeschaltet
  UCSRC |= (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0)|(1<<USBS);  // Zugriff auf UBRRH / Assynchron / Character Size = 8-Bit

  while(1)
  {
  
    
  
      UBRRH = UBRR_VAL >> 8;      //High Nibble schreiben
      UBRRL = UBRR_VAL;        //Low Nibbel schreiben

      while (!(UCSRA & (1<<UDRE)))  // warten bis Senden moeglich
        {
        }
 
        UDR = 0xAA;                    // schreibt den Hex-Wert auf die Schnittstelle

  }


}

Also der Hex Wert 0xAA sollte ja eigentlich dem Binärwert von 10101010 
entsprechen. Aber ich bekomme über HTERM immer den Wert 11010011.

Kann es irgendwie sein das HTERM bei mir da die Start- und Stoppbits 
durcheinander bringt? Eine andere Idee habe ich leider nicht mehr.

Im Anhang nochmal der Screenshot von HTERM.

Hoffe das ist nicht wieder so eine Anfängerfrage, aber ich währe 
wirklich sehr dankbar, wenn mir hier jemand weiterhelfen kann.

Gruß
Daniel

[Michael U. (amiga)]

Hallo,

sieht eigentlich ok aus.
Du bist sicher, daß er mit dem Quarz läuft und nicht doch mit den 
internen 1MHz?

Gruáus Berlin
Michael

[Daniel H. (daniel1412)]

Ich bin mir da schon relativ sicher mit der Frequenz.
Habe ja auch die Baudrate mit dem Oszi Kontrolliert und hier komme ich 
(mit Ablesefehler) auf ca. 4800 bits/s.

Also denke doch dass das mit der Freqenz passt.

[holger (Gast)]

Du hast zwei Stopbits eingestellt. Nimm das mit dem USBS
mal ganz raus.

[Jean P. (fubu1000)]

Hi,

UCSRC |= (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0)|(1<<USBS);
Du setzt in dieser Zeile auf 2 StopBits , hast in HTERM aber nur 1 
StopBit eingestellt-

Gruß

[Michael U. (amiga)]

Hallo,

gut, dann nehmen wir die Ausschlußmethode...

AVR raus, RX und TX brücken. Dann muß im Terminalprogramm das Echo der 
Eingaben kommen.
Natürlich unter der Voraussetzung, Du hast RX auch verdrahtet.

Was hast Du als Pegelwandler dran? MAX232? Stimmen da die Spannungen?

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

Jean Player schrieb:
> Hi,
>
> UCSRC |= (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0)|(1<<USBS);
> Du setzt in dieser Zeile auf 2 StopBits , hast in HTERM aber nur 1
> StopBit eingestellt-

Das stört aber hier nicht. Umgekehrt würde es stören, also Sender 1 
Stoppbit, Empfänger erwartet aber 2.

Das Stoppbit ist Ruhepegel, der kann dauern wie er will bis das nächste 
Startbit kommt.

Gruß aus Berlin
Michael

[Stefan E. (sternst)]

@ holger
@ Jean Player

Irrelevant. Wenn der Sender 2 Stoppbits sendet, spielt es keine Rolle, 
ob am Empfänger 1 oder 2 Stoppbit eingestellt sind.

[Daniel H. (daniel1412)]

Hmm, das war nur mal ein Test von mir, hatte leider vergessen das wieder 
rauszulöschen.

Aber auch ohne diesen Wert funktioniert es nicht. Jetzt ändern sich 
allerdings die Werte von der HTERM ausgabe auch noch.

HTERM ausgabe nochmal im Anhang.

Achsoo vielleicht sollte ich noch dazu sagen, dass die Übertragung nicht 
über RS232 funktioniert sonder per USB mit dem "mySmartUSB MK2
Version 2.11"

[Jean P. (fubu1000)]

Jop Michael hast Recht. Da war ich wohl zu schnell.

Auszug ausm Datenblatt:
• Bit 3 – USBS: Stop Bit Select
This bit selects the number of stop bits to be inserted by the 
trAnsmitter. The Receiver
ignores this setting.

Gruß

[Daniel H. (daniel1412)]

Also das mit der Brück von RxD zu TxD ohne den AVR geht nicht. Kann das 
evtl. an dem USB teil liegen, oder müsste der Trick auch mit dem 
mySmartUSB MK2 gehen?

[Michael U. (amiga)]

Hallo,

naja, auch damit müßte ja ein Echo mit Brücke TxD-RxD gehen, ich kenne 
das Teil allerdings nicht.

Wenn es nur eine USB-seriell-Bridge zur Verfügung stellt, muß Echo 
gehen.

Gruß aus Berlin
Michael

[Daniel H. (daniel1412)]

Also das mit dem Brücken geht nicht wie gesagt. Allerdings habe ich noch 
ein Testprogramm (dazu habe ich aber leider keinen c-Code) mit dem kann 
man einen String senden, und dieser wird dann auch gleich wieder 
zurückgesendet. Dieses Testprogramm funktioniert auf jeden Fall.

[Jean P. (fubu1000)]

Hatte mich interressiert was das fürn Teil ist und habe die Technische 
Beschreibung mal überflogen. Haste im Treiber vom mySmartUsb auch die 
4800 Baud eingestellt ?

Gruß

[Daniel H. (daniel1412)]

Ja, die Baudrate ist auch im Treiber eingestellt.

Jetzt muss ich mich korrigieren, habe nochmal alles neu angeschlossen 
und jetzt funktioniert die Brücke von TxD zu RxD auch einwandfrei. 
Kriege das gesendete wieder zurück.

Also muss das Problem wohl doch irgendwie in meinem C-Code liegen oder?

[Michael U. (amiga)]

Hallo,

wohl zu warm hier heute, jetzt erst gesehen...

  while(1)
  {



      UBRRH = UBRR_VAL >> 8;      //High Nibble schreiben
      UBRRL = UBRR_VAL;        //Low Nibbel schreiben

      while (!(UCSRA & (1<<UDRE)))  // warten bis Senden moeglich
        {
        }

        UDR = 0xAA;                    // schreibt den Hex-Wert auf die 
Schnittstelle

  }



Du setzt jedesmal gleich nach dem Schreiben der Daten die Baudrate in 
Deiner Main-Loop und damit macht der UART natürlich Mist.

      UBRRH = UBRR_VAL >> 8;      //High Nibble schreiben
      UBRRL = UBRR_VAL;        //Low Nibbel schreiben

gehört natürlich zur Initialisierung VOR die While-Schleife...

Gruß aus Berlin
Michael

[Daniel H. (daniel1412)]

Das ist ja der pure Wahnsinn, und daran sitze ich jetzt schon Tage.

Es funktioniert jetzt.

Vielen dank an alle dir mir Versucht haben zu helfen und vorallem danke 
Michael.

Gruß
Daniel

[Daniel H. (daniel1412)]

Hmm, schade die freude war wohl zu früh.

Habe jetzt herausgefunden, das es zwar teilweise funktioniert. Dies aber 
anscheinend stark davon abhängt wann ich HTERM starte. Wenn ich öfter 
Connecte und Disconnecte, dann kommen verschiedene Werte raus. naja, 
dafür ist wohl der Wert 0xAA nicht geeignet, da er nicht genau 
unterscheiden kann welches das Start und Welches das Stoppbit ist 
oder????

Was macht man denn um solchen Datenwust zu vermeiden?

[Peter (Gast)]

> Was macht man denn um solchen Datenwust zu vermeiden?
Am besten erst senden wenn den Empfänger bereit ist.

[Daniel H. (daniel1412)]

Also komme ich um ein Handshake verfahren nicht vorbei??? Wollte Daten 
so einfach wie möglich nur in eine Richtung übertragen.

[kurz (Gast)]

>Wollte Daten
>so einfach wie möglich nur in eine Richtung übertragen.


Und warum machst Du es nicht einfach?

Pack die Daten in einen Protokollrahmen, sende das Telegramm an den 
Empfänger. Sende das telegram einfach periodisch.
Der Empfänger nimmt die Daten nur an, wenn er das Telegramm korrekt 
erfaßt hat.

Und gut.

[Michael U. (amiga)]

Hallo,

wenn der Empfänger immer aktiv ist, geht es.

Wenn die Pause zwischen 2 Datenpaketen länger ist als eine Bytedauer + 
Start + Stop und etwas Reserve, ist nur das erste Paket kaputt, beim 2. 
wird das erste Startbit dann wieder richtig erkannt.

Gruß aus Berlin
Michael

[Daniel H. (daniel1412)]

Super, vielen dank. Das ist doch eine einfachere Lösung als das mit dem 
Protokoll.

Gruß
Daniel