ich bin recht neu in der Thematik µC Programmierung und habe auch gleich eine Frage. Ich versuche am ATMega328P über UART ein Zeichen zu Senden und dieses über RS232 am PC in TeraTerm anzuzeigen.
Prinzipiell funktioniert das Ganze auch, ich verwende eine externe 16MHz Clock und die Baudrate 9600 sollte auch in Ordnung sein.
Allerdings kommt aktuell das falsche Zeichen an.
Sende ich beispielsweise ein G vom µC, so empfängt der PC ein \.
G = 0100 0111
\ = 0101 1100
Ich habe nun rausgefunden woran das liegt. Beim TTL Pegel ist eine 1 auch eine logische 1. Beim RS232 Pegel hingegen ist die Spannung invertiert, dort ist eine 1 eine logische 0. Zudem ist bei mir die Kommunikation um einen Takt verschoben. Ich habe mal versucht das Ganze zu illustrieren (siehe Anhang).
Meine Frage ist nun, wie ich das Problem lösen kann. Gibt es eine einfache Möglichkeit die Bits am UART Ausgang zu invertieren, beispielsweise über das Setzen einer 1 im Register? Im Datenblatt sehe ich dazu aber leider nichts...
Du /musst/ einen RS232-Pegelwandler verwenden. Spätestens wenn Du mit Deinem µC Daten vom PC empfangen willst, wird der sonst das Zeitliche segnen, denn die Pegel, die der PC an der RS232-Schnittstelle ausgibt, liegen weit jenseits dessen, was die Eingänge deines µC überleben.
Üblicherweise verwendet man einen MAX232, dieser Pegelwandler enthält praktischerweise eine Ladungspumpe, und kann sich so die benötigen Spannungen selbst erzeugen.
Du /musst/ einen RS232-Pegelwandler verwenden. Spätestens wenn Du mit
Deinem µC Daten vom PC empfangen willst, wird der sonst das Zeitliche
segnen, denn die Pegel, die der PC an der RS232-Schnittstelle ausgibt,
liegen weit jenseits dessen, was die Eingänge deines µC überleben.
Dem PC schadet das nichts. Aber der UART-Rx-Port am µP ist vermutlich nach den Tests schon defekt. Das hat der OP nur noch nicht gemerkt, weil er den µP nur als Sender nutzt.
Man kann den Pegel mit Widerstand plus Zener-Diode begrenzen, aber das löst das Problem mit dem invertierten Pegel nicht.
vielen Dank für eure schnellen Antworten. Ich habe ein RS232 Shield dazwischen geschaltet, auf diesem befindet sich ein MAX3232. Genau das Teil, dass Thomas im ersten Link gepostet hat.
Ich gehe also davon aus, dass die Transformation des Spannungspegel funktioniert, da ja auch etwas in TeraTerm ankommt. Aber allerdings das falsche Zeichen da die Logik Pegel nicht invertiert sind.
Ein Indiz dafür dass die Spannungspegel prinzipiell in Ordnung sind, ist auch folgendes: Das einzige Zeichen das bei der Übertragung korrekt funktioniert, ist das "U". Dieses hat ASCII Code 85 (0101 0101). Dort ist die Invertierung ja eig. egal, da letztendlich wieder das gleiche "Muster" dabei herauskommt.
Das einzige Zeichen das bei der Übertragung korrekt
funktioniert, ist das "U". Dieses hat ASCII Code 85 (0101 0101). Dort
ist die Invertierung ja eig. egal, da letztendlich wieder das gleiche
"Muster" dabei herauskommt.
Wenn man 0101 0101 invertiert, dann kommt 1010 1010 heraus. Der Empfänger darf doch nicht einfach alles um 1 Bit verschoben interpretieren.
Eine Bitverschiebung kann u. U. vorgetäuscht werden. Da spielen Startbit, Stoppbit, Parity-Bit und der Unterschied zwischen 7- und 8-Bit-Zeichen mit hinein - das muss alles auf beiden Seiten identisch programmiert werden.
Nebenbei: Sendest du beim Testen immer nur genau 1 Zeichen und wartest dann lange genug? Ohne Handshake bekommst du sonst nur Käse.
Ich verwende sowohl am µC UART als auch in TeraTerm 8 Daten Bits, 1 Stop Bit und kein Parity Bit.
Wenn man 0101 0101 invertiert, dann kommt 1010 1010 heraus. Der
Empfänger darf doch nicht einfach alles um 1 Bit verschoben
interpretieren.
Das sehe ich auch so.
0101 0101 im Uart Pegel entspricht ja 1010 1010 im RS232 Pegel.
Da bei mir allerdings alles um einen Takt verschoben ist (siehe Bild im Anhang) passt es wieder ganz genau. Daher wird das U auch korrekt übertragen.
Ja, ich sende immer genau 1 Zeichen und warte dann 1 Sekunde:
Nein, eine logische 1 ist immer eine logische 1. Diese logischen Zustände 0 und 1 können allerdings je nach Interface durch unterschiedliche Spannungspegel oder Signale dargestellt werden.
Bei einem einfachen Modem, das RS232 überträgt, wird z.B. eine logische 1 einfach mit einer anderen Frequenz abgebildet als eine logische 0:
0101 0101 im Uart Pegel entspricht ja 1010 1010 im RS232 Pegel.
Nein, beide Bitfolgen sind immmer die selben. Nur ist eben beim TTL/CMOS Pegel eine 0 = 0V und eine 1 = 5V. Aber aber beim RS232-Pegel ist eine 0 >= +3V und eine 1 <=-3V:
Meine Frage ist nun, wie ich das Problem lösen kann.
Erst mal messen, welche Spannungspegel du denn da im Ruhezustand (= logische 1) hast. Und dann entschieden, ob da ein entsprechender Schnittstellenbaustein nötig ist, um die Pegel korrekt anzupassen.
Der µC erwartet im Ruhezustand einen 5V Pegel. Und er gibt im Ruheustand einen 5V-Pegel aus.
Wo wir es schon vom Messen haben: hast du ein Oszi? So ein Gerät ist zur Inbetriebnahme serieller Schnittstellen absolut notwendig, wenn man nicht bei jedem kleinen Schluckauf wieder herumraten möchte, was denn jetzt passiert.
hast du ein Oszi? So ein Gerät ist zur
Inbetriebnahme serieller Schnittstellen absolut notwendig
Falls nicht, und du scheust die Kosten, dann google mal nach DSO-150. Das ist nur ein Spielzeug, aber für deinen Fall gut genug und auch in vielen anderen Fällern sehr viel besser, als keins zu haben.
In dem Zusammenhang gibt es für ca 10 Euro einen "8ch Logic Analyzer", den würde ich gleich dazu empfehlen.
@Steve van de Grens, vielen Dank für den Hinweis. Das Gerät werde ich mir ebenfalls mal bestellen. Für solche einfache Fälle wäre es wohl definitiv hilfreich.
Das Ding reicht, um z.B. SPI-Kommunikation zu analysieren (ein bischen darueber nachdenken dass das Ding nur ca. 10EUR [= zwei Hefeweizen im der Gaststaette!] kostet, Dir aber das Leben deutlich vereinfacht).
Was Du brauchst sind Messclips, weil Du ja irgendwie an die IC-Beinchen ankommen musst (z.B. https://www.az-delivery.de/products/testhaken-clips-kit). Die sind zwar Tant, aber gute Clips sind leider im dreistelligen Bereich (und das waere es mir es nicht wert).
Neee, das ist Tand! Merke: Nürnberger Tand geht in alle Land, sagte man früher. Wobei Tand eine andere Bedeutung als heute hatte. Heute kommt viel Tand aus China.
Neee, das ist Tand! Merke: Nürnberger Tand geht in alle Land, sagte man
früher. Wobei Tand eine andere Bedeutung als heute hatte. Heute kommt
viel Tand aus China.
Da hast Du recht, da hast Du so recht. Die Haken sind Tand.
Ich habe dieses Produkt und komme damit zurecht. Als Software verwende
ich dazu Sigrok.
Ja, sigrok ist sehr zu empfehlen, vor allem durch die "stapelbare" Protokoll-Analyse gibt es schnelle Ergebnisse (low level: Logikpegel, nächste Stufe Baudraten-Erkennung, dann UART-Zeichen und die oberste Stufe parst das ASCII-Protokoll, etc.).
Die angegebene 24 MHz Abtastrate läuft bei mir nicht stabil. Aber 12 MHz
gehen - immerhin. Für meine seriellen Schnittstellen reicht das.
Theoretisch (tm) kann der EzUSB Chip 48 MB/s, überfährt aber damit nahezu jeden Hi-Speed-USB-Kanal, da die Daten ohne (großen) Puffer direkt gestreamt werden, dafür aber unendlich lang, nur begrenzt durch den empfangenden PC.
Das Ding enthält nichts anderes als eine kleine Platine mit dem verbreiteten CY7C68013A drin, solche Boards gibt es z.B. bei E... ab 8 Euro. Die können sogar 16 Bit, nicht nur 8. Dazu brauchst Du noch die Clips für feine Beinchen. Ich nutze das seit vielen Jahren (mein Board hat noch einen Mini-USB Anschluss, nicht: Micro). Dazu Sigrok als Software mit fx2lafw-Treiber für das Board, geht gut bis 12 MHz Abtastrate.
Ich habe nun rausgefunden woran das liegt. Beim TTL Pegel ist eine 1
auch eine logische 1. Beim RS232 Pegel hingegen ist die Spannung
invertiert, dort ist eine 1 eine logische 0. Zudem ist bei mir die
Kommunikation um einen Takt verschoben.
Wie es schon viele gesagt haben ist RS232 natürlich invertiert, eine logische 1 entspricht einem physikalisch negativen Wert und eine logische 0 entspricht einen physikalisch positiven Wert. Da du das UART-Signal aber schon nicht invertierst ist klar, warum es nicht klappt und das erklärt auch, warum das Signal um ein Bit verschoben ist: Die serielle Schnittstelle am PC wartet nämlich auf das Startbit und auch das wird natürlich invertiert erwartet ;)
However, das "Problem" hast du ja anscheinend gelöst. Wenn du den Mikrocontroller mit einem PC quatschen lassen willst rate ich inzwischen vom Max232 und Co ab. Ein PC hat heute idR keine RS232-Schnittstelle mehr, üblich ist USB und da gibt es auch viele Lösungen, z.B. von Microchip im bastlerfreundlichen DIP-Package gibts den MCP2221A, ein UART2USB-Wandler. Und FTDI, der Klassiker schlechthin, hat da auch einiges im Angebot was UART direkt auf USB bring (ich glaub nur nix im formschicken DIP-Package aber da bin ich mir grade nicht sicher ;))
Vielen Dank für all die Antworten! Das hat mir sehr weitergeholfen. Die von euch angemerkten Sachen werde ich mir definitiv besorgen.
und das erklärt auch, warum das Signal um ein Bit verschoben ist: Die
serielle Schnittstelle am PC wartet nämlich auf das Startbit und auch
das wird natürlich invertiert erwartet ;)
Stimmt, das erklärt auch die Verschiebung um einen Takt, da das StartBit natürlich ebenfalls invertiert ist.
Beim RS232 Pegel hingegen ist die Spannung
invertiert, dort ist eine 1 eine logische 0.
Nein, eine logische 1 bleibt eine logische 1. Bei RS232 ist die Zuordnung der Logikpegeln zu den Spannungen anders als am UART, abgesehen davon, dass bei RS232 nach Standard der untere Pegel negativ sein muss.
Zudem ist bei mir die Kommunikation um einen Takt verschoben.
Nein, das ist nur eine Folge davon. Dein Empfänger synchronisiert wegen der falschen Polarität nicht auf das Start-Bit des Senders, sondern auf das nächste von der Polarität passende Bit, nachdem der Empfang des vorherigen Zeichens abgeschlossen ist.
Stimmt, das erklärt auch die Verschiebung um einen Takt, da das StartBit
natürlich ebenfalls invertiert ist.
In deinen Zeichnungen ist das Startbit nicht invertiert, wenn man es mit den Nutzbits vergleicht. Zwischengeschaltete Pegelwandler können aber nicht wissen, welches die Nutzbits sind. Hast du also das Gezeichnete nicht wirklich gemessen oder sonstwie ermittelt?
Zwischengeschaltete Pegelwandler können aber
nicht wissen, welches die Nutzbits sind.
Das müssen die auch nicht. Sie sollen Pegel wandeln und nicht abhören ;-)
Falls der Mega nur zum Pc senden soll geht das in dem er invertiert sendet (Software Uart) ohne irgendwelche zusätzlichen Anpassungen. In Richtung Mega kann ein Transistor dazwischen. Oder auch invertiert empfangen, dann reicht ein Widerstand.
Zwischengeschaltete Pegelwandler können aber
nicht wissen, welches die Nutzbits sind.
Das müssen die auch nicht. Sie sollen Pegel wandeln und nicht abhören
;-)
Du hast mein Argument nicht verstanden. Laut den Zeichnungen des OP wissen und berücksichtigen sie das nämlich. Und weil jeder -- sogar ich :-) -- weiß, das sie das nicht können, habe ich die Zeichnungen angezweifelt.
Falls der Mega nur zum Pc senden soll geht das in dem er invertiert
sendet (Software Uart) ohne irgendwelche zusätzlichen Anpassungen.
Na, was der PC mit einem Pegel macht, der niemals bis auf null runter geht, obwohl er deutlich bis ins Negative gehen müsste, das weiß man nicht so genau. Das mag manchmal funktionieren und manchmal nicht.
