www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART invertiert


Autor: mef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin verwirrt und brauche Eure Hilfe.

Ich habe hier ein Controllerboard von meiner Uni mit einem AT90CAN128 
mit 16Mhz drauf. Eine von den beiden UARTs (UART1) ist mit einer 
USB->UART-Bridge (CP2102) verbunden.

Ich laß' den Controller in einer Endlosschleife das Zeichen 'K' (0x4B)
senden. Sowohl unter Windows als auch unter Linux wird die Brigde 
erkannt (mit VendorID:ProductID) und unter Linux bekomme ich mein 
/dev/ttyUSB0. Verbinde ich mich mit einem Terminalprogramm (HyperTerm u. 
Minicom) bekomme ich keine 'K's.

Baudrate und Frameformat sind richtig eingestellt (300Bd, 8N1). Ich habe 
mein Oszi an den TxD-Pin vom Controller drangehängt und bekomme 
folgendes Frame: 1010010110

Wobei das Signal invertiert ist: 1 = 0V und 0 = 5V. Ist diese 
Invertierung wie bei der RS-232 korrekt? Ich dachte eigentlich schon, 
allerdings bin ich mir nach folgendem Versuch nicht mehr sicher:

Nachdem ich den USB nicht dazu gebracht habe mir Daten auszuspucken, 
habe ich einfach zwei Drähte an das Board gelötet und einen MAX232 nach 
folgendem Schema: http://www.the-starbearer.de/Schaltungen/Max232.htm

Als ich meinen SUB-D-Stecker an meinen Rechner anschloß, bekam ich 
wieder keine Daten vom Terminal. Die Messung mit dem Oszi ergab, daß das 
Frame gesendet wird und mein Pegel zwar von -12 bis 12 geht, aber daß 
das Signal nochmal invertiert wird (im MAX232 ist ja ein Inverter 
drinnen): 1010010110, aber mit -12V als logische 0.

Meine Theorie: Der UART1 vom Controller sendet das Signal 
fälschlicherweise Invertiert (also 5V = logische 0), deswegen konnte der 
CP2102 kein Frame lesen, weil er das Startbit nicht gefunden hat und 
beim MAX232 wurde das Signal nochmal Invertiert und mein Terminal konnte 
auch kein gültiges Frame finden (wg. Startbit).

Ich habe im Datenblatt vom AT90CAN128 nichts zum Thema invertieren 
gefunden. Die Leitungen des Controllers sind direkt mit den Leitungen 
des CP2102 verbunden, ist das ein Fehler im Board design?

Irgendwelche Vorschläge? Sonst löte ich im Akt der Verzweiflung noch vor 
den MAX232 einen zusätzlichen Inverter?

Grüße mef

Autor: mef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also irgendwo ist der Wurm drinnen. Das mit dem Invertiertem UART 
scheint eine Sackgasse zu sein, denn schicke ich ein 0xFF, sind beim 
Controller die meisten Pegel bei +5V und nach dem MAX232 sind die 
meisten Pegel bei -12V.
Vielleicht bin ich ja auch einfach nicht in der Lage das Oszi zu lesen?
Ich teste veschiedene Zeichen und versuche Euch die Oszibilder 
darzustellen.

Bei 0x00 bekomme ich: -_________-_________
Bei 0xFF bekomme ich: ---------_---------_

Aber bei einem 'P' (01010001) bekomme ich: -_____-_-_-_____-_-_-_____

Bei 'K' (01001011) sehe ich folgendes: -_-_--_-__-_-_--_-__-_-_--_-
(Ich dachte die ganze Zeit der UART vom Controller sei invertiert, weil 
das 'K' mit Negativer Logik einen gültigen Frame ergibt)

Ich stehe irgendwie auf dem Schlauch. Für Tipps wäre ich dankbar...

Grüße mef

