www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Robuste Datenverbindung


Autor: Tüftler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum!

Ich möchte eine Datenübertragung zwischen zwei Platinen (beide mit 
AVR-Mikrocontroller) realisieren. Die Entfernung zwischen den beiden 
beträgt ca. 2m, beide sind auf einem Fahrzeug angebracht, wobei sich 
eine Platine draussen, die andere in einer Fahrerkabine befindet. Der 
Prozessor drinnen hat eine Art Master-Funktion und sendet Befehle an den 
draußen befindlichen Prozessor, der Prozessor draußen quittiert den 
Empfang der Daten. Also Kommunikation in beide Richtungen. Wichtig für 
mich ist die Robustheit und Konsistenz der Daten. Die Datenmengen sind 
gering, dafür ist die Korrektheit aber wichtig. Ich habe mir bereits ein 
paar Möglichkeiten überlegt, weiss aber nicht so recht, was die beste 
Lösung ist. Funk kommt nicht in Frage. Grundsätzlich denke ich, dass das 
Signal kabelgebunden und differentiell übertragen werden soll.

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)

SPI:
Hmm...Ein solches Bussystem ist nicht so geeignet(?)
bzgl. Signalpegel oder differential. Datensicherung findet auch nicht 
statt, d.h. ich müsste die Daten selbst mittels CRC o.ä. prüfen.
Vielleicht übersehe ich ja auch ein paar Vorteile.

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...

Bitte um Kommentare zu den Möglichkeiten. Kennt noch jemand 
Alternativen?

Viele Grüße
Tüftler

Autor: Falk Brunner (falk)
Datum:

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

Autor: Christoph Budelmann (Firma: Budelmann Elektronik GmbH) (christophbudelmann) Benutzerseite
Datum:

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

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: Lehrmann Michael (ubimbo)
Datum:

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

Autor: Tüftler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
danke schonmal für die Antworten!


Habe noch zwei Fragen:

@Falk Brunner
* 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?

@all
* Wie sieht es denn aus, wenn noch ein dritter Slave ins Spiel kommen 
soll? Würdet ihr dann zwei getrennte RS422-Verbindungen nehmen, oder 
eine gemeinsame RS485-Verbindung? Oder ist dann ein CAN-Bus die bessere 
Wahl?

Gruß
Tüftler

Autor: Falk Brunner (falk)
Datum:

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

Autor: Uwe ... (uwegw)
Datum:

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

Autor: Tüftler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe ... schrieb:
> Nein, weil RS232 rein byte-orientiert ist. Die Synchronisation erfolgt
> bei jedem neuen Byte anhand des Startbits.

Stimmt, Denkfehler von mir.

Falk Brunner schrieb:
> 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?"

Gute links, sehr informativ! Plesiochrone Systeme, da war mal was im 
Studium ;-)

Also wird die Wahl auf den CAN-Bus fallen, da ich mir die Möglichkeit 
vorbehalten will, einen dritten Teilnehmer mit ins Boot zu nehmen.

Die Frage für mich ist jetzt, ob ich einen AT90CANxx nehme, oder den von 
Michael Lehrmann vorgeschlagenen MCP2515 (+ Atmega). Hat da jemand 
Erfahrung?

Grüße
Tüftler

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.