Hallo, ich beschäftige mich bei einem kleinen Projekt mit dem Thema Interrupts. Um erkennen zu können, ob ich offene Interruptquellen im System habe, habe ich mir ein Paket an Interrupthandlern zusammengeschrieben, welche jeden IRQ auf meiner MCU (ATmega169) abfangen und merken. Dass sich im Moment das System nach einem IRQ in einer Endlosschleife befindet, soll für meine Frage nebensächlich sein. Der angehängte Sourcecode sollte recht verständlich sein. Sobald ein IRQ auftritt, ruft die zugehörige ISR (SIGNAL(IRQ)) die einen dummyHandler mit der Interruptquelle als Parameter auf. Danach läuft das System in eine Endlosschleife und man kann sich in Ruhe den letzten IRQ mit einem Debugger anschauen. Soweit so gut. An der ganzen Sache sind mir zwei Sachen (unangenehm) aufgefallen: 1. avr-gcc meckert bei Compilieren über die an das SIGNAL()-Makro übergebenen Parameter (warning: `SIG_xxx' appears to be a misspelled signal handler) 2. Der Objektcode ist nahezu explodiert. Wenn ich o.g. Verfahren für alle Interrupts des ATmega169 einsetze, wächst der Code um ~1700Bytes: ohne isr.c: AVR Memory Usage: ----------------- Device: atmega169 Program: 462 bytes (2.8% Full) (.text + .data + .bootloader) Data: 42 bytes (4.1% Full) (.data + .bss + .noinit) mit isr.c: AVR Memory Usage: ----------------- Device: atmega169 Program: 2174 bytes (13.3% Full) (.text + .data + .bootloader) Data: 44 bytes (4.3% Full) (.data + .bss + .noinit) Ist das normal? Gibt es evtl. einen resourcenfreundlichen Weg, den ich bis jetzt noch nicht sehe? Gruß, z0ttel
Guck dir doch mal den generierten Assemblercode an. Durch den Aufruf einer Funktion in der ISR zwingst du den Compiler zu einer PUSH/POP-Orgie, da er alle Register, die gemäß ABI durch die gerufene Funktion zerstört werden dürfen, zusätzlich retten muss. Das sollte die Code-Explosion erklären. Ich weiß nicht, ob dir mit _vector_default eventuell schon geholfen wäre, allerdings gibt's glaub' ich keine Möglichkeit herauszufinden, welcher Interrupt dann zugeschlagen hat. Andererseits: wenn du nicht weißt, welcher Interrupt auftreten kann, dann sitzt das Problem eher vor der Tastatur als im Controller... Als Alternative zu den geschachtelten Funktionsaufrufen kannst du natürlich die Vektoren in einem Assemblerfile implementieren, dort eine Zahl in ein Register eintragen und danach woanders hin springen. Das ,Meckern' über die Signalnamen ist der Versuch, im Compiler Fehler in der Schreibweise der Interruptvektoren abzufangen. Die SIG_xxx-Namen werden in <avr/io.h> definiert, hast du die denn auch includet? Andernfalls wäre die Bemerkung völlig zu Recht. ;-) Die signal.h heißt übrigens <avr/signal.h>. Mit avr/ davor und in Spitzklammern.
Hi Jörg, erstmal Danke für Antworten. Zu 1) Das ISR-Modul habe ich zum debuggen während der Entwicklung geplant. Sobald der Code 'fertig' ist, fliegt es zumindest teilweise raus. Da ich allerdings recht neu beim AVR bin, habe ich bewusst das 'aufgeblasene' Design gewählt, um eben einen besseren Überblick zu behalten (für den Fall, dass sich der Controller doch mal anders verhält als erwartet). Im 'Serien'code würde dann der default-Vector vollkommen reichen, da gebe ich Dir Recht. Zu 2) Stimmt, jetzt wo Du es sagst: die io.h wird in dem Modul nicht inkludiert, deswegen die Meckerei. Nach der Änderung ist alles gut :) Zu 3) Ich habe das makefile so geändert, dass ich das avr/ nicht mehr brauche -- ist das mit den Spitzklammern Pflicht? Greetz, z0ttel
> Zu 3) Ich habe das makefile so geändert, dass ich das avr/ nicht > mehr brauche Sollte man lieber nicht machen. Dadurch wird dein Code unportabel und für andere schwerer benutzbar. > ist das mit den Spitzklammern Pflicht? Ja, die sind Pflicht. Anführungszeichen und spitze Klammern sagen dem Compiler, wo er die Datei zu suchen hat. Faustregel: Header, die man nicht selbst geschrieben hat in spitze Klammern, nur selbstgeschriebene in Anführungszeichen setzen.
Hi Chris, ok, unter den Gesichtspunkten habe ich die Angelegenheit noch nicht betrachtet -> 'old habbits die hard'. Ich gelobe hiermit Besserung ;) danke für die Aufklärung cu z0ttel
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.