Hallo, nach den Angaben von Keil für das RTX-RTOS: (http://www.keil.com/support/man/docs/rlarm/rlarm_ar_inter_funct.htm ) "RTX can work with interrupt functions in parallel. However, it is better to avoid IRQ nesting. Good programming techniques use short interrupt functions that send signals or messages to RTOS tasks. With this practice, interrupt nesting becomes unimportant. This avoids common problems with nested interrupts where the user mode stack usage becomes unpredictable." kann mir jemand sagen wie es genau zu den "common problems" kommt? oder kann mir jemand sagen, wo ich mehr zu diesem thema finde? danke
sina anargo schrieb: > user mode stack usage becomes > unpredictable Steht doch direkt drin. Bei verschachtelten Interrupts kann dir ziemlich schnell der Stapel vollaufen, z.B. wenn zwei Interrupts sich ständig gegenseitig unterbrechen.
sina anargo schrieb: > kann mir jemand sagen wie es genau zu den "common problems" kommt? Timer Interrupt feuert alle 5 Millisekunden Die Bearbeitung des Interrupts im Handler dauert aber 10 Millisekunden. Und Peng.
Interruprhandler sollten generell so kurz wie möglich laufen. Wenn langwierigere Operationen notwendig sind, dann übergibt man die aktuellen Parameter an einen Thread und läßt den den Job abarbeiten.
Karl Heinz Buchegger schrieb: > sina anargo schrieb: > >> kann mir jemand sagen wie es genau zu den "common problems" kommt? > > Timer Interrupt feuert alle 5 Millisekunden > Die Bearbeitung des Interrupts im Handler dauert aber 10 Millisekunden. > > Und Peng. Das wäre dann aber ein ganz grober Bug. Ein Handler nicht aufgerufen werden, wenn er gerade abgearbeitet wird. Ich kann mir auch nicht vorstellen, wo das so nützlich sein könnte, dass man die Probleme in Kauf nehmen würde. Das hat aber nichts direkt mit verschachtelten Interrupts zu tun, abgesehen davon dass überhaupt irgendwelche Interrupts aktiviert sein müssen damit auch falsche Interrupts aktiviert sein können.
sina anargo schrieb: > unpredictable Das ist für mich die wichtigste Aussage. Die Auslastung des Stacks muss sorgfältig geplant sein. Man kann sie zwar überwachen, aber wenn der Stack überzulaufen droht, nützt das auch wenig, denn als Konsequenz könnte man nur einen IRQ nicht bedienen, was aber ein schwerer Fehler ist, oder gleich das Programm beenden. Bei IRQs die sich gegenseitig unterbrechen können ist so eine Planung garnicht möglich, man könnte nur vorsichtshalber einen Riesen-Stack vorsehen, aber auch das ohne Garantie. Ein RTOS sollte schon möglichst deterministisch bleiben. Man kann sich mit einem guten Entwicklungssystem natürlich die durchscnittliche und maximale Stackbelegung ausgeben lassen, aber nur unter Laborbedingungen. Gruss Reinhard
Die Frage ist eigentlich, ob jeder Task-Stack für die max. Interrupt-Tiefe ausgelegt sein muß. Es soll ja nicht derselbe INT mehrfach aktiv sein sondern einfach ein INT mit höherer Prio bedient werden, während eine andere ISR läuft. Brauchen beide zusammen 20 Bytes, dann muß entweder jeder Task-Stack eine 20 Byte Reserve haben oder man muß eben einen eige nen Interrupt-Stack haben. Falls schon eine andere ISR läuft, darf der Stack-Switch ausbleiben. Damit wird n-1 mal 20 Bytes gespart, n ist Anzahl Tasks. Keil's RTOS kann das offensichtlich nicht. BTW, manche Architekturen machen diesen Stack-Switch in Hardware.
Bastler schrieb: > BTW, manche Architekturen machen diesen Stack-Switch in Hardware. Wozu alle ARM Cores gehören, die klassischen und die Cortexe, damit also jene Architekturen, auf die sich der Keil Link bezieht. Allerdings tun sich die Cortex-M mit komplex verschachtelten Interrupts etwas leichter als die ARM7/9, die nativ mit IRQ/FIQ nur 2 Ebenen kennen und es darüber hinaus etwas umständlich wird. Keil hat insoweit Recht, als in einem RTOS meist wenig Notwendigkeit für komplexere und folglich verschachtelte Interrupt-Handler besteht, da komplexere ISR-Inhalte ggf. durch RTOS-Mechanismen in zwei Teile gesplittet werden können (Top/Bottom-Handler Design).
Die aber um Größenordnungen langsamer sein können, wenn ich da extra eine Task aufwecken muß, um z.B. ein Bit in einem IO-Register zu manipulieren. Das mit Keil auf ARM hatte nach meinem Post auch gesehen und frage mich, was genau das Problem ist wenn man eh einen INT-Stack hat.
Bastler schrieb: > Die aber um Größenordnungen langsamer sein können, wenn ich da extra > eine Task aufwecken muß, um z.B. ein Bit in einem IO-Register zu > manipulieren. Das würde ich aber auch nicht als komplexe ISR betrachten.
Oder um's genauer zu sagen: Mich stören solche strikten Regeln, wenn die Randbedingungen, die bei ihrer Aufstellung herrschten, im Dunkeln liegen. Unerfahrene lesen das und nehmen es für in Stein gemeißelt.
Bastler schrieb: > Fällt aber auch unter "avoid nested interrupts" Inwiefern? Wenn alle Handler kurz sind und folglich ohne Verschachtelung auskommen, dann landen nur komplexe Event-Mechanismen in Tasks und es schachtelt nichts. NB: Man kann ein Top/Bottom-Handler Verfahren auch ohne RTOS realisieren. Es läuft dann auf 2 Verschachtelungs-Ebenen hinaus, wodurch es kalkulierbar wird. In den knapp gehaltenen nicht verschachtelten Hardware-Handlern werden - wenn es sich lohnt - Software-Ints getriggert, die auf niedrigerer Ebene als die Hardware-Interrupts laufen und den komplexeren Teil der Events erledigen. Die PendSV-Feature der Cortex-M lässt sich dafür beispielsweise elegant einsetzen.
Bastler schrieb: > Unerfahrene lesen das und nehmen es für in Stein gemeißelt. Das gilt eigentlich generell für Daumenregeln. Mit wachsendem Verständnis für Abläufe und Risiken emanzipiert man sich davon. Damit sollen möglicherweise Anfänger davon abgehalten werden, das halbe Programm in ISRs abzuwickeln, die - weil zu lang - verschachtelt werden müssen. Ist ja nicht grad selten, dass ein Anfänger Millisekunden dauernde Wartschleifen in ISRs wirft. Und sich dann wundert, dass UART-Zeichen verschwinden. Und dann auf die geniale Idee von Verschachtelung kommt. NB: Der Ausdruck "good programming techniques" steht nicht unbedingt für eine strikte Regel, sondern eher für eine Empfehlung.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.