Ich möchte 2 uC über eine serielle Schnittstelle miteinander reden lassen. Das Problem ist, das dies über einen Stecker mit nur 2 Leitungen (Rx,Tx) geschieht, der zu einer beliebigen Zeit x erst verbunden wird, wenn beide uC schon "leben" und Daten senden. Je nachdem wann der Stecker zusammengesteckt wird kommt natürlich auf beiden Seiten nur Müll an (wenn gerade mitten in einem Transfer verbunden wird). Wie bekomme ich das am besten synchronisiert?
Denk Dir ein Protokoll aus, das erkennt, ob eine Gegenstelle verbunden ist und auch senden/empfangen kann. Prüfe nach dem Transfer, ob die Daten angekommen sind/ob die Verbindung noch steht, oder sonst was. Wie bei der normalen sprachlichen Kommunikation zwischen Menschen, einfach ein ähnliches Protokoll mit Rückfragen, Wiederholungen etc. erfinden. Es gibt auch ein simples Protokoll: Jedes empfangene Byte muß zurückgesendet werden (Echo-Protokoll), so weiß jeder uC, ob er verstanden wird.
Schon klar, aber wie kriege ich die erstmal Synchron, so dass die Verbindung steht? Bzw. was mache ich, wenn ich merke, dass die Daten Müll sind? Eine Stelle abschalten und auf Verdacht wieder neu einschalten? Gefällt mir nicht so toll.
Menschen telefoinieren z.b. und sagen "hallo" und dann fangen sie erst an zu quatschen. Wenns Dir nicht gefällt, dann darfst Du keinen Stecker abziehen.
> Das Problem ist, das dies über einen Stecker mit nur 2 Leitungen > (Rx,Tx) geschieht, der zu einer beliebigen Zeit x erst verbunden wird, > wenn beide uC schon "leben" und Daten senden. Wenn das wirklich nur Rx/Tx ohne GND ist, wird das wahrscheinlich NIE (oder nie zuverlässig) funktionieren, wenn es nicht grad RS485 ist. > Je nachdem wann der Stecker zusammengesteckt wird kommt natürlich auf > beiden Seiten nur Müll an (wenn gerade mitten in einem Transfer verbunden > wird). Wie bekomme ich das am besten synchronisiert? Sei doch froh, wenn schon mal nur Müll ankommt, im laufenden Betrieb nicht-hotplugging fähige Schnittstellen miteinander zu verbinden gibt meistens schon vor der Kommunikation Probleme wie abgerauchte IOs etc. Zum eigentlichen Problem, kleide jeden Transfer in ein definiertes Start- und Endezeichen ein. Kein Start-,aber Endezeichen empfangen heisst dann, der Transfer war murks. Nur Endezeichen geht auch, d.h. dann eben dass der erste Transfer immer verworfen wird, selbst wenn er korrekt empfangen wurde... Ralf
Nein, ihr versteht das Problem nicht. Es geht darum, dass innnerhalb eines Bytes der Transfer nicht klappt. Dann bekommt man nie mehr richtige Zeichen. Auf Zeichen-Ebene kann man da nichts auswerten. GND ist auch noch dabei. Die Stecker-Lösung ist leider so vorgegeben, daran kann ich nichts ändern.
Ohne GND ? In die Tonne. Wir nie gehen. Falls es denn doch einen GND geben sollte : Eine Zustandsmaschine beim Empfaenger liest das UART und prueft alles. Ein Meldung sieht wie folgt aus : Header-Daten-Checksum. Falls das nicht richtig ankommt, wird's verworfen. Falls es richtig ankommt sollte der Sender etwas zurueck erhalten, eine Antwort, oder auch nur eine Quittierung. Der Sender sollte sich moeglicherweise darauf einstellen ob ein anderes Device zuhoert, moeglicherweise aber auch nicht.
Bronco wrote: > Nein, ihr versteht das Problem nicht. > > Es geht darum, dass innnerhalb eines Bytes der Transfer nicht klappt. > Dann bekommt man nie mehr richtige Zeichen. Auf Zeichen-Ebene kann man > da nichts auswerten. Der Sender muss halt mal eine Pause machen, die länger als ein ganzes Datenbyte inkl. Start-, ev. Parity- und Stopbit ist. Dann kann sich der UART auf das erste Startbit nach der Pause synchronisieren. Ohne Pause, mit kontinuierlichem Datenstrom, ist es u.U. wirklich unmöglich.
Ok, nochmal zur Erklärung. Angenommen eine Seite schickt laufend ein Byte 0xAB. Nun wird der Stecker so unglücklich verbunden, dass statt 0xAB der Empfänger immer nur 0xBA sieht, weil der Stecker z.B. in der Mitte eines Transfers eines Bytes eingesteckt wurde. Dann liest man aus dem UART immer nur falsche Zeichen aus. Wie gesagt, GND ist auch dabei, nur keine freie Steuerleitung mehr für andere Zwecke, das meinte ich mit nur Rx, Tx.
> dass innnerhalb eines Bytes der Transfer nicht klappt. Da hilft nur, dass beim Senden mal eine etwas längere Pause (mindestens 1 Byte) zwischen zwei Zeichen eingelegt wird. Dann kann das nächste Startbit korrekt erkannt werden. Sonst kann das lange dauern und du erhältst nur Framing-Fehler... EDIT: > dass statt 0xAB der Empfänger immer nur 0xBA sieht > Dann liest man aus dem UART immer nur falsche Zeichen aus. Und erhält den angesprochenen Framing-Fehler.
> Nein, ihr versteht das Problem nicht. Doch, aber du möglicherweise nicht.... > Es geht darum, dass innnerhalb eines Bytes der Transfer nicht klappt. Dann bekommt man nie mehr richtige Zeichen. Auf Zeichen-Ebene kann man da nichts auswerten. Sobald eine Pause >1Zeichen im Transfer auftritt, synchronisiert der Empfänger beim nächsten Startbit. Macht der Sender nie Pause, dann hast du in der Tat ein Problem- passiert mir bei meiner Frau auch manchmal.....
Jo, das Problem ist dann wirklich, dass auf beiden Seiten nie eine Pause eingelegt wird, weil alles per DMA-Transfer abläuft. Mal gucken was ich dagegen machen kann.
Setz dein Protokoll auf, dass die Gegenstelle ab und an mal bestätigen muss. Wenn ein Sender länger als x Zeiteinheiten keine Bestätigung von der Gegenstelle bekommen hat, muss er davon ausgehen, dass nichts synchronisiert ist. Er geht dann in einen Modus, in dem er ständig ein 'Hallo ist da wer' raussendet und dann etwas wartet. Sobald er eine gültige Bestätigung hat, wechselt er in den Modus 'Daten rausblasen und ab und an auf Bestätigung warten'. Ist die Bestätigung eine zeitlang ausgeblieben, gehts wieder zurück zu ' Hallo ist da wer'. Sieh dir das reale Leben an. Wir alle kennen genug Techniken, wie man sowas im realen Leben machen kann.
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.