I2C interruptgesteuert?

[Sebastian (Gast)]

Hallo,

ich bin momentan an der Umsetzung eines Projekts zur Temperaturregelung 
mit einem PIC welcher über I2C einen AD Wandler abfragen soll 
(Singlemaster). Der PIC besitzt ein I2C Modul.
Nun hab ich viel über das I2C Protokoll an sich gelesen, eine Sache will 
ich aber einfach nicht verstehen:
Das I2C Modul ist in der Lage Interrupts zu allen möglichen Bus Events 
(Start Condition, Stop Condition....) zu generieren. Ich finde aber 
NIRGENDS auch nur ein winziges Beispiel zu I2C interruptgesteuert. 
Interrupts mit Polling gibt es dagegen einige.
1.Bringt es mir überhaupt was wenn ich Polling durch Interrupts ersetze?
2. Wenn ja, wie hoch ist der gesamte und "zeitliche" Nutzen?
3. Sehe ich das richtig, dass ich bei Interruptnutzung globale Variablen 
benötige?
4. Für ein Minimalbeispiel wäre ich sehr dankbar.

Gruß,
Sebastian

[... (Gast)]

Sebastian schrieb:
> Ich finde aber
> NIRGENDS auch nur ein winziges Beispiel zu I2C interruptgesteuert.

Was soll am I2C interruptgesteuert werden?

[Sebastian (Gast)]

Also das ganze läuft auf einem PIC24FJ128GA010. Dazu ein kurzer Auszug 
aus den Notes zum I2C Modul und der Interruptfähigkeit:

Zitat:

The I2C module generates two interrupts. One interrupt, MI2CxIF, is 
assigned to master events;
the other interrupt, SI2CxIF, is assigned to slave events. These 
interrupts will set a corresponding
interrupt flag bit and will interrupt the software process if the 
corresponding interrupt enable bit
is set and the corresponding interrupt priority is high enough.

The MI2CxIF interrupt is generated on completion of these master message 
events:
. Start condition
. Stop condition
. Data transfer byte transmitted/received
. Acknowledge transmit
. Repeated Start
. Detection of a bus collision event

The SI2CxIF interrupt is generated on detection of a message directed to 
the slave, including
these events:
. Detection of a valid device address (including general call)
. Request to transmit data (ACK) or to stop transmitting data (NACK)
. Reception of data

Zitat Ende.

Ich muss ehrlich sagen, ich weis nicht so recht wie ich das Nutzen soll? 
Allgemein bin ich aber der Meinung, gute Software sollte auf Polling 
möglichst verzichten (siehe Erstpost).
Gruß

[... (Gast)]

Sebastian schrieb:
> Ich muss ehrlich sagen, ich weis nicht so recht wie ich das Nutzen soll?

Ist doch alles gut. Die I2C Hardware kann beim Eintreten verschiedener 
Zustände einen Interrupt auslösen, so dass du in der Software passend 
reagieren kannst, ohne z.B. einen Slave laufend fragen zu müssen: "Hast 
du gerade eine gültige Device Adresse empfangen?".

[Sebastian (Gast)]

Aus Slave Sicht macht das durchaus Sinn aber als Master?

[Der Weise (Gast)]

Wenn man nebenher noch etwas anderes machen will? z.B. Kommunikation 
über andere Bus-Systeme oder Berechnungen?

[Simon K. (simon)]

Polling ist nicht unbedingt schlecht. Nur blockende und wartende 
Funktionen sind Mist.

[Michael H. (morph1)]

Das macht mehr als nur Sinn.

Die PIC24 können Interrupts mit Prioritäten verwalten.
Ich habe eine Library für Interrupts, welche Übertragungen 
vollautomatisch erledigt. Das funktioniert bei der niedrigsten Priorität 
und interferiert so nicht mit anderen Ints und kaum mit dem 
Hauptprogramm.

Am Ende der Übertragung wird dann ein Callback aufgerufen und die 
empfangenen Daten verarbeitet (sofern man nicht gesendet hat).

Bei kommerziellem Interesse kannst du dich gerne an mich wenden. Das ist 
Interrupt-basiert nämlich nicht so einfach und daher wird dir wohl kaum 
einer die Lösung vorkauen :)

[Klaus (Gast)]

Sebastian schrieb:
> Allgemein bin ich aber der Meinung, gute Software sollte auf Polling
> möglichst verzichten (siehe Erstpost).

Warum? Ernsthaft, solche Allgemeinplätze sind selten hilfreich. Als 
Begründung kann man dann lesen, der µC kann, statt zu pollen, etwas 
anderes machen. Nur was wird nicht gesagt. Pi auf tausend Stellen 
ausrechnen? Bei den meisten kleinen Systemen gibt es nichts zu tun. Bei 
Multitasking Systemen ist es genau anders herum, es gibt fast immer was 
zu tun.

Du willst eine Spannung/Temperatur via I2C bekommen, solange du die 
Daten nicht hast, ist der alte Wert gültig, du hast nichts besseres. 
Wenn jetzt z.B. die Ansteuerung deiner Heizung in einer HW-PWM läuft 
(also ohne dauernden Prozessoreingriff) kannst du nur auf die Daten vom 
ADC warten. Muß der Prozessor eine Soft-PWM erzeugen, dann gehört das in 
einen Interrupt.

Außerdem macht das Aufteilen sequenzieller Abläufe wie bei I2C in einen 
oder mehrere Interrupthandler einem das Leben nicht leichter. Bevor du 
also keine Vorstellung hast, was dein µC zu dieser Zeit besseres tun 
kann, als die I2C Engine zu pollen, kannst du ohne Interrupt leben.

MfG Klaus