Drehgeber an der C-Control I

[Frank]

Hallo Frank,

Ein Aufsummieren der Werte auf größere Bereiche sollte bei regelmäßiger
Abfrage im Programm ohne weiteres möglich sein.
Duch einen Interrupt-Ausgang muß das Zählermodul nur bei Änderung
des Zählerstands abgefragt werden.
MfG André H.

Hast Du da nicht einen Denkfehler bei der Konzeption gemacht? Wozu soll den der Interupt gut sein? Wenn bei jedem neuen Impuls der gezählt wird ein Interrupt ausgelöst wird, dann könnt es der Controller genauso gut selber zählen.
Der Sinn des Zähler ist doch die Entlastung des Controller, daher wäre es doch wesentlich besser wenn nur beim Zählerüberlauf ein Interrupt ausgelöst würde. Oder sehe ich das falsch?

Gruß Frank

[André H.]

Hallo Frank,

Hier ist keinerlei Denkfehler.
Ich kenne mich mit dem I²C-Bus bestens aus. (Hardware & Software)
Man muß einfach einmal von der Denkweise, daß ein Interrupt sofort abgearbeitet werden muß, wegkommen.
Ein Interrupt ist im Bereich vom I²C-Bus nur dazu da, eine Änderung zu signalisieren.
Ein Interrupt von I²C-Bus-Bausteinen muß nie an einen Interrupt-Eingang eines Controllers.
Vielmehr muß dieser an einen normalen I/O-Port und dient nur dazu
zu signalisieren, ob sich ein I²C-Bus-Zugriff "lohnt", um unnötiges Polling zu vermeiden.
Das ist vielleich bei der CC1 nicht schlimm, da diese ohnehin langsam ist,
und man hier nicht viel mit dem I²C-Bus macht.
Aber bei der CC2 würde man dies bei komplexeren Anwendungen deutlich merken.
Meine Hardware ist nunmal in erster Linie für die CC2 entwickelt.
Daß die meiste Hardware auch mit der CC1 nutzbar ist, ist ein angenehmer Nebeneffekt. :-)

Und um das als Programmcode zu verdeutlichen:
(Kleine Testfunktion in C2.)

byte lcnt[16];//Zwischenspeichern des letzten Zählerwerts
const AddrR[]=0x41,0x43,0x45,0x47,0x49,0x4B,0x4D,0x4F,
              0x71,0x73,0x75,0x77,0x79,0x7B,0x7D,0x7F;
function getCnt(byte addr, byte IntPort) returns byte
{byte x,y;
 if not ports.get(IntPort) // wenn Int-Port auf low
  {
   if i2c.cstart(AddrR[addr])
    {
     x=i2c.readlast();
     i2c.stop();
     y=x-lcnt[addr];
     lcnt[addr]=x;
     return y;
    }
   i2c.stop();
  }
 return 0;
}

Viele meiner (I²C-)Erweiterungen haben Interruptausgänge.
Ohne diese würde der I²C-Bus schnell "überlastet" und damit langsam.

MfG André H.

[Frank]

Hallo André
Ich dachte der Interrupt gibt nur einen Impuls weiter, war das nicht so beim PCF?
Was nützt einem der Impuls auf einem normalen Port? Um den zu registrieren müsste ja ständig der Port überwacht werden?

Oder setzt PCF die Leitung dauerhaft auf Low? Wenn ja wie wird die zurückgesetzt?

Gruß Frank

[Kjion]

Ich glaube bei PCF zeigt der Interrupt nur an, dass sich etwas verändert hat. Die Leitung bleibt dabei dann dauerhaft auf low bis man den Baustein wieder abgefragt hat.
Das heißt man müsste halt nur immer mal wieder schauen ob die Leitung auf Low liegt und in dem Fall den PCF abfragen...

MfG Kjion

[Frank]

