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