Hi! Die sache mit dem I2C Bus ist ja ganz nett, aber wenn ich auf ein bestimmtes externes ereignis eines slaves reagieren möchte bleibt mir nix anderes übrig als dass der master die slaves ständig anspricht und abfragt ob sich inzwischen etwas getan hat, und das vorzugsweise in dem zeitinterval in dem dieses ereignis noch gültig ist. gibt es da noch bus-systeme der nicht auf dem master slave system basiert, also in dem jeder knoten bei einem gewissen ereignis sofort bescheid geben kann so dass andere bausteine möglichst schnell reagieren können? mfg Paul H.
Solche (I2C) Bausteine, die externe Ereignisse haben (zB Eingangserweiterungen) haben dann meistens einen Interruptausgang, der dazu herangezogen werden kann als Trigger.
Naja,es gibt Bussysteme wo der Master der Reihe nach alle Slaves abpollt.Aus der Zeit die zum Abfragen eines Slaves nötig ist,ergibt sich die Zykluszeit in der spätestens ein aufgetretenes Ereignis bemerkt wird. Beim ASi dauert sowas z.b max. 5ms: http://de.wikipedia.org/wiki/AS-Interface Ansonsten müsste man von jedem Slave eine Signalisierungsleitung legen,durch die er auf sich aufmerksam machen kann.
also d.h. da hat noch niemand den goldenen bus erfunden? das problem besteht ja darin dass wenn es mehrere sender gibt, keiner von denen genau wissen kann ob ein anderer im nächsten taktzyklus nicht auch senden will und es dan eine kollision gibt. Das könnte man ja umgehen in dem man jedem Knoten eine fortlaufende adresse gibt.. 001, 002.. 003 usw. Nach jeder sendeaktion eines bausteins müssen nun mindestens die anzahl an taktzyklen gewartet werden wie hoch auch die adresse des jeweiligen senders liegt. somit hat jeder sender seine eigene taktnische in der er mal senden darf. dazu ist allerdings ein kleiner master notwendig, auch wenn er lediglich dazu dient den knoten mitzuteilen wie viele es von ihnen denn gibt, esseidenn man programmiert es ihnen ein, aber wenn man dann mal einen knoten mehr einbaut muss man gleich alle anderen neu programmieren. So eine Adresse ließe sich ja einfach mal über Dip-schalter einprogrammieren. dann bräuchte man allerdings auch 3 leitungen, eine takt-leitung, eine daten-leitung, und eine reset-leitung damit die knoten wissen wann der master ihnen mitteilen möchte wie viele knoten es gibt. Der Takt darf hier aber wohl auch nicht allzu hoch sein da der AVR ja zwischen den taktzyklen ja teilweise noch einiges an befehlen abzuarbeiten hat.. vielleicht doch lieber polling? schau mir jetzt mal das as-interface da an^^
>das problem besteht ja darin dass wenn es mehrere sender gibt, keiner >von denen genau wissen kann ob ein anderer im nächsten taktzyklus nicht >auch senden will und es dan eine kollision gibt. genau das problem ist bei can geloest...
>also d.h. da hat noch niemand den goldenen bus erfunden?
Schau Dir mal FlexRay an. Der Bus kann so ziemlich alles was das Herz
begehrt. Ist halt nur "ein wenig" komplexer als die anderen Bussysteme.
:-)
Für Deine Zwecke wäre CAN genau die richtige Wahl. Kollisionen sind dank
Arbitrierungsmechanismen keine Thema. Ausserdem nehmen Dir die
Communication Controller einen Haufen an Arbeit ab, so daß das Handling
von CAN nicht wesentlich schwieriger als der I2C sein sollte.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.