Hi
Das könnte sein, dann würde es Sinn machen wie es Andé beschrieben hat. Allerdings würde es meiner Meinung den I2C Port als auch den Controller noch wesentlich mehr entlasten, wenn der Überlauf des Zählers einen echten Interrupt auslöst. Dies würde auch einen nahezu fehlerfreie Zählung sichern - was bei langsamen Controllern ansonsten nicht 100% sicher ist.

Gruß Frank

[André H.]

Hallo Frank,

Kjion hat die Funktion eines Interruptausgangs bereits richtig beschrieben.

Um einmal allgemein die Funktion von Interrupts, egal ob diese von I²C-Bus-ICs,
FIFO-Bausteinen oder was auch immer kommen, zu beschreiben:
Ein Interrupt bleibt immer solange bestehen, bis dieser zurückgesetzt wird.
Bei I²C-Bus-Portexpandern, wie den PCF8574 oder MAX7311, geschiet
das durch ein Ansprechen (Adressieren) des Bausteins.

Bei I²C-Bus-Portexpander geht die Interruptleitung auf low, sobald sich
der Pegel an mind. einem der Ports ändert.

Und, um zum Interrupt bei Überlauf zu kommen:
Was soll das für einen Sinn machen ?
1. Wenn es zu einem Überlauf kommt, ist es bei "normalen" Zählern
meist schon zu spät, und man "verliert" Impulse.
2. Da bei I2C-CNT8 der Zähler beim Abfragen nicht zurückgesetzt wird,
mach es hier noch weniger Sinn.
3. Man benötigt den Zählerwert sicher nicht nur, wenn dieser überläuft. :-)

Man muß bedenken, wenn man einen Zähler zurücksetzen würde,
welcher passiv funzt, wie der I2C-CNT8, läuft man gefahr Impulse zu verlieren, da man zum Zürücksetzen über den I²C-Bus wieder Zeit benötigen würde.
Einen Aktiven Zähler am I²C-Bus wollte ich nicht erstellen. Da hier der
benötigte PIC-Controller um einiges teuere kommen würde.
Das ding müsste schließlich auch programmiert werden, was sich natürlich
auch wieder am Preis bemerkbar macht.

Übrigens ist beim I²C-Bus die Interruptleitung so vorgesehen, daß man
mehrere Bausteine an eine Interruptleitung hängt.
Geht die Leitung auf Low, fragt man alle Bausteine ab solange der Interrupt besteht:
Bsp: 5 PCF8574:

for i=0 ... 4
{
states[i]=pcf.in(i);
if port.get(IntPort) break; //wenn Interrupt beendet, Schleife verlassen.
}

@alle
Und zum I²C-Bus selbst:
Bitte nennt den I²C-Bus bitte auch I²C-Bus.
Es ist ein Bus, kein "I²C-Port" und auch keine "I²C-Schnittstelle".


MfG André H.

[Frank]

Hallo Frank,
Und, um zum Interrupt bei Überlauf zu kommen:
Was soll das für einen Sinn machen ?
1. Wenn es zu einem Überlauf kommt, ist es bei "normalen" Zählern
meist schon zu spät, und man "verliert" Impulse.
2. Da bei I2C-CNT8 der Zähler beim Abfragen nicht zurückgesetzt wird,
mach es hier noch weniger Sinn.
3. Man benötigt den Zählerwert sicher nicht nur, wenn dieser überläuft.

Hi André,

der Sinn ist ganz einfach. Der Controller wird nur dann informiert wenn es höchste Zeit wird den Zähler mal zu checken, ansonsten wird er enorm entlastet dadurch.
Natürlich müsste der Überlauf auch gleichzeitig den Zähler zurücksetzen - das ist ja kein echtes Hardware Problem
Da ein echter Interrupt auslöst wird, vergehen bis zur Abfrag nu wirklich keine Zeitspannen, somit dürfte selbst der langsamste Controller keine Schritte verlieren. Und selbst wenn er tatsächlich zu spät abfragen würde, dann würde er ja automatisch die Schritte lesen die bereits vergangen sind seit dem Interrupt, denn der Zähle rhat sich ja zurück gestellt. Da der Controller ja weiss das ein Überlauf entstanden ist, kann er die Konstante addieren.
Natürlich will man nicht nur beim Überlauf Werte haben, es spricht ja auch nichts dagegen das der Controller zwischenzeitlich den Zähler abfragt. Siehst Du den Vorteil

