Hallo, ich sende mit 9600 Bd zwischen zwei ATMega1284P MCU's Daten über an die UART-Schnittstelle angeschlossene RS485 Transceiver (MAX487). Beide Controller laufen mit 8 MHz internem Takt. Der Clock-Divider per Fuse ist aus. Ich habe den RS485 und UART Code sowie die beiden Main's angehängt, die ich auf die Schnelle zusammengeschrieben habe als Test-Code. Der Slave sendet 11 Bytes an den Master. Der Master empfängt an UART1 RX die Daten und gibt diese auf dem UART0 TX wieder aus, jedoch verfälscht bzw. nicht wie erwartet und in der Menge auch zu wenig. Zur Analyse der Daten habe ich zwei TTL/USB Konverter und einen LogicAnalyzer wie folgt aufgeschaltet: 1) TTL/USB(1): Liest die Eingangsdaten des Slave nach dem MAX487, also auf Mikrocontroller Seite UART1 RX (s. Anhang UART_to_USB_KORREKTUR.png, das rechte Fenster) aus. 2) TTL/USB(2): Liest die "Ausgangsdaten" welche vom Master per UART1 TX verfälscht, bzw. nicht wie erwartet ausgegeben werden (s. Anhang UART_to_USB_KORREKTUR.png, das linke Fenster) aus. 3) LogicAnalyzer: Liest ebenso wie (1) die Eingangsdaten ein, um noch ein paar mehr Informationen über das Timing etc. zu bekommen habe ich noch den LA angeschlossen. Mein Problem liegt also darin, dass die Daten vom Slave an den Master wie erwartet über RS485 transportiert werden, dort auch richtig am Master eingehen über UART1 RX, jedoch dann beim Weiterleiten direkt in der UART1 RX ISR an den UART0 TX (s. Main_Master.c) verfälscht ausgegeben werden bzw. nicht alle Daten (s. UART_to_USB_KORREKTUR.png) ausgegeben werden. Hat jemand einen Tipp was ich noch prüfen könnte um den Fehler auf die Schliche zu kommen? Mir fällt bald nichts mehr ein. Wenn noch Informationen benötigt werden einfach Bescheid sagen, dann liefere ich nach falls möglich. Vielen Dank und schönen Gruß Markus EDIT: Ich habe einen Fehler in der UART_to_USB.png ausgebessert und angehängt, daber bitte die Datei UART_to_USB_KORREKTUR.png nutzen, da ich nicht weiß, wie man im Nachhinein Anhänge löschen kann.
Angehängte Dateien:
-
LogicAnalyzer_Session.png
110 KB -
UART_to_USB.png
96 KB -
UART_to_USB_KORREKTUR.png
100 KB
:
Bearbeitet durch User
Markus E. schrieb: > ich sende mit 9600 Bd zwischen zwei ATMega1284P MCU's Daten über an die > UART-Schnittstelle angeschlossene RS485 Transceiver (MAX487). Beide > Controller laufen mit 8 MHz internem Takt. Welcher nicht sonderlich genau ist, ca. +/-5%. Das ist meist zuviel. https://www.mikrocontroller.net/articles/AVR_Checkliste#UART/USART
Von dem Microcontrollern habe ich keine Ahnung, aber für mich sieht das irgendwie auf ganz unterer Ebene (Baudrate zB) falsch aus. zB wird eine 9dez. = 00001001 zu einer 130dez = 10001000. Abgesehen vom Start-offset ist da auch eine null zuviel zwischen den einsen. Auch in den übrigen Daten korrelieren die Anzahl der einsen zwischen in- und output einigermaßen.
Falk B. schrieb: > Welcher nicht sonderlich genau ist, ca. +/-5%. Das ist meist zuviel. Danke für den Hinweis, ich habe dummerweise kein Quarz mehr herumfliegen, habe aber direkt welche bestellt und werde den Controllern jeweils eines spendieren für den externen Takt. Klaus schrieb: > aber für mich sieht das > irgendwie auf ganz unterer Ebene (Baudrate zB) falsch aus. > zB wird eine 9dez. = 00001001 zu einer 130dez = 10001000. Das ist mir auch aufgefallen, dass die Darstellung der Bits in Logic 2 umgekehrter Reihenfolge zu sein scheint, jedoch vom Serial Analyzer wie ich die Bytes erwarten würde interpretiert wird.
> Beide Controller laufen mit 8 MHz internem Takt. Das ist beim Master garantiert? Zusammen mit der Ungenauigkeitsfrage sollte das nachgemessen werden. Und eine Abfrage von FE1 und DOR1 wäre auch sinnvoll, notfalls Fehler-Signalisierung per LED.
S. Landolt schrieb: >> Beide Controller laufen mit 8 MHz internem Takt. > > Das ist beim Master garantiert? Nein scheinbar (im Rahmen der Toleranz) ganz und gar nicht. Denn wie es Falk mit seinem Beitrag schon andeutete ist die Toleranz des int. Takts zu kritisch für die serielle Übertragung in meinem Fall. Ich habe aus einer fertigen Schaltung ein Quarz ausgelötet und in die vorhandene Schaltung (zumindest am Master) eingebaut und die Datenübertragung funktioniert nun am UART1 TX genau wie ich sie erwarten würde. Insofern nochmal danke für den Hinweis mit der Toleranz, ich hätte nicht gedacht, dass dies mit internem Takt zu derartigen Schwierigkeiten am UART sorgen kann.
Haben Sie beim Ändern des Fuse-Low-Byte nochmal kontrolliert, dass das ursprünglich tatsächlich auf '8 MHz intern' stand?
Ja genau das hatte ich bei beiden Controllern geprüft, ebenso wie den Clock-Teiler.
Okay - würde mich jetzt aber doch interessieren, wie stark dieser 'Calibrated Internal RC Oscillator' in Ihrem Fall von den 8.0 MHz abweicht (falls das nicht zuviel Aufwand ist).
Markus E. schrieb: > Danke für den Hinweis, ich habe dummerweise kein Quarz mehr > herumfliegen, habe aber direkt welche bestellt und werde den Controllern > jeweils eines spendieren für den externen Takt. Du kannst zum Test ja auch die Einstellung #define F_CPU 8000000UL ändern und schauen, ob du einen funktionierenden Wert findest. Dann weist du zumindest, ob es am Takt liegt.
> ... F_CPU ... ändern und schauen ...
Da würde ich doch das Messen vorziehen, das geht schneller. Zumal
UBRR=51, d.h. es kommt bereits ein systematischer Fehler von 2 % herein.
S. Landolt schrieb: > UBRR=51, d.h. es kommt bereits ein systematischer Fehler von 2 % herein. Du meinst 0,2% ;-)
Wenn man UBRR bei 51 variiert ("ändern und schauen"), dann geht das nur
auf rund 2 % genau.
Das sollte reichen. Mit 1% würde es gehen wenn das U2Xn bit gestetzt würde. Dann wäre 103 für 9600Baud nötig. Das Osccal arbeitet auch ca im Prozent Bereich. Jedoch ist einer von beiden ein "Montagschip". Gewöhnlich ist der interne Generator genau genug. Vielleicht doch mal dem Takt messen?
:
Bearbeitet durch User
Die Abweichung des internen RC-Takts von 8 Mhz ist laut Datenblatt über Spannung und Temperatur nicht ausreichend für eine 9600 Bd-Übertragung. Da muss man Sender und Empfänger mit Hilfe von automatischen Routinen, oder mit Poti, Taster, etc. aufeinander abgleichen. Es geht auch ohne intelligenten menschlichen Eingriff, aber es muss vorgesehen sein!
Hier unterhalten die sich seid Jahren ohne Abgleich mit bis zu 30K Temperaturdifferenz. (bei 4,6-5,2V) Bei Probeläufen die abwechselnd mit 3,3 und 5V arbeiten stellte sich eine differenz im Takt heraus. Das störte die Komunikation nicht, machte jedoch eine falsche Stundenlänge ;-) PS Wenn Sender und Empänger sich aufeinander einstellen würde irgendwann der Bereich so weit daneben liegen das ein drittes Gerät nicht mehr mitreden könnte. Ein einmaliger Abgleich könnte jedoch sinnvol sein - falls mal ein "Montagschip" rein kommt.
Ich verstehe es einfach nicht: Herumgeeiere, Risiko-Kommunikation, Toleranzabschätzung, Takt- Kalibrierung und wer weiss was sonst noch für Zusatz-Probleme (ach so: ewiges Herumdiskutieren hier im Forum hab ich vergessen). Erspar ich mir alles mit der Verwendung eines Quarzes und zweier Lastkapzitäten. Kostet fast nichts verglichen mit dem Ärger und Aufwand den ich sonst hätte. Ich baue mir ja einen Mikrocontroller nicht deswegen weil ich ewig an der Takt- konfiguration herumbasteln will sondern weil ich mit dem Controller bestimmte Aufgaben erledigen will. Und wenn ich den Quarz und die Lastkapzitäten in einem Aufbau noch nicht drin haben sollte dann mach ich mir die kleine Mühe und bastel mir die noch als Flickwerk mit rein. Dann sind meine niedrigen Serial-Kommunikationsprobleme wie weg-geblasen.
Wenn man statt der asynchronen UART eine synchrone Kommunikation verwendet, ist der Takt und dessen Stabilität irrelevant, da immer nur eine Seite der Kommunikation den Takt vorgibt und im Rahmen der Kommunikation auch an die Gegenseite überträgt. AVRs kennen zwei Arten der synchronen Kommunkation - SPI und I2C.
Hi
>AVRs kennen zwei Arten der synchronen Kommunkation - SPI und I2C.
Zwei? Was ist mit dem Synchronen Master Mode der Usart?
MfG Spess
spess53 schrieb: > Was ist mit dem Synchronen Master Mode der Usart? Gibt es einen korrespondierenden synchronen Slave Mode?
>Gibt es einen korrespondierenden synchronen Slave Mode?
Dann lies mal (DB)
Internal Clock Generation – The Baud Rate Generator
UCSRnC – USART Control and Status Register n C->• Bits 7:6 – UMSELn1:0
USART Mode Select
MfG Spess
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.