BUS System

[HannoHupmann]

Hallo

für meine zukünftigen Projekte möchte ich mehrere Controller (Hauptsächlich mega32 und eventuell mega12 verwenden und die ganze Steuerung modularisieren. Daher bin ich gerade auf der Suche nach einem geeigneten BUS System.

Gefordert wird von mir, dass ich mehrere Controller miteinander verbinden kann und nicht mehr als 16 Leitungen verwendet werden müssen. Welche bekannten BUS Systeme gibt es?

TTL bzw. Seriell scheidet wohl aus, da hier nur 2 Controller miteinander verbunden werden können. Selber schreiben möchte ich ungern was, wenn es auch eine vernünftige Lösung bereits gibt.

[Felix G]

Da wäre z.B. CAN

das ist ein sehr störfestes Bussystem, das u.a. auch in den meisten Autos eingesetzt wird.

[williwilli]

Hallo HannoHupmann,

I2C bietet doch default schon die Möglichkeit, auch mehrere Master miteinander zu verbinden. Zu den Möglichkeiten gibt's schon einige Einträge im RN-Wiki, auch passende Sourcen ...
Wenn irgendwelche Gründe gegen I2C sprechen, wird es wohl RS422 oder RS485 werden müssen. Nur ob's da schon fertigen Code gibt...?

[Ceos]

über ein protokoll wirst du kaum eherumkommen, das musst du schon schreiben! als bussystem würd ich dir ein RS485 vielleicht nahelegen, das ist ncihts weiter als RS232 differentiell zu übertragen, dabei hast du dann einen 8beinigen umsetzer, der hat TX udn RX als eingang/ausgang für den controller und eine t+ und t- leitung als ausgang, auf rs485 wird dann auf "einer leitung" bidirektional übretragen, also ein gewisses timing musst du da schon selber vorbereiten damit es zu möglichst wenigen kollisionen kommt!
dann bleiben da noch 4 beinchen, 2 für + und - und je ein bein als signalleitung für empfangsmodus und sendenmodus

als Übertragungsleitung habe ich mal ein 100m LAN kabel genommen, wo ich an den gewünschten stellen die schirmung vorsichtig geöffnet habe, dann die adernpaare ein wenig entdrillt und dann über eine 9pin SUB-D klemmbuchse angezapft habe. am anfang und ende der leitung müssen abschlusswiderstände, aber ich kann nach belieben controller an und abstecken, aus der SUB-D bekomme ich dann 8 leitungen, 2 für stromversorgung (auf die distanz allerdings verwende ich noch optokoppler wegen spannungsdifferenz) 2 für handshake und 4 für 2 kanäle von RS485

handshake läuft einfach so, leitung ist über pullups auf definierten pegel und um einen sendevorgang anzukündigen wird einfach die polarität umgekehrt, ist sie bereits verdreht, darf der controller nicht senden, wird die leitung dann freigegeben, drehen alle controller mit sendebedarf die 2te leitung um und lassen die 1te wie sie ist und warten eine zeit, die sich aus adresse * 0.1ms ergibt und versucht dann die leitugn zu belegen, die regel mit der 2ten leitung ist, damit kein weiterer controller mit niedriger adresse ihn unterdrückt indem er die leitung vorher wieder belegt!

quasi wie eine bedarfs und eine besetzt leitung

[HannoHupmann]

I2C ist schon mal nicht schlecht, damit hab ich auch schon gearbeitet.

Felix G CAN Bus muss ich mir mal ansehen, bisher hab ich mich damit noch nicht auseinander gesetzt.

@Ceos klar, ein Busprotokoll brauch ich, nur muss ich nicht unbedingt selbst eines schreiben wenn es sich um nen Standart BUS handelt und es dafür bereits Quellcode gibt. Ich möchte auch etwas sehr universales einbauen und weniger eine selbstgestrickte Lösung. Daher interessieren mich vor allen erst mal die komerziellen BUS Systeme, für die gibt es meistens auch schon Bausteine u.a.


Achja es handelt sich um Entfernungen von weniger als 1m d.h. ich brauch auch keine langen Übertragungstrecken.

[Vitis]

Protokoll ... also zumindest bei 485 ist das Freistil, es gibt
kein fertiges Protokoll ... wozu auch.
Alles was Du beachten musst ist im Halbduplexbetrieb,
dass nicht zwei Busteilnehmer gleichzeitig quasseln.
Was da wer wem mitteilt ist dabei schnuppe.
Sinnvoll ist ein gemeinsames Protokoll dennoch, kann aber
auch einfach gehalten werden z.B.

000_015_set_timeout_15

000 Busmaster sender
015 empfänger
set_timeout auszuführende Aktion
15 Wert

Antwort wäre dann:

015_000_ack

015 sender
000 empfänger
ack acknowledge sprich OK, mach ich.

Du kannst Dir aber auch das Protokoll
vom Profibus reinziehen wenn Du magst.

[Gock]

Naja, 1m ist schon einiges, wenn man bedenkt, dass I2C eigentlich von Chip zu Chip gedaht war, also auf derselben Platine.
Ich würde aber auch CAN empfehlen. Das ist für einige Meter gedacht, störsicher, wie schon gesagt, es ist relativ weit verbreitet und einfach zb im Vergleich zu USB. Man bekommt immermal einen WandlerIC dafür und einige µCs können das von Hause aus.
Prinzipiell ist ein Protokoll gut, dass der µC beherrscht, weil er dann sehr effizient damit umgeht. Ein Hardware I2C oder SPI oder eben CAN ist immer besser, als die Softwarelösung. Oder aber man benutzt einen Converter.
Es gibt Megas, die CAN sprechen.
Es ist zwar seriell, aber das ist auch gut so und ich weiß nicht, was Du dagegen hast.
Allerdings habe ich noch nicht damit gearbeitet...
Gruß

[Felix G]

CAN hat natürlich den Vorteil ziemlich vollständig spezifiziert zu sein, d.h. du musst dir selbst kein Low-Level Protokol überlegen. Außerdem ist es sehr gut auch für große Strecken (bis zu 500m) geeignet.

[McJenso]

Hallo,

für CAN würde ich jetzt auch pauschal plädieren. Das Protokoll ist fertig, die Teilnehmerzahl erweiterbar, unanfällig gegen Störungen, multimaster Bus, es gibt Bibliotheken sowohl für At90CAN oder auch den MCP2515, der über SPI angeschlossen wird. Wenn du natürlich nur kurze Strecken in sauberer Umgebung hast, würde ich vielleicht auch SPI vorschlagen, da hier der externe Beschaltungsaufwand quasi entfällt. Von I2C bin ich persönlich abgekommen, das ist mir zu anfällig. RS485 ist sicher auch nicht schlecht. Wobei mir der Aufwand für ein Protokoll in der Software zu groß ist.

Gruß

Jens

[Ceos]

Wobei mir der Aufwand für ein Protokoll in der Software zu groß ist

es lebe die herausforderung

mir war die beschaltung und der verkabelungsaufwand von CAN wiederum zu groß (braucht der wirklich 12V oder geht das nicht auch irgendwie ohne?)... aber ansichtssache ^^