|
Anzeige
|
welcher Bus für Kommunikation zwischen Platinen?
Gast
#4945907
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 Alle dürfen unsynchronisiert senden -> Multimaster -> CAN Viele Grüße, Stefan -> ganz eng <- plus *> keine Geschwindigkeitsangabe <* UART Master Tx auf alle Slaves, Slave Tx als wired-and I2C SPI Birger Bus schrieb: > ganz eng gepackt CAN ohne Transceiver (Siemens AP2921)
Gast
#4946649
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 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.
Gast
#4946718
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
Gast
#4946757
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. 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... 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.
Gast
#4947036
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. Antwort schreiben |
Anzeige
|
