Keine Interrupts beim Mega8

[Daniel Krups (Gast)]

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

[Daniel Krups (Gast)]

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

[johnny.m (Gast)]

> #define LED_HI_TGL {PORTC ^= 0x20;}

Was sollen den die {} und das ;?

Besser wäre

#define LED_HI_TGL PORTC ^= 0x20

[johnny.m (Gast)]

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?

[Daniel Krups (Gast)]

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

[Jörg W. (dl8dtl) (Moderator)]

> 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;}.

[johnny.m (Gast)]

@Jörg:
Naja, 'anstößig' finde ich es auch nicht. Nur ein bisschen
gewöhnungsbedürftig. Ich hab es halt anders gelernt...

[Karl heinz B. (kbucheg)]

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.

[Netzpolizei (Gast)]

Allerdings gibt's auch Fälle, in denen sie schädlich sind.

Man denke an:

if (blah)
    LED_HI_TGL;

[Jörg W. (dl8dtl) (Moderator)]

Dafür wäre die gängige Umschreibung

#define LED_HI_TGL do { PORTC ^= 0x20; } while (0)

[Daniel Krups (Gast)]

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