Robuste Datenverbindung

@Tüftler (Gast)

>RS232 mit UART:
>Einfach zu realisieren. TX und RX physisch getrennt. Realiserung mit
>Differential-Übertragung kein Problem.

Dann hiest es aber RS422 ;-)

> Aber ist die Übertragung ohne
>Takt und das Fehlen von Datensicherung in Hardware nicht ein großer
>Nachteil?

Nein.

>(Bei einem Paritätsbit kann man nicht wirklich von Datensicherung
>sprechen)

Dazu nimmt man eine CRC.

>SPI:
>Hmm...Ein solches Bussystem ist nicht so geeignet(?)

Nicht sinnvoll, wenn gleich machbar. Braucht aber mehr Leitungen und 
auch eine zusätzliche CRC. Der Geschwindigkeitsvorteil wird nicht 
benötigt.

>CAN:
>Ist der Industrie-Standard für solche Anwendungen. Übernimmt OSI Schicht
>1+2.

Ja, da ist viel Zeug drin, CRC und Mehrfachübertragung etc. Die Treiber 
sind sehr robust.

> Allerdings habe ich mit CAN bisher noch nichts gemacht. Ich kann
>den Aufwand mich da einzuarbeiten schlecht abschätzen.

Keine Ahnung.

MfG
Falk

Tüftler schrieb:
> RS232 mit UART:
> Einfach zu realisieren. TX und RX physisch getrennt. Realiserung mit
> Differential-Übertragung kein Problem. Aber ist die Übertragung ohne
> Takt und das Fehlen von Datensicherung in Hardware nicht ein großer
> Nachteil?
> (Bei einem Paritätsbit kann man nicht wirklich von Datensicherung
> sprechen)

Es hält dich niemand davon ab, im Controller mehr Aufwand zur 
Sicherstellung der Datenkorrektheit zu betreiben. Gängig sind 
Checksummen zur Feststellung von Fehlern (von einfachen 
XOR-Verknüpfungen bis hin zu CRC-Checksummen und einigem mehr) oder der 
Einsatz fehlerkorrigierender Codes. Bei deiner Anwendung würde ich aber 
einfach vorschlagen, die Daten differentiell per RS422 zu übertragen und 
über eine Checksumme abzusichern - das dürfte reichen.

> CAN:
> Ist der Industrie-Standard für solche Anwendungen. Übernimmt OSI Schicht
> 1+2. Allerdings habe ich mit CAN bisher noch nichts gemacht. Ich kann
> den Aufwand mich da einzuarbeiten schlecht abschätzen. Sieht laut
> Wikipedia aber nicht so kompliziert aus, wenn zwischen zwei Teilnehmern
> kleine Pakete hin und her geschickt werden...

Kann man machen, ist aber definitiv mehr Aufwand als RS422 und für die 
Anwendung nicht nötig.

Tüftler schrieb:
> RS232 mit UART:
>
> Einfach zu realisieren. TX und RX physisch getrennt

2m sind auch mit RS232 kein Problem.
Wenn man kein Geschwindigkeitsfanatiker ist, kann man damit sogar 
wesentlich längere Strecken überbrücken. Und ein paar Byte mit XOR 
abzusichern ist völlig OK.

mfg.

Tüftler schrieb:
> CAN:
> Ist der Industrie-Standard für solche Anwendungen. Übernimmt OSI Schicht
> 1+2. Allerdings habe ich mit CAN bisher noch nichts gemacht. Ich kann
> den Aufwand mich da einzuarbeiten schlecht abschätzen. Sieht laut
> Wikipedia aber nicht so kompliziert aus, wenn zwischen zwei Teilnehmern
> kleine Pakete hin und her geschickt werden...

Servus,

CAN ist nicht sonderlich komplizierter als UART oder I2C.

Mein Tipp: Nimm den MCP2515 (CAN-Controller) und den MCP2551 
(CAN-Treiber). Kosten je ca. 1-2€
Hab dir mal aus dem CAN:Artikel was rauskopiert:

MCP2515
    * SPI Schnittstelle
    * 2 Empfangs- und 3 Sendepuffer jeweils individuell konfigurierbar 
(ID, Masken/Filter etc.)
    * ein gemeinsamer Interruptpin (RX)
    * ein Interruptpin pro Empfangspuffer, umkonfigurierbar als GPO
    * ein Triggerpin pro Sendepuffer, umkonfigurierbar als GPI
    * Stromsparmodus
    * auch für 3,3V-Betrieb geeignet.
    * Diverse C- und Assembler Beispielcodes verfügbar (z. B. bei 
microchip.com und kvaser, Assembler meist für PICs). Auch Software für 
Direktanschluss an die parallele Schnittstelle eines PC verfügbar 
("bit-bang Interface").
    * erhältlich z. B. bei Reichelt (ca. 2€)

Es gibt genügend Projekte mit AVRs die sich mit dem MCP2515 
beschäftigen.
Der MCP2551 ist nur der Treiber (ähnlich dem MAX232 für RS232 halt in 
diesem Fall für CAN).

@  Tüftler (Gast)

>* Das asynchrone Senden ist deiner Aussage nach kein Nachteil.

Das ist auch so ;-)

> Macht es
>Sinn, eine Präambel à la 0x55 0x55 wie bei Ethernet zu senden, damit
>sich der Empfänger synchronisieren kann?

Nein, ist ja RS232 und kein Ethernet. Der Empänger funktioniert anders.

http://www.mikrocontroller.net/articles/UART#Siehe_auch
Beitrag "Unnachvollziehbares Verhalten von AVR mit UART"
Beitrag "Woran erkennt ein UART eigentlich das Startbit?"

>* Wie sieht es denn aus, wenn noch ein dritter Slave ins Spiel kommen
>soll? Würdet ihr dann zwei getrennte RS422-Verbindungen nehmen,

Kan man machen.

> oder eine gemeinsame RS485-Verbindung?

Geht auch, dann braucht man aber ein kleines Protokoll.

> Oder ist dann ein CAN-Bus die bessere Wahl?

Ja, denn dort ist das alles schon fix und fertig drin.

MFG
Falk

Tüftler schrieb:
> * Das asynchrone Senden ist deiner Aussage nach kein Nachteil. Macht es
> Sinn, eine Präambel à la 0x55 0x55 wie bei Ethernet zu senden, damit
> sich der Empfänger synchronisieren kann?

Nein, weil RS232 rein byte-orientiert ist. Die Synchronisation erfolgt 
bei jedem neuen Byte anhand des Startbits.