Hi, ich versuche eigentlich ein Projekt vom ICCAVR zu portieren, leider gelingen mir die Interrupts nicht, die Initialisierung der z.B. Timer Register müsste richtig sein, da es ja schonmal lief. Ich habe mir dann schnell das angehängte Programm zusammen geschrieben aber auch da wird der Interrupt nicht ausgelöst (entsprechende LED nicht an). Vielleicht springt ja jemandem von euch der Fehler ins Auge. Gruß Daniel
Achso.... ich bin mir auch nicht sicher ob ich alles richtig programmiere das ist nun z.B. die Prozedur: $ avr-gcc -mmcu=atmega8 -c irqtest.c $ avr-objcopy -O ihex irqtest.o irqtest.hex $ avrdude -p m8 -P /dev/parport0 -c bsd -U flash:w:irqtest.hex
> #define LED_HI_TGL {PORTC ^= 0x20;}
Was sollen den die {} und das ;?
Besser wäre
#define LED_HI_TGL PORTC ^= 0x20
Ach ja, wenn Du schon portierst und was 'zukunftsträchtiges' machen willst, dann mach am besten gleich ein Update vom WINAVR und benutze das veraltete SIGNAL nicht mehr. Schau mal ins AVR-GCC-Tutorial, wie das mittlerweile geht. Was bringt Dich eigentlich zu der Annahme, dass der Interrupt gar nicht ausgelöst wird? Geht die LED auch bei längerem Warten nicht an? Bei welcher Taktfrequenz läuft der Mega denn?
Es tut nun, lag aber am Compileraufruf ich hatte ja nur eine Datei daher durfte ich kein -c machen er hatte also nicht gelinkt... In meinem richtigen projekt werd ich mal nach dem avrobjcopy Aufruf sehen der ist noch anders. ich benutze die neuste Version unter Linux. Bin aber etwas verwirrt was nun die aktuelle Methode ist, ich dachte es wäre SIGNAL, da ich ISR nirgends in den includes gefunden habe. Aber danke für deine Antwort
> ich benutze die neuste Version unter Linux. Das wäre die avr-libc-1.4.4. Hast du die? Je nachdem, wie die jeweiligen package maintainer sind, sind Linux-Toolchains leider manchmal ziemlich ältlich. Mir ist in Erinnerung, dass der GenToo-Maintainer für die AVR-Pakete ziemlich auf Draht ist, aber gerade in RPM-Land scheint's trüb zu sein. Im Gegensatz zu Johnny finde ich nichts anstößiges an {PORTC ^= 0x20;}.
@Jörg: Naja, 'anstößig' finde ich es auch nicht. Nur ein bisschen gewöhnungsbedürftig. Ich hab es halt anders gelernt...
Die { } haben schon ihren Grund. Hab jetzt eine Weile nachgedacht, aber er fällt mir partout nicht mehr ein. Es gibt da einen Fall in dem die { } lebenswichtig sind.
Allerdings gibt's auch Fälle, in denen sie schädlich sind. Man denke an:
1 | if (blah) |
2 | LED_HI_TGL; |
Dafür wäre die gängige Umschreibung
1 | #define LED_HI_TGL do { PORTC ^= 0x20; } while (0)
|
Hi nochmal, bei meinem Testprogramm funktioniert ja nun alles, in meinem richtigen Projekt wird der Interrupt leider noch nicht ausgelöst. Vielleicht hat ja noch jemand eine Idee. so initialisiere ich Timer0: TCNT0 = T0_RELOAD; TCCR0 = 3; // Timer 0 in prescaler-mode / 64 TIMSK = 1;// enable timer0 ovl. interrupt so sieht die Interruptroutine aus: SIGNAL(SIG_OVERFLOW0) { ... .... TCNT0 = T0_RELOAD; SREG |= 0x80; // global interrupt enable LED_HI_ON; .... ... } (beides in main.c) und LED_HI leuchtet nicht. ich glaube ja fast es hat etwas mit dem Compileraufruf zu tun: avr-gcc -mmcu=atmega8 -c main.c avr-gcc -mmcu=atmega8 -c displ7seg.c avr-gcc -mmcu=atmega8 -c gps.c avr-gcc -mmcu=atmega8 -o gpstacho.elf main.o displ7seg.o gps.o avr-objcopy -O ihex gpstacho.elf gpstacho.hex avrdude -p m8 -P /dev/parport0 -c bsd -U flash:w:gpstacho.hex Gruß Daniel
Bitte 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.