Für ein Schulprojekt möchte ich zwei 8252 verbinden und zwischen ihnen Daten seriell übertragen. Als Fehlerkorrektur soll einfach ein zusätzliches Parity-Bit übertragen werden. Jetzt die Frage: Falls der Empfänger entdeckt, dass die Information nicht stimmt, was soll als nächstes passieren? Kennt vllt. jemand zufällig gute Literatur zur seriellen Datenübertragung?
Der Empfaenger kann jede Meldung mit einem ACK, resp einem NACK quittieren und der Sender gegebenenfall bei NACK nochmals senden.
Hallo Maxim Was machst du, wenn du jemanden nicht verstanden hast? Du bittest ihn das gesagte zu wiederhohlen. Gruss Olli
Ja, aber wie? Wenn der Empfänger einen Fehler registriert, soll er dann wieder durch die serielle Schnittstelle eine Meldung an den Sender schicken, sodass dieser das letzte Byte nochmals schickt? Wie soll der Sender erkennen, dass es sich um ein Befehl handelt und nicht um eine Information, die zufällig dem Befehl entspricht? Oder sollte man dafür eine eigene Leitung führen?
Maxim wrote: > Ja, aber wie? > > Wenn der Empfänger einen Fehler registriert, soll er dann wieder durch > die serielle Schnittstelle eine Meldung an den Sender schicken, sodass > dieser das letzte Byte nochmals schickt? Üblicherweise macht man das nicht auf Byte Ebene, sondern in größeren Blöcken. Hängt davon ab, was du tatsächlich übertragen willst. > dass es sich um ein Befehl handelt und nicht um eine Information, die > zufällig dem Befehl entspricht? Überträgst du denn Befehle? Du könntest zb. an jeden Befehl eine Checksumme anhängen und der Empfänger muss den fehlerfreien erhalt eines Befehls quittieren. Entdeckt der Empfänger einen Fehler in der Übermittlung, dann schickt er eben eine negative Quittierung: ACK = Acknowlege = Ich habe die Daten fehlerfrei erhalten NACK = Not Acknowledge = Ich habe einen Fehler in der Übertragung gefunden. Wie's dann weitergeht, musst du mit dir selbst absprechen. Zb. Könntest du vereinbaren, dass ein fehlerhafter Empfang beim Empfänger immer dazu führt dass der Befehl nicht ausgeführt wird. Das heist aber auch für den Sender: Erhält er ein NACK, so muss er davon ausgehen, dass der Befehl nicht ausgeführt wurde und er sendet den Befehl noch einmal. Selbes Spiel wenn die Bestätigung nicht innerhalb eines Zeitlimits erfolgt. > > Oder sollte man dafür eine eigene Leitung führen? Wie stellst du sicher, dass diese eigene Leitung nicht ebenfalls gestört ist?
Also kann ich eine Datenpaketgröße von z.B. 12 Bit definieren. Die ersten 3 Bit sind immer zum Verständigen zwischen Sender/Empfänger. Die restlichen 9 Bit enthalten die eigentliche Information + Paritätsbit?
Maxim wrote:
> Also kann ich eine Datenpaketgröße von z.B. 12 Bit definieren.
Wenn du das willst.
Aber bedenke: Eine übliche UART Übertragung baut auf einer
Byte Übertragung auf. Also würde ich zumindest ein vielfaches
von 8 Bit nehmen.
Das vereinfacht dann auch den Sende und Empfangscode.
Sobald es um Befehle mit Parametern geht, sollte man ein Protokoll ueberdenken. Hier ist eins als Beispiel :http://www.ibrtses.com/embedded/shortmsgprotocol.html
Wenn du das Paritaetsbit einbeziehst,dann hast du doch schon eine brauchbare Sicherheit. Die MCs arbeiten sauber...man kann alles uebertreiben.
>Wenn du das Paritaetsbit einbeziehst,dann hast du doch schon eine >brauchbare Sicherheit. Die MCs arbeiten sauber...man kann alles >uebertreiben. Hast nicht ganz verstanden, worum es geht ... Zum Thema: Das mit der Kommunikation zwischen den uCs ist mir nun klar. Jetzt stellt sich mir noch eine Frage: Der Takt wird vom Master generiert. Soll er ständig anliegen oder nur wenn Daten gesendet werden müssen? Bei der SPI trifft ja der letzte Fall zu. Warum? Gibt es Nachteile bei einem dauernd anliegenden Takt?
@ Maxim (Gast) >Der Takt wird vom Master generiert. Welcher Takt? >Soll er ständig anliegen oder nur >wenn Daten gesendet werden müssen? Bei der SPI trifft ja der letzte Fall >zu. Warum? Gibt es Nachteile bei einem dauernd anliegenden Takt? Bei asynchroner Kommunikation per RS232 gibt es keinen Takt, der übertragen wird. MFG Falk
Allerdings gibt es bei dem ACK / NACK spielchen noch ein Problem. Wenn der Empfaenger einen gueltigen Block mit ACK quitiert und bei der uebertragung zum Sender das ACK getstoert wird oder ausbleibt dann wuerde der Sender denn Block noch einmal senden wobei dann im Empfaenger 2 gleiche Bloecke angekommen waeren. Besser ist es wenn man dem Datenblock eine laufende Nummer mitgibt. Wenn dann der Datenblock auf grund einer Stoerung nochmal uebertragen wuerde kann der Empfaenger der ja den ersten Block schon als korrekt Quitiert hat den zweiten Datenblock mit der selben Block nummer verwerfen. So ist sichergestellt das bei einem gestoerten ACK nie 2 mal der gleiche Datenblock im Empfaenger ankommt. Gruss Helmi
Es ist schwer, Dir zu etwas zu raten, wenn nur kleine Teile des Umfeldes bekannt sind. Zuerst muss einmal klar sein, ob die beiden Prozessoren nahe bei einander liegen oder nicht. Muss ein langes Kabel dazwischen, oder liegen sie recht nahe beieinander, aber in einem gestörten Umfeld ( Motoren o.Ä.). Sind beide auf einer Platine, so kann man SPI mit hoher Datenrate einsetzen. Auch eine ACK-Leitung, die vom Empfänger jedes mal gezogen wird, wenn ein Kommando korrekt empfangen wurde, ist das schneller, als die Schnittstelle mit einem Byte zu blockieren. Ist das Umfeld gestört, sollte SPI nur mit geringer Baudrate genutzt werden, auch bei relativ kurzen Wegen. Geht es aber um eine möglicherweise recht lange Kabelverbindung, dann sollte man auf RS232, RS422, RS485 oder RS488 zurückgreifen. Alles serielle Protokolle die teils über zwei, teils über vier Adern bei hohem Störabstand serielle Kommunikation ermöglichen. Beim SPI sender der Master den Takt auf einer extra Leitung mit. Bei den zuletzt genannten seriellen Protokollen, wird der Takt aus den übertragenen Daten vom Empfänger zurück gewonnen. Die Daten werden dazu in Start- und Stop-Bits verpackt, die der Empfänger erkennen und auf die er sich einstellen kann. Also rück mal raus, was genau Ihr da in der Schule verbinden wollt, dann könne wir hier Dir auch zu einem Bus und einer Kommunikation raten, die einfach aber auch wirkungsvoll sind. Gruß, Ulrich
Dann wird er wohl synchrone Datenübertragung meinen, oder?
Es sind zwei Experimentierplatinen mit jeweils einem 8252. Die werden durch Litzen verbunden. Was die Transferrate angeht, sind die Anforderungen ziemlich gering. Es soll halt z.B. ein Byte empfangen, multipliziert und wieder zurück zum Master gesendet werden. Der zeigt das Byte auf 8 LEDs an, sodass man sehen kann, dass die Übertragung funktioniert. Im Grunde braucht man hier also weder das Paritätsbit noch sonstige Techniken, die man bei seriellen Schnittstellen nutzt. Nun soll das Projekt aber einen gewissen Lerneffekt haben. Deshalb würde ich schon gerne eine Fehlererkennung und ein simples Protokoll einbeziehen. Um die Sache trotzdem nicht zu kompliziert zu machen, habe ich mich für die synchrone Übertragung entschieden. Der Vorteil eines permanenten Taktsignals wäre ja, dass der Slave jederzeit Daten an den Master übertragen kann, während bei SPI immer auf den Master gewartet werden muss. Ich vermute aber, dass es bei SPI wegen mehreren möglichen Slaves so geregelt ist. ps: Es kommt nur eine Punkt-zu-Punkt-Verbindung in Frage, mehr brauchen wir nicht.
@ Maxim (Gast) >seriellen Schnittstellen nutzt. Nun soll das Projekt aber einen gewissen >Lerneffekt haben. Deshalb würde ich schon gerne eine Fehlererkennung und >ein simples Protokoll einbeziehen. Um die Sache trotzdem nicht zu >ps: Es kommt nur eine Punkt-zu-Punkt-Verbindung in Frage, mehr brauchen >wir nicht. Dann nimm RS232, nicht SPI. MFg Falk
Wenn's um den Lerneffekt geht, so wuerde ich beide Methode machen, synchron SPI und Asynchron. Ist ja nur ein paar Kabel anloeten und ein paar Zeilen Code.
Hi! Da stimme ich meinem Vorredner zu. Die Lerneinheit 'Serielle Datenkommunikation' kann mit SPI und RS232 zwei völlig unterschiedliche serielle Bussysteme abdecken und zudem den Unterschied zwischen synchroner und asynchroner Datenübertragung aufzeigen. SPI an sich lässt erst einmal nur einen einzigen Kommunikationspartner zu, mit /SS Signal dürfen es sogar zwei Master sein. Aber erst mit zusätzlichen ChipSelect Signalen können mehr als nur zwei miteinander reden. RS232 läßt nur zwei Kommunikationspartner zu. Sollen mehrere in einem Bus zusammen gefasst werden so muss man auf andere physische Protokolle ausweichen. ( z.B. RS485) Was die Komplexität beider Schnittstellen angeht, so findet sich in der Software kein Unterschied: RS232: Baudrate, Parität, Stop-Bits Einstellen. Los gehts! SPI: Baudrate, Flanke, Master/Slave Einstellen. Los gehts! Elektrisch ist es eine Frage des Aufbaus. Zwischen zwei Mikrocontrollern und auf kurze Distanz, kann man die RS232 auch ohne Treiber-Baustein direkt anschließen. Für mich ist aber dann der Witz weg, wenn man nicht auf der einen Seite des Klassenraumes die Zahlen eingibt und über 10m Strippe das Ergebnis auf der letzten Bank erscheint. Mit SPI müsste man aber ein anderes Beispiel nehmen, dass Geschwindigkeit erfordert und auf kurze Distanz sinn macht. Das würde die unterschiedlichen Vorteile der beiden Systeme hervorheben: RS232 langsam aber weitreichend (RS485 störsicherer und noch viel weitreichender) und SPI, kurz aber schnell. Lediglich lässt sich SPI leichter erklären, weil dort auf eine Änderung des Taktes die Bits durch geschoben werden. Bei der asynchronen Schnittstelle muss man dann auch das Clock-Recovery erklären. Gruß, Ulrich
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.