Autor: 2919 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RS232 (V24) ist invertiert, dh der tiefe Pegel ist eine Eins.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Die UART fügt deinem Byte noch ein Startbit=1 am Anfang und ein 
Stopbit=0 am Ende zu. D.h. ein übertragenes Byte besteht aus 10 bits.

MfG Spess

Autor: 2919 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Oszibilder stimmen. Sie sind aber am Controller gemessen. Der Max232 
invertiert das Signal. Es gibt noch ein Start und Stop Bit 
unterschiedlichen Levels hinzu. Ich denk Spess53 hat die Pegel der V24 
geschrieben. Und dann muss man noch wissen dass das Schieberegister des 
UART das niederwertige Bit zuerst rausschiebt. Ich hab's grad 
kontrolliert, und mein ueblicher AVR hat im Datenblatt das UART genau 
erklaert. Unter "USART - Frame Formats"

Autor: Tishima (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Wie erzeugst Du mit nem AVR 16 Mhz ne Baudrate von 300 ?
Das kommt mir "Spanisch" vor....

Errechne mal anhand der Taktfrequenz und Registerinhalte die 
tatsächliche Baudrate.

gruß,
Bjoern

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Meine Angaben haben sich auf den TTL-Pegel nach der UART bezogen. Nach 
dem Startbit folgt das MSB, nicht das LSB. Deine 'Diagramme' stellen die 
erwarteten Bitfolgen dar. Also arbeitet die USART wie erwartet. Welchen 
Wert hat dein UBR-Register. Bei 16MHz und 300Bd sollte es $0D04 sein.

MfG Spess

Autor: Durchblicker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du ohne Unterbrechung sendest, kann die empfangende UART evtl. 
nicht korrekt auf den ankommenden Datenstrom synchronisieren, sie 
interpretiert das falsche aktive Bit (low) als Startbit. Daher können da 
schon falsche Daten ankommen. Mit einem Neustart des Programms sollten 
die Daten aber schon stimmen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tishima (Gast)

>Wie erzeugst Du mit nem AVR 16 Mhz ne Baudrate von 300 ?

Mit einem UBRR von 16000000/16/300-1 = 3332. Die neuen AVRs haben doch 
alle einen 12 Bit Vorteiler.

>Das kommt mir "Spanisch" vor....

Porque muchacho?

MfG
Falk

Autor: 2919 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wie auch immer du das mit dem LSB und dem LSB machen willst ... ein 
Auszug vom Mega32. --> Start, Bit0..Bit7, Stop

Autor: mef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schon festgestellt sendet die UART vom Controller nicht invertiert 
(also 1=0V), sondern nur das LSB zuerst -nicht andersherum wie 
fälschlicherweise erwartet.

Ich hatte zwei Fehler:

1. Was wie ein Baudratenfehler aussah, war ein Baudratenfehler. Ich 
hatte anstelle UBBRH und UBBRL nämlich zweimal UBBRH geschrieben 
(Copy&Paste-Fehler), dadurch war die Baudrate ein Tick schneller (ca. 
30µs) als mein PC, welcher dann die Stop-Bits bzw. das Idlesignal 
fälchlicherweise als Datenbits gelesen hat, was dann zu Zeichen wie 0xF0 
geführt hat, die mein minicom nicht angezeigt hat. Auf dem Oszi fiel 
diese Ungenauigkeit nicht auf.
Ich hatte auch nicht mehr mit den 300bd gearbeitet sondern mit 2400bd.

2. Die USB-Bridge geht wohl wegen eines Layout-fehlers im Board nicht. 
Der /Reset-Pin ist nirgends angeschlossen. Wegen seines Low-Active 
dürfte er die ganze Zeit reseten und keine Zeit haben sich um das 
UART-Signal zu kümmern...


Danke für Eure Hilfe, ohne den Zaunpfahlwink mit dem LSB (Ja, wer lesen 
kann ist im Vorteil) würde ich wohl immernoch darüber grübeln.

Grüße mef

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.