Bei deiner Konzeption hat der Controller ne Menge Arbeit wenn er bei dem Interrupt auf einem Port (der bei jedem Minibewegung/Impuls) ankommt erst mal alle I2C Bausteine lesen muss.

Gruß Frank

[André H.]

Hallo Frank,

Man kann natürlich in ein Zählermodul noch dies und das an HW reinpacken,
um alle möglichen Eventualitäten zu ermöglichen.
Jedoch ging es mir bei dem Zähler nur um ein einfaches
preiswertes Modul.

Außerdem ist die Hardware (damit meine ich den Stapel Platinen) schon
länger fertig.(ca. 2 Monate) Ich war vor lauter Arbeit nur noch nicht gekommen
die nötigen Treiber (CC2) bzw. Routinen(CC1) zu schreiben.
Es bringt jetzt nichts zu schreiben, dies oder das wäre besser.

Die Interruptleitung beim I2C-CNT8 ist nunmal nicht dazu gedacht,
Interrupts auszulösen, sondern, wie gesagt, um eine Änderung zu signalisieren.

Außerdem dauert der I²C-Bus-Zugriff selbst bei der CC1 nicht länger als
das Lesen von zwei Programmbytes aus dem EEProm.
Und wenn Dein CC1-Proggie z.B. für einen Durchlauf 1sek. braucht, und Du
in dieser 1sek. einmal auf neue Impulse prüfst und ggf. abfragst, so wären
max. 255 Hz drin ohne garantiert auch nur einen Impuls zu verlieren.

Da ich aber schon lange nicht mehr mit der CC1, sondern nurnoch mit
der CC2 arbeite, ist für mich das Thema "Controllerauslastung" nicht
so wichtig.
Wie schonmal gesagt, ist meine komplette I²C-Bus-Hardware in erster
Linie für die CC2 enbtwickelt. (Hauptbreich Wäremtechnik/Hausautomatisation)

Bei deiner Konzeption hat der Controller ne Menge Arbeit wenn er bei dem Interrupt auf einem Port (der bei jedem Minibewegung/Impuls) ankommt erst mal alle I2C Bausteine lesen muss.

Das hab' ich nie so geschrieben.
Das Beispiel, was ich gebracht habe, fragt nur solange ab, bis der
Interruptauslösende Baustein abgefragt wurde. Danach wird
die Schleife verlassen.
Gut, im schlimmsten Fall werden alle Bausteine abgefragt, aber das
ließe sich nur mit mehreren Ports für die Interruptleitungen vermeiden.

Aber ich glaub', ich weiß, wo das Problem liegt:
Viele CC1 Nutzer Emulieren völlig unnötig einen I²C-Bus an zwei
I/Os mit Basic-Routinen.
Ich halte das für völligen Unsinn und nutze bei den CC1-Routinen
für meine I²C-Bus-Erweiterungen immer den internen I²C-Bus
mit ASM-Treibern. Hier spielen I²C-Buszugriffe bei der CC1 dann
zeittechnisch eher eine untergeordnete Rolle.

Wenn bei der CC1 schon ein I²C-Bus an zwei I/Os emuliert wird, dann
bitte wenigstens mit ASM-Routinen. Alles andere wäre schwachsinn.
Ein (ASM-)Beispiel hierfür befindet sich z.B. im Buch "MSR mit CC-Basic"

MfG André H.

[Frank]

Hi André,

