Ewiges Thema Timer und PWM

[Klebwax]

Ich habe so langsam ernsthaft das Gefühl dass du noch keinen Cortex-M programmiert hast

Richtig, aber außreichend PICs und andere Prozessoren, um zu den PICs etwas sagen zu können.

Hier gibt es für bis zu 32 Interruptquellen EINEN Interrupt Vektor

Das ist ja fast so verkrüppelt wie bei den alten PICs, EINEN Vektor für viele Interrupte. Die kleinen PIC haben auch nur einen, größere bis zu 100 Vektoren, da muß man im Handler nicht erst den Interruptverursacher suchen. Das hat aber mit der Frage hier nichts zu tun.

und du musst sogar laut Datenblatt/Manual explizit das Flag mit der ERSTEN OPERATION IM HANDLER löschen damit der Interrupt eben nciht zwei mal feuert.

Der TO programmiert einen PIC und den in C und hat das Problem, daß ihm der Compiler an den Anfang seines Handler ca. 40 Befehle schreibt. Wie soll er um himmelswillen in seinem Code da etwas vor diesen Prolog bekommen?

Außerdem, was sollte denn da bitte dazwischen pfuschen??? Ich bin innerhalb der ausgeführten ISR fertig mit allen arbeiten und schalte dann das I-Flag wieder ein, ob da ein wartendert ISR feuert oder nciht ist mir dann herzlichst egal!

Nochmal, es geht hier um C. Und da bist du nicht fertig, der Compiler packt dir noch eine Menge Code rein, um den alten Kontext wiederherzustellen. Und wenn zu diesem Zeitpunkt die Interrupte enabled sind (oder wenn du von Multilevel sprichst die Priority auf auf den Wert von main() gesetzt wird), kann jeder Interrupt dazwischen kommen. Damit hast du dann einen Interrupt im Interrupt, der den Kontext sichert. Das kann solange passieren, bis der gesamte Stack aufgebraucht ist.

Also nochmal der Hinweis, Datenblatt lesen und sicherstellen wie die ISRs geschrieben werden müssen damit keine anderen Interrupts dazwischen funken!

Als allgemeiner Ratschlag sicher richtig, ab man kann davon ausgehen, daß der C-Compiler schon mal funktionierenden Interruptcode erzeugt. Und daß man in C keinen Code schreiben kann, der am Anfang des Handlers also vor dem Retten der Register oder am Ende also nach dem Wiederherstellen ausgeführt wird, ist auch klar. Sollte der Prozessor etwas als ersten Befehl im Handler benötigen, muß das der Compiler das als Teil des Prologs erzeugen.

Ich habe so langsam ernsthaft das Gefühl dass du noch keinen Cortex-M programmiert hast

Ich habe so langsam ernsthaft das Gefühl dass du außer deinem Cortex-M noch keinen anderen Baustein programmiert hast

Nochmal zusammengefasst: wenn der TO in seinem Interrupthandler explizit die Interrupte wieder enabled, selbst wenn es der letzte C-Befehl in seinem Code ist, wird er Probleme bekommen, insbesondere wenn er in seinem System mehrere Interuptquellen hat. Und ob er die einzelnen Interruptenable-Bits im Handler setzt oder löscht, spielt nur im Zusammenhang mit den Interruptflags eine Rolle. Solange die Interrupte aber nicht generell enabled sind, ist das unkritisch.

MfG Klebwax

[Ceos]

Das ist ja fast so verkrüppelt wie bei den alten PICs, EINEN Vektor für viele Interrupte. Die kleinen PIC haben auch nur einen, größere bis zu 100 Vektoren, da muß man im Handler nicht erst den Interruptverursacher suchen. Das hat aber mit der Frage hier nichts zu tun.

deine Aussage zu meiner Warnung war aber allgemein formuliert und allgemein gesprochen ist sie defintiv falsch.

Der TO programmiert einen PIC und den in C und hat das Problem, daß ihm der Compiler an den Anfang seines Handler ca. 40 Befehle schreibt. Wie soll er um himmelswillen in seinem Code da etwas vor diesen Prolog bekommen?

wo habe ich gesagt dass er etwas VOR dem prolog schreiben soll? Das war ebenfalls nur ein reales Beispiel von mir gewählt, denn der Prozessor den ich da als Beispiel genommen habe führt zwar den Prolog Atomar aus, gewährt einem aber einige Zyklen "Atomariät" um eben genau dieses Bit löschen zu können bevor es erneut feuert ... man sollte jemanden der nach Auskunft fragt zwar immer eine direkte Lösung geben aber auch ein wenig dabei über den Tellerrand hinausgucken, sonst frisst man sich an Details fest die durch zu spezifisches Grundwissen entstehen.

Nochmal, es geht hier um C. Und da bist du nicht fertig, der Compiler packt dir noch eine Menge Code rein, um den alten Kontext wiederherzustellen

ich wiederhole mich auch hier gerne für dich erneut, WENN der controller es vom grundsatz her erlaubt einen Interrupt im Interrupt zu feuern macht es sinn die globalen Interrupts zu blockieren solange man eine Zeitkritische Aufgabe ausführt (in dem Falle die Beinchen zu toggeln) und dann mus man das I-Flag auch wiederherstellen, das ist dann nur logisch.

ab man kann davon ausgehen, daß der C-Compiler schon mal funktionierenden Interruptcode erzeugt

Und cih sage dir hiermit dass diese allgmein gehaltene Aussgae falsch ist, es ist schlciht Controllerabhängig und verallgemeinerungen sind da gefährlich.

Sollte der Prozessor etwas als ersten Befehl im Handler benötigen, muß das der Compiler das als Teil des Prologs erzeugen

Wie gesagt, nein, falsch, Controllerabhängig.

Ich habe so langsam ernsthaft das Gefühl dass du außer deinem Cortex-M noch keinen anderen Baustein programmiert hast

ATMega, ATTiny, ATXMega, diverses STMs, MSP, ADuC und seit neuestem diverse Cortex-M von unterschiedlichen Herstellern weil wir auf den Cortex Zug aufspringen wollen, aber die Performance über den AHB Bus mit seinen Sync-Flags ist grausig.