Ewiges Thema Timer und PWM

[Klebwax]

da es nicht die einzige ISR sein wird die du später verwendest, würde ich dir noch empfehlen innerhalb der ISR das globale Itnerrupt Flag zu lsöchen und am ende wieder einzuschalten um glitches zu vermeiden wenn ein interrupt im interrupt feuert (sofern das beim pic18 möglich ist, ich kenn den chip leider nicht)

Keine gute Empfehlung. Wenn du am Ende den Interrupt wieder einschaltest ist der Interrupthandler noch lange nicht fertig. Da kann dir jetzt jeder Interrupt inklusive der, der gerade abgeschlossen wird, reinpfuschen. Der Interrupt darf nur atomar mit dem letzten Befehl wieder freigegeben werden. Daher gibt es den Assemblerbefehl "return from interrupt", den der Compiler automatisch ans Ende eine Interrupthandlers packt.

Und abschalten brauchst du ihn auch nicht. Das muß automatisch passieren. Da das jeweilige Interruptflag meißt individuell in SW gelöscht werden muß, würde sonst der Interrupt nach dem ersten Assemblerbefehl des Interrupthandlers erneut zuschlagen. Und das solange, bis der µC abstürzt. Und das gilt prinzipiell für alle Prozessoren.

Wenn ich das jetzt richtig verstanden habe ist es also so, dass beim Interrupt der Stack gesichert und anschliessend zurück geschrieben werden muss. Da ich diese Zeitdauer nicht berücksichtige stimmt meine Berechnung nicht.

So weit so gut.

An für sich ist die Zeitdauer dafür bekannt da ich den Wert ja solange angepasst habe bis die gewünschte Frequenz eingestellt wurde, also 65484 - 65436 = 48 Ticks, d.h. 48 Ticks * 0,2µs = 9,6µs. Ist das ein realistischer Wert für das Sichern und Schreiben des Stackse, erscheint mir etwas hoch

Es geht nicht wirklich um den Stack, es geht um das Sichern des ganzen Kontext der gerade laufenden Funktion. Und das kann schon dauern. Es ist auch nicht gesagt, daß es immer gleichlange dauert. Dein Ansatz ist also schlecht und, wie ich schon sagte, für dein Konzept (Interrupt mit 50kHz) ist der Prozessor zu langsam.

MfG Klebwax

[Ceos]

Keine gute Empfehlung. Wenn du am Ende den Interrupt wieder einschaltest ist der Interrupthandler noch lange nicht fertig. Da kann dir jetzt jeder Interrupt inklusive der, der gerade abgeschlossen wird, reinpfuschen. Der Interrupt darf nur atomar mit dem letzten Befehl wieder freigegeben werden. Daher gibt es den Assemblerbefehl "return from interrupt", den der Compiler automatisch ans Ende eine Interrupthandlers packt.

Das ist definitiv falsch!
Den Befehl gibt es nur bei Controllern die selbigen auch unterstützen, da fehlt dir wohl etwas Erfahrung mit Multi-Level Interrupts. Es ist Controllerabhängig weswegen ich darauf hingewiesen habe! Leider kenne ich mich mit dem PIC nicht genug aus, weswegen ich extra auf diese möglichkeit hingewiesen habe!

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!

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

Das muß automatisch passieren

Tut es aber nicht!

Da das jeweilige Interruptflag meißt individuell in SW gelöscht werden muß, würde sonst der Interrupt nach dem ersten Assemblerbefehl des Interrupthandlers erneut zuschlagen

Ich habe so langsam ernsthaft das Gefühl dass du noch keinen Cortex-M programmiert hast
Hier gibt es für bis zu 32 Interruptquellen EINEN Interrupt Vektor 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.

Sich darauf zu verlassen dass allse automatisch passiert ist gefährlich!

[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.

[GeoMan]

also bei atmegas weis ich es 100%ig, dass innerhalb der ISR das I-Flag automatisch gelöscht wird, bei XMegas wird nur das Prioritäts I-Flag gelöscht damit kein Interrupt gleicher oder niedrigerer Prio ausgeführt werden kann, ob udn wie das bei PIc ist kann cih nciht sagen einfach im kapitel interrupts nachschauen ob es automatisch das i-flag beim betreten der ISR sperrt oder nicht

Habe mir das jetzt mal genauer angeguckt, beim PIC wird automatisch ein Flag gelöscht und nach dem Ende der ISR wieder das Flag gesetzt damit der Interrupt nicht unterbrochen werden kann. Allerdings kann ab den PIC18 Typen ein mit einem höher priorisierten Interrupt einen niedrig priorisierten Interrupt unterbrechen. Der höher priorisierte Interrupt wird abegarbeitet, anschliessend zurück zum niedrig priorisierten Interrupt gesprungen, die Routine fertig bearbeitet bevor es wieder zurück ins Hauptprogramm geht. Wohlgemerkt ich programmiere alles in C.

Zusätzlich gibt es eine Otion "Fast" die verhindert, dass bei einem Interrupt der Stack gesichert und zurückgeschrieben wird. Wenn ich diese nutze erhöht sich meine Frequenz von 33 kHz zu 45 kHz.
Bestätigt nochmals die Annahme, dass die Abweichung zu den berechneten 50 kHz unter anderem daher rührt. Diese Option sollte man wohl nur nutzen wenn man genau weiss man tut

- - - Aktualisiert - - -

Hallo PICman - sorry, GeoMan.

Ich kenn mich mit den PICs nicht aus, ich programmiere Atmels in C. Aber vielleicht gibts bei PIC ähnliche Dinge. Ich bekomme z.B. mit dem Compilat noch ne so genannte LLS-Datei. In der ist eine Art Assemblerlisting mit Maschinencode, dazwischen eingefügtem C-Code und mit mancherlei organisatorischen Daten zum Compilat enthalten. Als Beispiel mal eine vollständige ISR zum USART-Empfang

...
..
.

Man kann bei den Atmels in einer ISR das Interruptbit explizit auf "erlaube Interrupts" setzen. Ich habe hin und wieder zwar nested interrupts in meinen Quellen - aber die sind schon ein heisses Eisen.

Hallo oberallgeier

Ich beschäftige mich noch nicht all zu lange mit µC aber habe schon mitbekommen, dass es da verschiedene Typen gibt und der PIC wohl nicht mehr so angesagt ist, wie zu den Zeiten als der PIC18F Typ erschienen ist
Es gibt beim PIC etwas vergeichbares, nennt sich .LST File.

Um rein zu kommen finde ich ist C schon sehr gut und einfacher als direkt mit Assembler loszulegen, daher kann ich deinen Ausführugnen - !noch! - nicht ganz folgen. Das werde ich aber wohl machen müssen wenn man ich ein tieferes Verständnis erhalten möchte bzw. um Probleme besser verstehen/ lösen zu können.

So weit bin ich -noch- nicht

Viel zu lernen ich noch hab