Werbung
setz einfach [ C O D E ] vor und [ / C O D E ] nach deinem code ein dann formatiert er es richtig .... natürlich ohne die leerzeichen, sonst hätte er aus meinem text code gemachtdie Formatierung stimmt aber sobald ich den Beitrag freigebe kommt Obiges heraus
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
O.K. das mit dem Code habe ich jetzt verstanden und direkt umgesetzt - also das mit dem Formtieren des Codes
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
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)
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
Ah jetzt verstehe ich wozu der dienen soll, ja sowas gibt es beim PIC18! Wenn ich das globale Interrupt Flag in der ISR disable kann ich also sicher gehen, dass dieser Interrupt bis zum Ende abgearbeitet wird ohne durch einen anderen Interrupt unterbrochen zu werden.
Ich finde hier leider keinen Like Button o.Ä. sonst hätte ich den schon mehrmals gedrückt!
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 sageneinfach im kapitel interrupts nachschauen ob es automatisch das i-flag beim betreten der ISR sperrt oder nicht
generell PWM auf diese art zu machen würde ich aber vermeiden, ich würde wohl eher hingehen den timer mit dem PRx register vorladen und downcounten lassen bis 0 und dann im ISR die bits bedienen, während der timer sich automatisch auf den im PRx Register gesetzten wert zurücksetzt und dann wieder munter runterzählt bis 0, so hast du einen 100%ig exakt feuernden interrupt und maximal einen statischen offset aber immer gleiche frequenz
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
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.Zitat von Ceos
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
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 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
Geändert von GeoMan (15.11.2017 um 11:32 Uhr)
Hallo PICman - sorry, GeoMan... dass beim Interrupt der Stack gesichert und anschliessend zurück geschrieben werden muss .. erscheint mir etwas hoch ..
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
Hier siehst Du diesen gesamten Overhead an pushs und pops, zugehörigen Registerbewegungen und dem reti; der Jump nach "ISR( USART0.."Code:ISR( USART0_RX_vect ) { 148: 1f 92 push r1 14a: 0f 92 push r0 14c: 0f b6 in r0, 0x3f ; 63 14e: 0f 92 push r0 150: 0b b6 in r0, 0x3b ; 59 152: 0f 92 push r0 154: 11 24 eor r1, r1 156: 8f 93 push r24 158: 9f 93 push r25 15a: ef 93 push r30 15c: ff 93 push r31 u8 i = rx_in; 15e: 90 91 20 0f lds r25, 0x0F20 ROLLOVER( i, RX0_SIZE ); 162: 9f 5f subi r25, 0xFF ; 255 164: 97 fd sbrc r25, 7 166: 90 e0 ldi r25, 0x00 ; 0 if( i == rx_out ){ // buffer overflow 168: 80 91 21 0f lds r24, 0x0F21 16c: 98 17 cp r25, r24 16e: 31 f4 brne .+12 ; 0x17c <__vector_20+0x34> URX0_IEN = 0; // disable RX interrupt 170: 80 91 c1 00 lds r24, 0x00C1 174: 8f 77 andi r24, 0x7F ; 127 176: 80 93 c1 00 sts 0x00C1, r24 17a: 0a c0 rjmp .+20 ; 0x190 <__vector_20+0x48> return; } rx_buff[rx_in] = UDR0; 17c: e0 91 20 0f lds r30, 0x0F20 180: f0 e0 ldi r31, 0x00 ; 0 182: 80 91 c6 00 lds r24, 0x00C6 186: e0 56 subi r30, 0x60 ; 96 188: f1 4f sbci r31, 0xF1 ; 241 18a: 80 83 st Z, r24 rx_in = i; 18c: 90 93 20 0f sts 0x0F20, r25 } 190: ff 91 pop r31 192: ef 91 pop r30 194: 9f 91 pop r25 196: 8f 91 pop r24 198: 0f 90 pop r0 19a: 0b be out 0x3b, r0 ; 59 19c: 0f 90 pop r0 19e: 0f be out 0x3f, r0 ; 63 1a0: 0f 90 pop r0 1a2: 1f 90 pop r1 1a4: 18 95 reti
50:...0c 94 a4 00.....jmp.....0x148.....; 0x148 <__vector_20>
ist hier aber noch NICHT erfasst. Aus den entsprechenden Befehlen und dem Datenblatt des Controllers kann man nun (bei Atmel und GCC) den tatsächlichen Zeitbedarf in Einheiten der CPUclocks (siehe unten: #Clocks) genau ausrechnen:
Nachtrag:Code:DATA TRANSFER INSTRUCTIONS Mnemonics Operands Description .............. Operation .. Flags .. #Clocks ... PUSH .... Rr ..... Push Register on Stack ... STACK ← Rr . None .... 2 POP ..... Rd ..... Pop Register from Stack .. Rd ← STACK . None .... 2 RETI ..............Interrupt Return ......... PC ← STACK .. I ...... 4
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.
Geändert von oberallgeier (14.11.2017 um 13:05 Uhr) Grund: noch etwas zu (nested) Interrupts
Ciao sagt der JoeamBerg
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.
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.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
MfG Klebwax
Strom fließt auch durch krumme Drähte !
Das ist definitiv falsch!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.
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!
Tut es aber nicht!Das muß automatisch passieren
Ich habe so langsam ernsthaft das Gefühl dass du noch keinen Cortex-M programmiert hastDa 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
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!
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
Richtig, aber außreichend PICs und andere Prozessoren, um zu den PICs etwas sagen zu können.Ich habe so langsam ernsthaft das Gefühl dass du noch keinen Cortex-M programmiert hast
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.Hier gibt es für bis zu 32 Interruptquellen EINEN Interrupt Vektor
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?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.
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.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!
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.Also nochmal der Hinweis, Datenblatt lesen und sicherstellen wie die ISRs geschrieben werden müssen damit keine anderen Interrupts dazwischen funken!
Ich habe so langsam ernsthaft das Gefühl dass du außer deinem Cortex-M noch keinen anderen Baustein programmiert hastIch habe so langsam ernsthaft das Gefühl dass du noch keinen Cortex-M 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
Strom fließt auch durch krumme Drähte !
Berechtigungen
Zitieren
Lesezeichen