Hallo, ich möchte gerne ein Bus-System für mich auf die Beine stellen. Als "Master" soll ein Raspberry-Pi Model B genutzt werden. Meine Frage an euch ist jetzt, welche Schnittstelle ich am besten nutze, um ATMega's anzusprechen. Zur Auswahl stehen der UART (Favorit), SPI und I²C. Wichtig ist, das möglichst wenig Adern benötigt werden (UART, I²C), und eine größtmögliche Entfernung Schaffbar ist (Wenn machbar, 30-35m ohne "Repeater). Ich persönlich würde sagen das der UART dafür am besten geeignet ist. Was mein ihr? MFG
Busman schrieb: > Ich persönlich würde sagen das der UART dafür am besten geeignet ist. > Was mein ihr? mit einem passenden treiber aka RS 485 absolut kein problem.
SPI und I²C sind nur für ganz kurze Strecken von wenigen Zentimetern geeignet. Mit RS232 hatte ich schonmal 25 Meter bei 115200 Baud gemacht, aber das war kein Bus, sondern nur Pont-To-Point. Schau Dir mal RS485 an.
Wie schon gesagt, RS485. Paarweise verseilte Leitung verwenden. Datenrate nur so hoch wählen wie benötigt wird. Dann sollten die 35m kein Problem sein.
Die Aufgabenstellung ist irgendwie falsch formuliert. Du willst große Entfernungen: RS422 oder RS485 Du willst wenig Adern im Kabel: UART oder I2C Du willst es einfach: UART Jetzt mußt Du Dir nur noch klar werden, ob die Kommunikation bidirektional oder uni werden soll, ob Du die weiteren Module über das gleich Kabel mit Strom versorgen willst oder nicht. Und, und, und...
Ist es denn ein größerer Programmieraufwand RS485 zu nutzen? Wie nutze ich den ein RS485-Tranceiver ? Über die leitung wollte ich zusätzlich noch eine Spannung von 24V mitgeben, sofern das kein Störeinfluss ist.
RS485 hat nur ein Adernpaar für alle Teilnehmer, Master oder Slave ist da egal. Es braucht einen Mechanismus in der Software, der einem Gerät das Senden erlaubt, die Treiber entsprechend schaltet (Datenblatt lesen oder Tutorial hier). Sende-Konflikte sollten beherrschbar sein. Hat das System nur einen Master, so nimm RS422 für die Kommunikation Master->Slave und RS485 für Slave->Master. Braucht auch nur 4 Datenleitungen. Oder am besten nimm gleich CAN.
Hallo, eigentlich möchte ich das Im Bus mehrere Geräte sitzen. Alle Geräte kommunizieren mit Hilfe einer (An jeden Teilnehmer) vergebenen Adresse. Einen Master benötige ich als doch nicht. Der Raspberry PI wird somit nur die Kommunikationsschnittstelle für Computer, Netzwerk usw. Welche Schnittstelle schafft da längere Leitungen? Geplant hatte ich ein 4-6 Adern-Kabel, auf dem 2 Pins für 24V sind, und 2-4 für die Schnittstelle. Also benötige ich ein System das hier 2-4 Adern vorweist, lange Leitungslängen unterstützt, und ohne Explizite Master-Slave vergebung funzt.
Wenn alle gleichberechtigt sein sollen, dann ist CAN dein Freund. Christian_RX7
CAN sieht auf dem ersten Blick ganz Gut aus. Was für Hardware benötige ich um am Raspberry PI einen CAN-BUS zu erstellen?
Ich habe mir jetzt einmal folgende Belegung ausgedacht: 6-Poliges Modular-Kabel mit RJ12-Buchse: P1: CAN_V 24V+ P2: FREI Notfall-Reserve P3: CAN_D CAN-Daten P4: CAN_D2 CAN-Daten2 P5: FREI Notfall-Reserve P6: CAN_GND Jetzt ist nur noch die Frage, ob ich für CAN irgendwelche Treiber benötige (Insbesondere am RaspberryPI), und eventuell wäre ein bisschen nachschlaglektüre auch nicht Schlecht. Ich hoffe ihr könnt mir weiterhelfen, Busman
http://www.skpang.co.uk/catalog/pican-canbus-board-for-raspberry-pi-p-1196.html http://lnxpps.de/rpie/
Ich hab mal den MCP2515 per SPI an den Pi angebunden und einen SN65HVD230D als Transceiver dazu. Funktioniert bei mir wunderbar, wie man die Treiber dafür hinkriegt weiß Google - ich aus dem Kopf leider nicht mehr...
Busman schrieb: > CAN sieht auf dem ersten Blick ganz Gut aus. Was für Hardware benötige > ich um am Raspberry PI einen CAN-BUS zu erstellen? Die meisten Leute verwenden MCP2515 SPI-CAN Controller, sowohl für den PI als auch für AVRs. Der ist allerdings nicht besonders leistungsfähig. Die meisten aktuellen PICs haben die verbesserte Version mit mehr Buffer und Filter eingebaut, und der Preisunterschied zwischen einem MCP2515 und z.B. einem PIC18F25K80 ist relativ gering, so dass es sinniger ist, gleich den CAN-Controller mit eingebautem PIC zu nehmen und auf die AVRs zu verzichten. Einen der PICs kannst Du dann auch per SPI oder UART an den PI hängen. fchk
Danke Falk, Ich hab das jetzt so verstanden, das an Das RPI (Oder den ATMega etc) via SPI der MCP2515 kommt, dahinter kommt dann der MCP2551. Aus dem MCP2551 kommt dann CAN, Richtig? Dann habe ich das jetzt nähmlich verstanden.
Busman schrieb: > Ich hab das jetzt so verstanden, das an Das RPI (Oder den ATMega etc) > via SPI der MCP2515 kommt, dahinter kommt dann der MCP2551. Aus dem > MCP2551 kommt dann CAN, Richtig? Eine CAN Peripherie besteht ähnlich wie bei Ethernet immer aus zwei Teilen: einem MAC (dem Digitalteil, zB dem MCP2515 oder dem ECAN-Controller des erwähnten PIC18F25K80) und einem PHY (dem Analogteil, heißt bei CAN auch Transceiver). Der CAN PHY ist immer ein externer 8-Pinner im SO8 oder DIL8. Je nach spezifischen Anforderungen gibts viele verschiedene, für schnelle und langsame Busse, besonders robuste Typen wie MAX1305x (die können bis +-80V ab), und auch besondere Typen für reine 3.3V-Systeme (CAN ist normalerweise ein 5V-Standard). > Dann habe ich das jetzt nähmlich verstanden. Wer nämlich mit h schreibt, ist ... fchk
>SPI und I²C sind nur für ganz kurze Strecken von wenigen Zentimetern >geeignet. Wenns sein muss geht das auch (richtig aufgeteilt) über einge m.
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.