Serielle Datenübertragung im Selbstbau

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?

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.

@ 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

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

@ 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

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