Hi, offensichtlich ist die Kommunikation zwischen zwei AVR per Hardware-UART einfach. Aber ich bin einfach nicht in der Lage, eine direkte Verbindung zwischen zwei AVRs herzustellen. Aber der Reihe nach: Per RS232 kann ich vom Computer auf einen ATtiny2313 Daten schicken. Das klappt einwandfrei. (8N1 - also 8 Datenbits, No Parity, 1 Stopbit) Nun möchte ich den Computer durch einen Atmel ersetzen. Sagen wir, einen ATmega8. Nun habe ich das gleiche Datenpaket mit BASCOM und dem Befehl "Printbin" ausgegeben und die TxD des ATmega8 direkt mit dem RxD Port des anderen Atmels verbunden. Eigentlich sollten die Pegel doch kompatibel sein? Wo ist der Denkfehler? Baudrate und andere Fehlerquellen habe ich überprüft und auch laut Oszilloskop kommen die korrekten Daten raus. Welche Stolpersteine muss ich bei direkter AVR->AVR Kommunikation beachten? (Einen MAX232 möchte ich nicht unbedingt einsetzen müssen) Ein Link zu einer Lösung würde mir schon reichen g (oder der Hinweis auf einen Post hier im Forum :) ) besten dank und schönen Abend :) Christian
Gast
#304892
normalerweise kein Problem. Entweder Softwareproblem, oder wie schon so oft, Baudratenproblem. Internen RC-Osc benutzt?
An die gemeinsame Masse gedacht?
Gast
#304894
@crazy horse: softwareproblem ist möglich. habe aber alles anhand der BASCOM Beispiele überprüft. Ein externer Quartz mit 4MHz wird genutzt. Vielleicht müsste ich einen 8MHz nutzen, da ich ne Geschwindigkeit von 38400 Baud nutzen? @Marc: Ja, gemeinsame Masse ist vorhanden. werde mal den Quartz austauschen :) ciao, Christian
Gast
#304895
Entfernung?
Gast
#304896
Die Leitung war ca. 20cm lang, das darf doch nix ausmachen!? Ist bislang nur ein Testaufbau. Sendet BASCOM denn beim folgenden PRINTBIN-Befehl das Stoppbit am Ende mit? PRINTBIN DATENPAKET(1); 6 Ich möchte ein Array aus 6 Bytes versenden und am Ende mit einem Stoppbit abgeschlossen haben. Das ist doch der richtige Befehl dafür, oder? Mein "Gegen-AVR" Überprüft nämlich, ob Stopbit und Byte-Anzahl korrekt sind. Chris
Gast
#304897
Wenn beide die selbe Taktfrequenz haben, sollten eigendlich keine Baudratenprobleme auftreten, da beide die selbe Abweichung in der Bitposition haben.
Gast
#304898
eigendlich = eigentlich ;-)
Gast
#304899
Nö, leider hat der Empfänger-AVR nen 8MHz Quarz. Wie gesagt, ich werde nen 8MHz Quarz auch in den Sender-AVR bauen und dann nochmal versuchen. Ich hatte nicht erwartet, dass hier so genau auf den Takt geachtet werden muss. Aber ich habe eben ausgerechnet, dass 38400 Baud bei 4MHz einen Taktteiler von 5,5 ergeben. Und 5,5 ist nicht wirklich eine Integerzahl, sodass ich einen enormen Fehler beim Senden habe. Mit 8MHz müsste es wohl laufen. Ich melde mich heute Abend, Christian :)
Das ist mir jetzt peinlich. Es scheint tatsächlich am Quarz gelegen zu haben. So ein Mist. Ich habe einige Stunden nach Fehlern gesucht, aber ich bin nicht auf die Idee gekommen, dass der 4MHz Quartz probleme machen könnte. Mit dem 8MHz empfängt der Zielatmel alle Befehle fröhlich und funzt :) Danke Leute, für den Gedankenanstoß! :)
Gast
#304901
Möglicherweise kannst Du die Kommunikation auch asynchron durchführen (z.B. mittels I2C), dann ist die Taktfrequenz nicht so kritisch. Rick
Gast
#304902
Ein Blick ins Datenblatt verrät mir, dass bei 4Mhz und 38,4k der Fehler -7% ist, bei U2X-Bit = 0(Schätze das ist der Fall). Bei gleicher Einstellung und 8 Mhz beträgt der Fehler jedoch nur 0,2%. Kein wunder warum es nicht funktioniert. Abhilfe: U2X-Bit bei beiden setzen, UBRR neu setzen, oder mit der Baud-Rate runtergehen, oder als dritte Möglichkeit einen krummen Quarz für Baudraten verwenden. MfG Barti
Gast
#304903
oder, ganz anders, sich um die genormten Baudraten überhaupt nicht kümmern. Spielt keinerlei Rolle, wenn du nur zwischen 2 AVRs Daten austauschen willst - da spricht nichts gegen z.B. 31450 Baud. Hauptsache, bei beiden gleich.
Gast
#304904
Wow, soviele Möglichkeiten...ist ja wie Weihnachten und Ostern zusammen.
Gast
#304905
Offtopic: Wofür steht "U2X"??
Bit für 2fache UART Geschwindigkeit. I2C ist ein Asynchroner Bus? Das ist mir neu. Er hat doch eine Daten und eine Clockleitung. Die Synchron zueinander sind, weil die Clock immer nach dem anlegen der Daten kommt. Folglich sollte das ein synchroner Bus sein.
Nun, die Steuerung über einen PC soll nicht übermäßig schwer werden, deshalb bleibe ich bei standard Baudraten und verwende ein normales RS232-Protokoll/-pegel. Ich habe es jetzt wie folgt gelöst: -> 8MHz Quarz -> bei Sender einen Levelshifter über billigen Bipolartransistor -> Empfänger ebenfalls einen Levelshifter -> Datenleitung von PC an µC und von µC an µC. Jetzt kann ich von beiden Geräten aus dem AVR Daten zukommen lassen. Mit I²C wäre das wohl nicht so einfach, ohne weitere Hardware den Rechner zuzuklemmen. Aber für weitere Projekte schaue ich mir mal das U2X-Bit an. Hatte davon bislang nix gewusst, klingt aber nützlich :)
ohoh, vorsicht. Was wenn beide Senden? naja wenn du eh PC-Konform bleiben willst, bringt dir das U2X au nix.
keine Sorge - hab die beiden Leitungen durch Dioden voneinander getrennt. Wenn beide Senden, gibts halt ein wirres Schalten im Empfangs-AVR, aber da die Datenpakete manuell verschickt werden, ist das jetzt so, als wenn man wie blöd mit zwei Leuten auf Wechselschalter drückt (ist in diesem Falle sogar ne Lichtschaltung g) Habe diesen Fall eben ausprobiert. Hat alles prima geklappt :) Bin jetzt sehr zufrieden mit der Schaltung. bis denn und gute Nacht, Christian