Hey Leute, eigentlich dachte ich es wäre mir problemlos Möglich 2 ATMegas miteinander kommunizieren zu lassen, scheinba habe ich mich aber überschätzt. Also mein UART ist eingestellt auf 9600 Baud, asynchronous, 8Datenbits, no Parity, 1Stopbit. So nun Daten empangen läuft quasi automatisch. Von aussern kommt ein Startbit, der Hardware-UART springt an und meldet am ende mittels eines Flags den erfolgreichen Empfang. Senden läuft ähnlich: ich schriebe ins leere Puffer-register und warte bis die Daten raus sind. Nun die Frage: Wenn gerade Daten empfangen werden wärend ich Daten in den TX-Puffer schreibe, wann werden diese gesendet? Ich verstehe das ja richtig, dass es bei der asynchronen Verbindung zweier µCs keinen Master und kein Slave in dem Sinne mehr gibt oder? Hintergrund: Ich möchte, dass ein Controller den anderen Befragt und Befehle gibt (also doch irgendwie ein Master). Will µC1 z.B. dass µC2 "LED 2 an"macht, so schickt er z.B. ein "a" an den Anderen. Will µC1 aber den Wert von "(uint16_t)variable" wissen, sendet er z.B. ein "b" an µC2, woraufhin µC2 den Wert von Variable sendet, also also erst das HighByte und anschließend das LowByte von "variable" in den TX-Puffer schriebt. Oder ist das ein völlig falscher Ansatz wie man 2 µCs über UART kommunizieren lässt. Vielen Dank lg Martin
Martin schrieb: > Nun die Frage: > Wenn gerade Daten empfangen werden wärend ich Daten in den TX-Puffer > schreibe, wann werden diese gesendet? Ich nehme an, die Frage soll lauten: "Wenn ich gerade Daten in den TX-Puffer schreibe während Daten empfangen werden, wann werden diese gesendet?" Falls das die Frage ist, wäre meine Antwort: Sofort. Das Senden und das Empfangen läuft praktisch unabhängig voneinander, also auch gleichzeitig.
Sender und Empfänger sind also abgesehen von den Einstellungen völlig unabhängig. Danke
Martin schrieb: > Oder ist das ein völlig falscher Ansatz wie man 2 µCs über UART > kommunizieren lässt. Der meistens völlig falsche Ansatz besteht darin, dass man 2 µC einsetzt, wo es einer alleine auch tut. Aber abgesehen davon, ist es meistens eine extrem gute Idee, wenn man keinen 2 Frontenkrieg eröffnet, sondern einen der beiden µC zunächst durch etwas bereits als funktionierend bekanntes ersetzt. zb durch einen PC mit einem Terminalprogramm. Dann kann man sich am PC ansehen, ob derjenige der sendet, das richtig tut. Und man kann auch den PC mit dem anderen verbinden und dem mal händisch seine Kommandos schicken. Wenn dann beide µC unabhängig voneinander mittels PC ausgetestet sind und deren Programme leidlich laufen, dann kann man die beiden direkt miteinander verbinden und die Chancen stehen gut, dass es dann auf Anhieb leidlich funktionieren wird.
> Der meistens völlig falsche Ansatz besteht darin, dass man 2 µC > einsetzt, wo es einer alleine auch tut. Schon klar, aber hier soll ein Display mit einigen knöpfen per UART an verschiedene Geräte angeschlossen werden. (ich hab nur das eine Display) Dieser Controller wird dann als eine Art HumanInterface genutzt. gleichzeitg lerne ich die Kommunikation kennen was für mein großprojekt Hausbus irgendwann mal von Vorteil ist. > Aber abgesehen davon, ist es meistens eine extrem gute Idee, wenn man > keinen 2 Frontenkrieg eröffnet, sondern einen der beiden µC zunächst > durch etwas bereits als funktionierend bekanntes ersetzt. zb durch einen > PC mit einem Terminalprogramm. > > Dann kann man sich am PC ansehen, ob derjenige der sendet, das richtig > tut. > Und man kann auch den PC mit dem anderen verbinden und dem mal händisch > seine Kommandos schicken. Mit dem STK500 und einem Terminal-Programm denke ich ist mir da ganz gut geholfen oder? Werde ich vermutlich auch so machen müssen. Danke
Was häufig falsch gemacht wird, wenn zwei Controller via RS-232C verbunden werden sollen, ist, dass RxD mit RxD und TxD mit TxD verbunden wird. Die Leitungen müssen gekreuzt werden (RxD des einen an TxD des anderen).
Bitte 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.