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