RS485 onboard

[Oz z. (ozzy)]

Moin,

ich plane für ein Projekt den Bau eines langen (ca. 50cm) BusBoards, auf 
das dann z.B. die Prozessorkarte und Erweiterungen (Sensoren) gesteckt 
werden können. Für die Kommunikation mit dem Busboard nach aussen sollen 
eine Ethernet- und eine RS485-Verbindung existieren.
Nun meine Frage: nutzt man überhaupt RS485 als Bus auf einer Platine, 
oder setzt man den Treiber-chip direkt an das Kabel nach draussen?
Ich überlege eben nur, da es ja auch möglich ist, später evtl. Sensoren, 
die über RS485 kommunizieren, einzubauen. Da müsste man dann auf der 
Erweiterungsplatine dann ebenfalls einen Treiberbaustein einbauen.

Was haltet Ihr da für sinnvoll? Ich weiß momentan auch noch nicht, wie 
das fertige System irgendwann einmal aussehen wird, möchte nur eben 
gerne schon einmal vorbeugen, nicht, dass ich die Platinen noch einmal 
fertigen lassen muss.

Vielen Dank,
Ozzy

[Sascha W. (sascha_w)]

Christoph O. schrieb:
> ich plane für ein Projekt den Bau eines langen (ca. 50cm) BusBoards, auf
> das dann z.B. die Prozessorkarte und Erweiterungen (Sensoren) gesteckt
> werden können. Für die Kommunikation mit dem Busboard nach aussen sollen
> eine Ethernet- und eine RS485-Verbindung existieren.
> Nun meine Frage: nutzt man überhaupt RS485 als Bus auf einer Platine,
für die 50cm brauchst du noch kein RS485

> oder setzt man den Treiber-chip direkt an das Kabel nach draussen?
schon eher

> Ich überlege eben nur, da es ja auch möglich ist, später evtl. Sensoren,
> die über RS485 kommunizieren, einzubauen. Da müsste man dann auf der
> Erweiterungsplatine dann ebenfalls einen Treiberbaustein einbauen.
> Was haltet Ihr da für sinnvoll?
da musst du jetzt überlegen ...
1) sollen die Erweiterungen am BusBoard direkt mit extern 
angeschlossenen Baugruppen kommunizieren, dann währe die Verwendung von 
RS485 auf allen Erweiterungsbaugruppen (intern/extern) sinnvoll. Sonst 
bleibt immer nur der Weg über den Prozessor
2) laufen alle Kommunikationswege am Prozessor zusammen und die 
Erweiterungen sind nur Slave's am Bus, dann brauchst du intern keine 
RS485

> Ich weiß momentan auch noch nicht, wie
> das fertige System irgendwann einmal aussehen wird, möchte nur eben
> gerne schon einmal vorbeugen, nicht, dass ich die Platinen noch einmal
> fertigen lassen muss.
was würdest du denn am internen Bus verwenden wollen - eine RS232 lässt 
sich ja auch nicht besonders auf mehr als 2 Busteilnehmer verteilen.

Sascha

[Oz z. (ozzy)]

Moin,

erst einmal danke für Deine Antwort. Naja, die Frage die sich mir 
stellt, ist, ob man den Treiber direkt am Übergang Kabel-Platine macht 
und dann auf RS232 geht, oder man den Bus bis kurz vor den Prozessor auf 
RS485 lässt, um ggf. einen RS485-Sensor mit dem Prozessor kommunizieren 
lassen zu können. Normalerweise sind die Leitungen doch verdillt. Kann 
es bei parallel auf der Platine verlaufenden Leitungen da zu Problemen 
kommen? Sollte man zwischen/neben den Leitungen jeweils eine 
Masseleitung verlegen?

MfG, und vielen Dank, Ozzy

[Michael X. (Firma: vyuxc) (der-michl)]

485 sollte mit 120 Ohm abgeschlossen sein.

[Frank K. (fchk)]

Wenn ich mir das so anschaue, kommt mir folgende Idee:

1. CAN statt RS485. Bei CAN macht der Controller mehr automatisch, was 
man bei 485 sonst zu Fuß machen müßte - Busarbitrierung, CRC und 
ähnliche Sachen

2. auf eine zentrale Busplatine verzichten; CAN-Busse auf kurzen 
Strecken durch ungeschirmte RJ45-Kabel weiterreichen, wobei Ground und 
CANH/CANL sich abwechseln. Über längere Strecken Netzwerkkabel 
verwenden. Jeder Teilnehmer bekommt 2 RJ45-Buchsen, so dass Du den Bus 
immer weiter schalten kannst. An die Enden kommen Blindstecker mit 120 
Ohm Terminatoren.

3. Die CPU-Karte könnte einen Luminary LM3S8970 bekommen; der hat gleich 
3*CAN und 10/100 Ethernet MAC+PHY eingebaut. Das wären dann 7*RJ45, je 2 
pro CAN-Bus und einmal fürs Ethernet (mit eingebautem Übertrager). So 
kannst Du den Traffic auf mehrere Busse verteilen und auf dem 8970 
zwischen den Bussen routen, wenn das nötig sein sollte.

4. Für die Slaves wären beispielsweise NXP Cortex M0 (LPC11C12 oder so) 
oder ein STM32F103C oder irgendwas anderes denkbar.

5. Bei CAN hast Du immer einen MAC (den eigentlichen CAN-Controller, im 
Microcontroller oder als extra Chip) und einen PHY, einen externen 
8-Pinner, der die Analog-Treiber enthält. Hier gibts verschiedene, je 
nach Busgeschwindigkeit und Buslänge, aber das Pinout ist fast immer das 
gleiche.

Das sind jetzt meine Ideen so auf die Schnelle.

fchk