[ERLEDIGT] Ewiges Thema Timer und PWM

Ewiges Thema Timer und PWM

Hallo zusammen,

ich arbeite mich weiter mit Hilfe eine PIC 18F458 Entwicklungsboard in
die µC Thematik ein und bin jetz dabei ein 50 kHZ PWM Signal für einen
PWM Modulator zu erstellen. Es gibt da viel Möglichkeiten und ich habe
jetzt mal 2 realisiert.

Einmal über die SETUP_CCP Funktion und einmal über einen Timer
Interrupt. Das funktioniert soweit, nur bei der Methode mit dem
Interrupt erhalte ich nicht die berechnete Frequenz. Ich habe wie immer
schon in diesem Forum und bei Tante Google gesucht aber nichts gefunden
was mir weiter hilft.

Code:

#include <18f458.h> #device ICD=TRUE #fuses HS,NOLVP,NOWDT,PUT #use delay(clock=20000000) void init_timers() { SETUP_TIMER_1(T1_INTERNAL); SET_TIMER1(65436); SETUP_CCP1(CCP_PWM); setup_timer_2(T2_DIV_BY_4, 24, 1); set_pwm1_duty(1); } #INT_TIMER1 void timer0_isr() { SET_TIMER1(65436); //Einstellen der gewünschten Frequenz output_high(PIN_D1); //Einstellen des gewünschten Pulsbreite output_high(PIN_D1); output_high(PIN_D1); output_low(PIN_D1); } void main() { setup_timer_1(T1_DISABLED); setup_timer_2(T2_DISABLED,0,1); SET_TRIS_D( 0x50 ); SET_TRIS_C( 0x00 ); init_timers() ; enable_interrupts(INT_TIMER1); enable_interrupts(GLOBAL); While(True); }

Nach meinen Berechnungen müsste 20Mhz/4 => 0,2µs Tick ergeben. 50 kHz
entsprechen 0,02 ms und somit ergeben sich 0,02ms/0,2µs = 100 Ticks.

Somit muss ich rechnerisch den Zähler des Interrupts auf 65536-100 =
65436 einstellen um die gewünschte Frequenz zu erhalten, damit ergeben
sich leider nicht 50 kHz sondern 33.79kHz.

Ich muss den Wert auf 65484 einstellen um 50 kHz zu erhalten, ich kann
den Fehler in meiner Berechnung nicht finden?!

Kann mir jemand sagen was ich falsch mache oder falsch annehme/
verstanden habe?

Zitat:

Zitat von GeoMan

Kann mir jemand sagen was ich falsch mache oder falsch annehme/
verstanden habe?

Erstmal, Code liest sich viel leichter, wenn man ihn auch als Code postet. Du solltest auch angeben, wo du z.B. die Funktion SETUP_TIMER_1(T1_INTERNAL) herhast, ich kenne sie nicht.

Aber ich denke, dein Problem lässt sich auch so lösen. Der Interrupt wird ausgelöst, wenn der Timer abgelaufen ist. Dann dauert es aber noch eine nicht genau definierte Zeit, bis in deinem Interrupthandler der Timer neu gesetzt wird. Der Prozessor führt erstmal den laufenden Befehl zuende aus, dann braucht er etwas um dem Handler aufzurufen. Dann muß er alle möglichen Zustände sichern damit er sie am Ende des Handlers wiederherstellen kann. Und erst dann fängt er an, deine Code im Handler abzuarbeiten. Inzwischen ist schon etwas Zeit vergangen und damit stimmt deine Rechnung nicht mehr. Deine 100 Ticks für einen Zyklus entsprechen knapp 100 Befehlen, das ist sehr wenig. Für eine 50kHz Frequenz mit Steuerung in Software ist dein Prozessor zu langsam.

MfG Klebwax

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 :confused:

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.

Zitat:

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 :confused:

Deswgen schrieb ich: als Code formatieren. Beim Editor auf erweitert und dann Code einfügen.

Zitat:

Wie dem auch sei, die Funktion wird im CCS Compiler verwendet

Ahnte ich. Der CCs Compiler ist manchmal ein wenig am C-Standard vorbei, oder wars früher. Das kann schon mal wichtig sein.

Zitat:

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.

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.

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

Zitat:

die Formatierung stimmt aber sobald ich den Beitrag freigebe kommt Obiges heraus :confused:

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 gemacht :D

O.K. das mit dem Code habe ich jetzt verstanden und direkt umgesetzt - also das mit dem Formtieren des Codes :cool:

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 :confused:

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)

Ah jetzt verstehe ich wozu der dienen soll :Strahl , 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 sagen :) einfach 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

Zitat:

.. dass beim Interrupt der Stack gesichert und anschliessend zurück geschrieben werden muss .. erscheint mir etwas hoch ..

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

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

Hier siehst Du diesen gesamten Overhead an pushs und pops, zugehörigen Registerbewegungen und dem reti; der Jump nach "ISR( USART0.."
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:

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

Nachtrag:

Zitat:

Zitat von Doku zu m328/p, Atmel-42735B

..
When an interrupt occurs, the Global Interrupt Enable I-bit is cleared and all interrupts are disabled. The
user software can write logic one to the I-bit to enable nested interrupts.
..

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.

Zitat:

Zitat von Ceos

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.

Zitat:

Zitat von GeoMan

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 :confused:

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

Zitat:

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!

Zitat:

Das muß automatisch passieren

Tut es aber nicht!

Zitat:

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!

Zitat:

Zitat von Ceos

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.

Zitat:

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.

Zitat:

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?

Zitat:

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.

Zitat:

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.

Zitat:

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

Zitat:

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.

Zitat:

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.

Zitat:

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.

Zitat:

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.

Zitat:

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.

Zitat:

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.

Zitat:

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 :) 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 :strom

- - - Aktualisiert - - -

Zitat:

Zitat von oberallgeier

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 :cool:
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 :-k

Viel zu lernen ich noch hab ;-)