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
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
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.
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.
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á:
1 | while (!(SENSORX_UCxIFG & SENSORX_UCxxTXIFG)); // warten, bis USART0 TX-buffer sendebereit |
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
Bitte 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.