www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Serielle Datenübertragung im Selbstbau


Autor: Maxim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: sechszweisechs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Empfaenger kann jede Meldung mit einem ACK, resp einem NACK 
quittieren und der Sender gegebenenfall bei NACK nochmals senden.

Autor: Olli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Maxim

Was machst du, wenn du jemanden nicht verstanden hast?

Du bittest ihn das gesagte zu wiederhohlen.

Gruss Olli

Autor: Maxim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Maxim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sobald es um Befehle mit Parametern geht, sollte man ein Protokoll 
ueberdenken. Hier ist eins als Beispiel 
:http://www.ibrtses.com/embedded/shortmsgprotocol.html

Autor: M. Kriegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://de.wikipedia.org/wiki/ARQ-Protokoll

ist vllt. auch noch eine Anregung ...

Autor: lontano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du das Paritaetsbit einbeziehst,dann hast du doch schon eine 
brauchbare Sicherheit. Die MCs arbeiten sauber...man kann alles 
uebertreiben.

Autor: Maxim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann wird er wohl synchrone Datenübertragung meinen, oder?

Autor: Maxim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: sechsdreizwei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.