Danke für die Antwort Klebwax. Der Code liest sich tatsächlich so nicht einfach, die Formatierung stimmt aber sobald ich den Beitrag freigebe kommt Obiges heraus
Wie dem auch sei, die Funktion wird im CCS Compiler verwendet ununabhängig davon kann ich deinen Ausführungen soweit folgen. Dann muss ich jetzt nur zusehen wie ich die
Zeit am besten messe die für die Abarbeitung etc. benötigt wird und dann bei der Berechnung mit berücksichtigen.
Deswgen schrieb ich: als Code formatieren. Beim Editor auf erweitert und dann Code einfügen.Zitat von GeoMan
Danke für die Antwort Klebwax. Der Code liest sich tatsächlich so nicht einfach, die Formatierung stimmt aber sobald ich den Beitrag freigebe kommt Obiges heraus
Ahnte ich. Der CCs Compiler ist manchmal ein wenig am C-Standard vorbei, oder wars früher. Das kann schon mal wichtig sein.Wie dem auch sei, die Funktion wird im CCS Compiler verwendet
Diese Zeit muß nicht konstant sein. Je nachdem, wie schlau der Compiler ist, wird er mehr oder weniger Werte retten, abhängig von deinem Code. Du müsstest also nach jeder Codeänderung neu bestimmen, wie lange die Interruptpräambel dauert. Und sobald du in der Mainloop etwas tust und dabei auch Befehle vorkommen, die zwei Zyklen dauern, geht es auch mal schneller oder langsamer. Und zu guter Letzt: 100 Befehle zwischen zwei Interrupten sind zuwenig.Dann muss ich jetzt nur zusehen wie ich die Zeit am besten messe die für die Abarbeitung etc. benötigt wird und dann bei der Berechnung mit berücksichtigen.
50kHz für eine Softpwm sind für deinen Prozessor zu schnell. Machs lansamer, benutze die eingebaute Hardware (deswegen gibts die) oder nimm einen wesentlich schnelleren Prozessor.
MfG Klebwax
Strom fließt auch durch krumme Drähte !
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.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 !
Berechtigungen
Zitieren
Lesezeichen