Normierung von Roboter Steckern

Hallo Frank,

Zitat:

---

Damit ist er nicht mehr ganz kompatibel zu Joerg´s Entwurf, aber INT ist wirklich sehr wichtig, eigentlich gehört das zu jedem I2C-Bus wird nur immer vergessen.

---

naja, das will schon gut überlegt sein. Mir persönlich ist nur der PCF8574(A) bekannt, der diese Interruptlogik unterstützt. Mag aber sein, dass es noch andere Phillips-ICs gibt, die das ausnutzen. Zumindest kenne ich (noch) kein Robotik-Sensormodul, was diese INT-Leitung benötigt.

Die Frage ist, was bringt dieses Signal wirklich. Man kann die Leitung nutzen um am Host eine IO-Änderung des PCF8574 zu signalisieren.
Das bedeutet aber, nur ein PCF-Baustein hätte von dieser Leitung wirklich etwas (peer2peer). Man kann zwar auch mehrere INT-Ausgänge parallel schalten (open drain), aber dann fängt der Host im Signalisierungsfall an, alle möglichen PCF abzufragen womit der Vorteil dann auch wieder vertan wäre.

Aber das ist natürlich guter Stoff für eine Diskussion. Gibt es jemanden, der diese Leitung momentan in seinem Robotik-Projekt nutzt?

Viele Grüße
Jörg

Nun, nachdem noch keine Software geschrieben wurde, wird der INT noch nicht benutzt. Ich habe ihn aber Hardwareseitig mit realisiert, so dass es kein Problem wäre ihn zu verwenden.

Ich kenne derzeit auch nur den PCF8674, der den INT besitzt, finde es aber schon eine feine Sache.

Hallo,

es ist in der Tat so das der INT-Ausgang von den meisten noch vernachlässigt wird. Liegt in erster Linie halt auch daran das viele Bastler erst jetzt richtig Anfangen den I2C-Bus zu nutzen.
Ich hab ihn allerdings auf meinem nächsten Board auch fest vorgesehen.
Er hat schon einige Vorteile! Wenn man den PCF zum Überwachen zahlreicher Sensoren benutzt, die nur in sehr unregelmäßigen nicht vorhersehbaren Abständen reagieren, dann ist es schon schön wenn der Controller über einen Interrupt informiert wird das sich was getan hat und er sich nun schnellstens darum kümmern muss alle I2C Sensoren auszulesen. Dies ist in einer Schleife sehr schnell machbar!

Genutzt wird der INT Eingang auch von vielen Projekten im CC2Net (C-Control II). Und da es keinen Aufwand darstellt diesen mitzuführen, sollte man das vorsehen. Man muss ihn ja nicht nutzen.
Zudem ist sehr wahrscheinlich das auch weitere I2C Bausteine diesen INT Eingang nutzen werden.

Gruß Frank

Naja, überzeugt bin ich von der allgemeinen Zweckmäßigkeit nicht, aber es könnte vielleicht für kleine konkrete Projekte (wenige Slaves) einen winzigen Vorteil bringen.
Es ist nunmal beim I2C so, dass der Master quasi alle Daten einsammelt. Die INT-Leitung erlaubt jetzt ein priorisiertes Einsammeln. Jedoch, je mehr Slaves dieses Feature nutzen, desto weniger bringt es.

Zitat:

---

es ist in der Tat so das der INT-Ausgang von den meisten noch vernachlässigt wird.

---

Fakt ist zumindest, die INT-Leitung ist nicht Bestandteil der I2C-Spezifikation (siehe auch AN10216-01 - I2C MANUAL). Man kann es als nützliche Erweiterung betrachten und die Frage ist halt, ob's Sinn macht die Leitung in die Roboternetz-Spec mit aufzunehmen und damit leicht inkompatibel zur Elektor und zu den Embedit Boards zu werden.
Bislang sieht's wohl so aus.

Viele Grüße
Jörg

Hi
Genau gesagt nimmt der Vorteil nicht mit der Anzahl der Slaves sondern nur mit der Anzahl der Slaves ab die diese auch benutzen, nur diese müssen abgefragt werden. Da abe rnicht von 100 Modulen ausgegangen werden kann, dürfte der Vorteil noch groß genug sein.

Vorteil liegt auch in der einfachen Programmierung von zeitkritischen Dingen. Es ist halt bequemer auf einen Interrupt zu reagieren als ständig alle Sensoren überprüfen zu müssen.

Ja INT gehört nicht zu den I2C Spezifikationen! Das liegt natürlich auch daran das man diesen Bus als 2 Leitungsbus durchsetzen wollte. Vielleicht sind die Entwickler auch einfach zu spät auf die Idee mit dem INT gekommmen , wer weiss das schon ;-)

Aber da die Vorgaben von Elektor und Embedit ja noch nicht so große Verbreitung gefunden haben sollte diese kleine Abweichung doch aufgrund der weiteren Möglichkeiten sinnvoll sein. Durch einfaches durchtrennen oder weglassen einer Leitung wäre man wieder kompatibel zu Elektor!
Aber es wäre doch nervig wenn man wegen dieser einen Leitung noch irgendwo ein Kabel anlöten müsste.

Gruß Frank

hi @ all,
ich bin auch ein freund der 2x5pol version
allerdings halte ich nix davon die komplette stromversorgung
ueber diese pinleiste zu realiesieren
ich denke es ist sinnvoll stromversorgung
und datenleitungen zu trennen
also ein 2x5pol fuer daten und irgendein anschluss fuer die stromversorgung
gerade bei microcontrolern wird haeufig solch eine variante gewaehlt
allerdings bin ich auch ein neuling und vielleicht gibt
es gute gruende fuer eure version

gruss skammel

Die guten Gründe für unsere Version ist zum einen das es halt schon Boards mit diesme Stecker gibt. Zum anderen ist es viel bequemer wenn man an Erweiterungen nur ein Kabel anschließen muss. Nur bei Erweiterungen die sehr viel Strom benötigen wären zusätzliche Leitungen notwendig.

Das es Sinn macht die Stromversorgung mitzuführen sieht man u.a. auch bei dem USB-Bus. Er ist gerade deshalb so beliebt und bequem!

Drehen wir die Argumentation mal um: Was spricht dagegen beides zu kombinieren?

Gruß Frank

Ich meine, man kann da ganz gut differenzieren.
Bei wirklichen Lasten wie Aktoren (von denen auch entsprechend große Störungen auf die Datenleitungen ausgehen können) sollte man auf eine getrennte Stromversorgung setzen.

Aber gerade bei sowas wie Displays hat man nur Kabelsalat, wenn man noch zwei zusätzliche Leitungen benötigt.

@Frank, OK bei niedrigen stroemen macht es wohl sinn die versorgung mitzufuehren

den vorschlag mit der INT-leitung halte ich auch fuer sinnvoll gerade
in bezug auf sensoren

gruss skammel

Hi,
vielleicht sollt man auf unserem Standardboard einen Jumper (Steckbrücke) vorsehen mit der man die Spannungen vom Stecker nehmen kann denn bei Hochstromverbrauchern wie Motoren etc. sollte man wirklich erst vor Ort einspeisen da gerade diese auch ziemlichen Frequenzmüll produzieren. Und der kann zu merkwürdigen Fehlern führen die sich unter Umständen wie ein Programmbug darstellen.

Gruß Hartmut