welcher Bus für Kommunikation zwischen Platinen?

[Birger Bus (Gast)]

Hallo,

ich denke gerade über ein Modul nach, das Daten von an ihm 
angeschlossenen Geräten loggt und per übergeordnetem Gerät (Master)
zugreifbar macht.
Dieses Modul kann dann so mehrfach verwendet werden alle Geräte sollen
über einen Bus mit dem Master kommunizieren können.

Welches Bussystem würde sich für ein solches System am ehesten eignen, 
d.h. für Platinen, die gestapelt bzw. ganz eng gepackt sind?

RS485?
I2C?

VG

[Stefan K. (stefan64)]

Alle dürfen unsynchronisiert senden -> Multimaster -> CAN

Viele Grüße, Stefan

[Marcus H. (Firma: www.harerod.de) (lungfish)]

-> ganz eng <-

plus

*> keine Geschwindigkeitsangabe <*

UART   Master Tx auf alle Slaves, Slave Tx als wired-and
I2C
SPI

[Volker S. (vloki)]

Birger Bus schrieb:
> ganz eng gepackt

CAN ohne Transceiver (Siemens AP2921)

[Birger Bus (Gast)]

Marcus H. schrieb:
> -> ganz eng <-
>
> plus
>
> *> keine Geschwindigkeitsangabe <*
>
> UART   Master Tx auf alle Slaves, Slave Tx als wired-and
> I2C
> SPI

also mir reicht eine Geschwindigkeit von
115200 bauds (par seconde)

d.h. alles Slave TX verbinden und jeweils ne Diode z.B.
1N4148 dazwischen knallen?

VG

[Rufus Τ. F. (rufus)]

Sofern Du das Protokoll von "jeder Teilnehmer sendet, wann er Lust dazu 
hat" zu einem geordneten, von einem Master gesteuerten Verfahren 
abänderst, kannst Du auch I2C verwenden.

Das benötigt zwei Leitungen, kann ziemlich viele Teilnehmer adressieren, 
und ist mit typisch* 400 kBit/sec auch etwas flotter.

Da das Protokoll standardisiert ist, gibt es entsprechend viel 
Unterstützung sowohl auf der Hardwareseite (viele µCs haben direkte 
Hardwareunterstützung dafür eingebaut) als auch auf der Softwareseite.


*) Daneben sind noch 100 kBit/sec und, sofern es die jeweiligen 
Bausteine unterstützen, auch noch deutlich höhere Datenraten möglich.

[Birger Bus (Gast)]

Rufus Τ. F. schrieb:
> Sofern Du das Protokoll von "jeder Teilnehmer sendet, wann er Lust dazu
> hat" zu einem geordneten, von einem Master gesteuerten Verfahren
> abänderst, kannst Du auch I2C verwenden.

Hallo, der Master soll in diesem Fall ein kleiner Linux Rechner sein 
z.B. so ein Beaglebone o.ä.

d.h. ein Teilnehmer wird ungefragt nicht senden!

VG

[m.n. (Gast)]

Birger Bus schrieb:
> also mir reicht eine Geschwindigkeit von 115200 baud

Dann würde ich Dir zu UART mit Multiprozessorprotokoll raten, was jeder 
aktuelle µC bieten sollte. Nur der Master darf jederzeit adressieren und 
senden und nur der angesprochene Slave darf antworten. Eine Diode zur 
Entkopplung der Slave-TX-Leitungen kann entfallen, wenn der Ausgang vom 
nicht aktiven Slave deaktiviert wird.
Die Kommunikation per UART kann voll-duplex ablaufen.

IIC wäre eine Option, wenn ein Teilnehmer nur darüber angesprochen 
werden kann. IIC ohne "besondere Maßnahmen" kann hängen bleiben.
Die Kommunikation ist immer halb-duplex.

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Birger Bus schrieb:
> Marcus H. schrieb:

> also mir reicht eine Geschwindigkeit von
> 115200 bauds (par seconde)
Je vois ce que vous avez fait là. "Baudots par seconde"  lôl

> d.h. alles Slave TX verbinden und jeweils ne Diode z.B.
> 1N4148 dazwischen knallen?
Klassisch, wenn Du nur push-pull-Ausgänge hast, dann alle Slave-TX per 
Diode zusammenschalten. Kathoden an TX, Anoden an Master-RX. Dann noch 
ein Pull-Up an den Master-RX. Ruhezustand bei TTL-RS232-UART ist 1. Der 
Wert des Pull-Ups ermittelt sich aus der Stromtragfähigkeit der 
Ausgänge, der Buskapazität und der gewünschten Geschwindigkeit. Also ein 
Kilo Ohm. ;)

Bei vielen MCUs kannst Du GPIOs als Open-Drain schalten, dann erübrigen 
sich die Dioden.

Und bitte nicht so laut knallen - Elektronik ist schüchtern...

[Rufus Τ. F. (rufus)]

Birger Bus schrieb:
> Hallo, der Master soll in diesem Fall ein kleiner Linux Rechner sein
> z.B. so ein Beaglebone o.ä.
>
> d.h. ein Teilnehmer wird ungefragt nicht senden!

Dann kannst Du I2C verwenden. Natürlich gehen auch andere Varianten, das 
ist keine Absolutheit.

m.n. schrieb:
> UART mit Multiprozessorprotokoll

Kann halt nicht jede UART, so z.b. nicht die in normalen PCs verbauten 
UARTs und auch nicht die in USB-Seriell-Adaptern zu findenden. Ansonsten 
ist das ja durchaus schick.

> Die Kommunikation per UART kann voll-duplex ablaufen.

Ich sehe hier nicht wirklich, wie das mit einem 
Single-Master/Multiple-Slave-Protokoll sinnvoll verbunden werden kann.

[m.n. (Gast)]

Rufus Τ. F. schrieb:
> Ich sehe hier nicht wirklich, wie das mit einem
> Single-Master/Multiple-Slave-Protokoll sinnvoll verbunden werden kann.

Ganz einfach: es können keine Kollisionen auftreten. Ein Slave kann 
schon antworten, während der Master noch neue Daten übermittelt.

Rufus Τ. F. schrieb:
> Kann halt nicht jede UART, so z.b. nicht die in normalen PCs verbauten
> UARTs und auch nicht die in USB-Seriell-Adaptern zu findenden.

Bei PCs hatte ich seinerzeit kleine Buchstaben 'a', 'b', ... als Adresse 
verwendet und die restliche Übertragung per Großbuchstaben oder im 
IHEX-Format. Bei korrekter Adressierung hat der Slave in der RX-ISR 
seine Adresse als Echo geschickt, wodurch schnell festzustellen war, wer 
alles am Bus hängt.