UART Übertragungsproblem

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

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.

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ß

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

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

@ holger
@ Jean Player

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

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"

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ß

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?

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

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.

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ß

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?

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

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

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?

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

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

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

Gruß
Daniel