Programmablauf-/Planung mit mehreren Interrupts

[Seb (Gast)]

Hallo Zusammen,

Ich wollte mir mal den Rat von ein paar erfahrenen Programmierern 
einholen bevor ich mein erstes größeres Projekt mit mehreren Interrupts 
in Angriff nehmen. Im folgenden versuche ich mal meine (geplante, 
skizzierte) Programmübersicht darzustellen. Anschließend stelle ich die 
eine oder andere Frage. Der µC meiner Wahl ist ein MSP430F2617.



Hauptprogramm:
    while-Schleife:
       If(TimerB_flag gesetzt)
          {TimerB_Flag reset;
           Sensoren/Daten auslesen (SPI,I²C, seriell);
           Berechnungen durchführen;
           Daten ggf. auf SD_Karte(SPI);
           }
       If(Alert_flag gesetzt)Aktion;


Interrupts:

-TimerB setzt jede Sekunde kurz das TimerB_Flag (eine Zeile)

-TimerB-Intervall für Setzen eines Alive_1 Signals auf PIN(500ms, eine 
Zeile)

-TimerB-Intervall für Setzen eines Alive_2 Signals auf PIN (50ms, eine 
Zeile)

- TimerB für Abfrage eines Pins mit Zeitstempel (Überprüfung, ob PIN 
rechtzeitig bedient wurde), ggf. Setzen eines Alert_Flags (ca. alle 600 
ms, eine Zeile)

- Interrupt auf normalem Interrupt-Pin (Hochzählen einer globalen 
Variable, eine Zeile)



Nun die Fragen/Erläuterungen:

1. Ich wollte versuchen die Interrupts so klein wie möglich zu halten 
und größere "Arbeiten" in der main-Schleife zu erledigen (Übergabe von 
Flags, Hochzählen globaler Variablen).

2. Was passiert, wenn ich in der Schleife gerade meine Sensoren auslese 
(via SPI oder I²C) und just in diesem Augenblick ein Interrupt aufpoppt? 
Wird die Kommunikation genau dort fortgesetzt, wo sie unterbrochen 
wurde? Könnten dabei nicht Daten verloren gehen?

Anm.:Die Sensoren müssen alle der Reihe nach ausgelesen werden, um 
danach Berechnungen durchzuführen.


Ich hoffe mein Problem ist klar geworden und würde mich auf eine 
angeregte Diskussion freuen. Das Programm befindet sich, wie schon 
angedeutet, noch im Planungsstatus, damit ich Missverständnissen 
meinerseits einen Riegel vorschieben kann.

Gruß
Seb

[Michael U. (amiga)]

Hallo,

Seb schrieb:
> Nun die Fragen/Erläuterungen:
>
> 1. Ich wollte versuchen die Interrupts so klein wie möglich zu halten
> und größere "Arbeiten" in der main-Schleife zu erledigen (Übergabe von
> Flags, Hochzählen globaler Variablen).
So ok und zu empfehlen. Die Größe von "so klein wie möglich" und auch 
von "größeren Arbeiten" ist kein Dogma und hängt letztlich von den 
auftretenden Zykluszeiten der Programmteile ab.
>
> 2. Was passiert, wenn ich in der Schleife gerade meine Sensoren auslese
> (via SPI oder I²C) und just in diesem Augenblick ein Interrupt aufpoppt?
> Wird die Kommunikation genau dort fortgesetzt, wo sie unterbrochen
> wurde? Könnten dabei nicht Daten verloren gehen?

I2C und SPI werden vom Mastertakt gesteuert, wenn also Dein Prozesor der 
Master ist, stören IRQ-Routinen erstmal nicht.
Ansonsten mußt Du eben während Sachen erledigt werden, die aus 
Timinggründen nicht gestört werden dürfen, die Interrupts für diese Zeit 
sperren.
Gilt dann eben im Prinzip das Gleiche: die Zeiten so kurz wie unbedingt 
nötig, in denen Du die IRQ sperrst.

Gruß aus Berlin
Michael

[Seb (Gast)]

Hi Michael,


Danke für deinen Input. Habe mir auch schon überlegt an kritischen 
Stellen die Interrupts kurz auszuschalten.

Witzig: Bin ab morgen auch für das WE in Berlin. Freue mich schon 
endlich wieder auf eine Stippvisite vorbeizuschauen.

[Weingut P. (weinbauer)]

Michael U. schrieb:
> I2C und SPI werden vom Mastertakt gesteuert, wenn also Dein Prozesor der
> Master ist, stören IRQ-Routinen erstmal nicht.

jaein würd ich da sagen. Wenn Du die Hardware-I2C und Hardware-SPI 
verwendest
gibts bestimmt keine Probleme, weil wärend Dein Programm in der ISR ist 
die Hardware weiter läuft ... eleganterweise wäre SPI und I2C auch 
wiederum interruptbasierend sprich transmission complete int für die 
Schnittstellen, dann brauchts da kein Wartezyklus.

Wenn Soft-I2C oder SPI verwendet wird kanns zu Timingproblemen kommen. 
hatte schonmal n Baustein, der bei Wartezeit von n paar Millisekunden 
ohne CLK nur noch Nullen ausgab.

[Seb (Gast)]

Japp, elegant wäre es wohl das auch noch in Interrupts ablaufen zu 
lassen. Für I²C mache ich das z.B. Die SPI-Kommunikation fragt bisher 
brav das Interrupt-Flag in einer Schleife ab (s.u.). Sofern das erstmal 
keine Probleme gibt, würde ich es dabei belassen.

Senden läuft alá:

while (!(SENSORX_UCxIFG & SENSORX_UCxxTXIFG));      // warten, bis USART0 TX-buffer sendebereit

[Peter D. (peda)]

Seb schrieb:
> Die SPI-Kommunikation fragt bisher
> brav das Interrupt-Flag in einer Schleife ab (s.u.).

Das ist der übliche Weg.
Das SPI läuft ja mit sehr schnellem Takt (XTAL/2), da ist die Wartezeit 
nur kurz.
Mit nem Interrupt würde man wesentlich mehr CPU-Zeit verpulvern durch 
die ganze in den Interrupt Rein- und Rausspringerei.


Peter