schön das Du doch indirekt zu gibst das meine Idee nicht ganz schlecht ist
Ich verstehe nicht was Du mit Aufwand meinst. Auch bei meiner Lösung bräuchte man nix weiter, vielleicht ein Gatter oder so!
Die einzigen Änderungen wären ja:
- der Überlauf müsste nur Zähler zurücksetzen (glaube da reicht ne Drahtbrücke)
- der Interrupt müsste auf echten Interrupt Eingang geführt werden (da dieser glaub eh nur auf Flanken reagiert braucht man garnichts ändern)

Wäre also wirklich nur "eine winzige Änderung für den Menschen aber ein großer Schritt für den Controller".

Aber ok, wenn Platinen nun mal fertig sind, kann man nix machen. Notfalls kann man das sogar noch mit manuell mit einer Brücke ändern - falls es jemand möchte.
Meine Methode entlastet ja auch den I2C-Port, von daher hat das auch schon Vorteil für schnelle Controller.

[André H.]

Hallo Frank,

>Die einzigen Änderungen wären ja:
> - der Überlauf müsste nur Zähler zurücksetzen (glaube da reicht ne Drahtbrücke)

Warum willst Du den Zähler bei einem Überlauf zurücksetzen, wenn
dieser sowieso wieder bei 0 anfängt ??
Wenn, dann müsstest Du den Interrupt mit einem I/O-Port zurücksetzen !

> - der Interrupt müsste auf echten Interrupt Eingang geführt werden (da dieser glaub eh nur auf Flanken reagiert braucht man garnichts ändern)

Müsste man schon, da der Interrupt vom PCF8574 kommt, und dieser
bei jeder Änderung der Eingänge ausgelöst wird.

Jedoch garantiere ich Dir, daß Du garantiert Impulse verlierst, wenn nur
die Überläufe erfasst werden.

Ein I²C-Bus Zugriff(Zählerabfrage) dauert hier
mit CC1 + ASM-Routine ca. 20ms
mit CC2 in C2 ca. 0,6 bis 0,7ms
C164CI mit 20MHz in ASM. ca. 0,2ms


> Meine Methode entlastet ja auch den I2C-Port, von daher hat das auch schon Vorteil für schnelle Controller.

1. Es gibt keinen "I2C-Port", sondern nur einen I²C-Bus.
2. Hab ich schonmal geschrieben, daß der I²C-Bus mit mind. 100kHz funzt ?


Das einzigste, was man machen könnte, wäre, wenn man entweder ein 9. Zählerbit einem Port zuführt und den Pegelwechsel überwacht oder
das 8. Zählerbit zusätzlich an einem Interrupt-Port zuführt.
An diesem Int-Port dürfte dann aber keine weitere Interruptquelle.
Den Int-Ausgang des PCF8574 würde man dann nichtmehr nutzen.

Ziel beim I²C-Bus ist es jedoch möglichst mit einer Interruptleitung für
die gesamte Peripherie auszukommen.
In der Robotik wird wahrscheinlich der I²C-Bus kaum verwendet, außer
höchstens einmal einen SD20 oder einen PCF8574 als Ausgangserweiterung anzuschließen.
Hier ist das Thema I²C-Bus-Interrupts sicher nicht wichtig.

Da, wie gesagt, meine Hardware für den Schwerpunkt Gebäudetechnik
entwickelt ist, ist es hier auch wichtig jede Veränderung zu erfassen.
Als Anwendungsbeispiel für das I2C-CNT8 sei hier z.B. ein Volumenstromgeber genannt, welcher Impulse höchtens mit ein paar Hz
ausgibt, wobei es jedoch z.B. bei Wärmemengenzählung wichtig ist,
die Zeitspannen etwas genauer zu erfassen, als nur bei einem Überlauf.
In der Gebäudetechnik können schnell einmal 20 bis 30 I²C-Bus-Baugruppen
an einem Bus hängen. (oder gar mehr)
(Auch eine oder mehrere RS232 am I²C-Bus, welche bei jedem empfangenen Byte einen Interrupt auslösen müssen !)

MfG André H.