Hallo miteinander, ich habe das Problem, dass mein MCU (ATMega64a) nicht mit dem TCM515 Modul über UART kommunizieren will. Konkret besteht das Problem darin, dass der TCM515 das UART TX Signal von meinem MCU nicht erkennt. Andersherum ist das kein Problem. Da unterschiedliche Supply-Spannungen (5V & 3,3V) anliegen, habe ich zwischen den MCU TX Pin und dem TCM515 RX Pin einen Spannungsteiler (1KOhm zu 2KOhm) zwischengeschaltet. Ich habe ebenfalls schon 300 Ohm zu 1KOhm getestet, da der UART0 TX Pin nur ~4,5V ausgibt; 3,4V liegen noch in der Toleranz des TCM515. Ebenfalls kein Erfolg. TCM515-Eigenschaften: VCC -> 3,3V UART -> 57.600 BAUD, 1 Startbit, 1 Stopbit, 8 Databits, 0 Paritybits MCU C-Code: Siehe Anhang „code.c“ MCU Fuses: 11100100 (Low) 11011001 (High) 11 (Extended) Hört sich soweit bekannt an, gibt ja schon viele solcher Posts. Jetzt kommt allerdings das komische: Ich kann den UART0 des MCUs mit anderen Geräten verbinden (gleiche Konfiguration) und es besteht kein Problem. Ebenfalls kann ein Arduino mit derselben UART Konfiguration problemlos mit dem TCM515 kommunizieren. Heißt: MCU TX -> TMC515 RX – Nicht funktional TCM515 TX -> MCU RX – Funktional MCU TX -> Arduino RX – Funktional Arduino TX -> MCU RX– Funktional TCM515 TX -> Arduino RX – Funktional Arduino TX -> TCM515 RX – Funktional Auch eine Überprüfung mittels Logik-Analyzer ergab keine Auffälligkeiten (Rohdaten mit Start- & Stopbit sowie LSB-0-Bitnummerierung): 0 10101010 1 0 00000000 1 0 10000000 1 0 00000000 1 0 10100000 1 0 00001110 1 0 11000000 1 0 10010000 1 Bit-Länge ca. 18us Dargestellter CMD: CO_RD_VERSION (Kapitel 2.5.5 im ESP3-Standard) Leider habe ich gerade keinen Screenshot parat. Falls benötigt kann ich die Tage noch einen Screenshot der Analyseergebnisse posten. Ich hatte auch schon einiges an Kontakt mit dem EnOcean-Support, leider bisher ohne Erfolg (auch keine Ansatzpunkte). Habe auch den MCU und das TCM515 mehrfach ausgetauscht... Ich hoffe ihr könnt mir weiterhelfen! Danke im Voraus. Cheers, Morris
Welchen Quarz verwendet dein Mega64? Wie ist die Beschaltung?
Hallo Helmut, ich nutze den internen RC Oscillator @ 8 MHz. Denke mal, die Frage zur Beschaltung war auf den Quarz bezogen?
Morris H. schrieb: > Hallo Helmut, > > ich nutze den internen RC Oscillator @ 8 MHz. ist nicht besonders genau, zumindest wenn nicht kalibriert. Kann sein das die Abweichung bei den anderen Kombinationen gerade noch klein genug ist das es dort noch läuft. Miß mal mit dem LA die Zeiten, oder gib die 8MHz per Fuse mal an CLKOUT raus und messe nach. Und dann ist 8MHz zu 57.6k sowieso schon schlecht da du ohne U2X -3.5% und mit U2X +2.1% daneben liegst. Sascha
:
Bearbeitet durch User
Ja, bei so hohen UART-Raten immer einen externen Quarz benutzen. Am besten einen sog. Baudratenquarz. Ist zwar eine krumme Frequenz, aber die UART-Takte stimmen dafür.
Hallo Sascha, hallo Helmut, danke, gute Einwände; da habt ihr natürlich recht. Werde mir einen passenden Quarz bestellen und das ganze dann mit geringerer TX-Fehlerquote testen. Interessant finde ich noch, dass als ich ein TCM515 Modul „geopfert“ und mal direkt an den 5V MCU TX gehängt habe das Problem vollständig verschwunden war. Der TCM515 hat jedes Signal korrekt empfangen. Dachte dann zuerst an ein Problem mit dem Spannungsteiler, allerdings habe ich den Arduino ebenfalls über die gleichen Widerstände angeschlossen... Ist selbstverständlich keine Lösung, da es auf Dauer den Port zerschießt. Wisst ihr, was das Problem behoben haben könnte? Morris
Kleine Ergänzung: Ebenfalls habe ich mit dem über UART1 verbundenen Bluetooth-Modul kein Problem, obwohl dieses mit 115.200 BAUD kommuniziert. Ich gehe einmal davon aus, dass das Bluetoothmodul eine größere Fehlertoleranz besitzt, sodass selbst die (eigentlich problematische) Abweichung von -3,5% kein Problem darstellt. Morris
Sieht nach Grenzfall aus - Vorschlag: dieser systematische Fehler von 2.1 % lässt sich per OSCCAL wegjustieren.
PS: > per OSCCAL wegjustieren taugt nur zum Prüfen der Verhältnisse, beißt sich aber mit > ... 115.200 BAUD ... da falsche Richtung.
Hallo zusammen, ich habe das Problem durch den Quarz lösen können. 11,0592MHz haben mir gut gepasst, da es nah an den zuvor verwendeten 8MHz dran ist. Und nochmal danke für eure mithilfe, selbst bei einem eigentlich offensichtlichen Fehler :) @Landolt, dein Ansatz ist sicherlich für Operationen mit nur einer Baudrate bzw. in die gleiche Richtung abweichende Baudraten interessant. Werde ich im Kopf behalten, falls bei einer Applikation kein Quarz in Frage kommen sollte. BG Morris
Ich hatte zuerst an eine kleine Korrektur, 7.834 MHz, gedacht. Aber für 57600 & 115200 Bd wären natürlich 7.373 MHz sinnvoll, und dorthin lässt sich ein ATmega64 sicher auch ziehen. Aber natürlich ist ein Baudratenquarz mit Abstand die beste Lösung.
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.