-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

Thema: BUS System

  1. #1
    Moderator Robotik Einstein Avatar von HannoHupmann
    Registriert seit
    19.11.2005
    Ort
    München
    Alter
    34
    Beiträge
    4.528
    Blog-Einträge
    1

    BUS System

    Anzeige

    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.

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von Felix G
    Registriert seit
    29.06.2004
    Ort
    49°32'N 8°40'E
    Alter
    34
    Beiträge
    1.780
    Da wäre z.B. CAN

    das ist ein sehr störfestes Bussystem, das u.a. auch in den meisten Autos eingesetzt wird.
    So viele Treppen und so wenig Zeit!

  3. #3
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    24.07.2008
    Alter
    54
    Beiträge
    224
    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...?
    Geht das nicht auch einfacher???

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    33
    Beiträge
    2.380
    ü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

  5. #5
    Moderator Robotik Einstein Avatar von HannoHupmann
    Registriert seit
    19.11.2005
    Ort
    München
    Alter
    34
    Beiträge
    4.528
    Blog-Einträge
    1
    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.

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    43
    Beiträge
    2.240
    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.
    Vor den Erfolg haben die Götter den Schweiß gesetzt

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    25.11.2003
    Beiträge
    1.111
    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ß

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Felix G
    Registriert seit
    29.06.2004
    Ort
    49°32'N 8°40'E
    Alter
    34
    Beiträge
    1.780
    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.
    So viele Treppen und so wenig Zeit!

  9. #9
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    20.05.2006
    Ort
    Lippe
    Alter
    48
    Beiträge
    524
    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

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    33
    Beiträge
    2.380
    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 ^^

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •