INT0 und INT1 mit Atmega8 benutzen: ISR wird mit avr-gcc nicht ausgeführt

[Joschua C. (Gast)]

Hallo

Ich versuche gerade was mit meinem Atmega8 und dem avr-gcc:

Wenn an PD2 oder PD3 (Die Interrupteingänge) eine fallende Flanke kommt, 
soll eine LED an PB0 leuchten. An PD2 und PD3 sind Taster angeschlossen, 
die den Pegel beim Drücken auf low ziehen.

Folgendes funktioniert super (geklaut vom avr-Tutorial von 
Mikrocontroller.net, die beiden Zeilen, die einen Wert in PortD laden 
habe ich hinzugefügt, wollte gucken, ob das ganze auch mit Pullups an 
den Interrupteingängen läuft) Das Programm schaltet die LED in einer 
Routine an, in der anderen aus.

.include "m8def.inc"

.def temp = r16

.org 0x000
         rjmp main            ; Reset Handler
.org INT0addr
         rjmp int0_handler    ; IRQ0 Handler
.org INT1addr
         rjmp int1_handler    ; IRQ1 Handler


main:                         ; hier beginnt das Hauptprogramm

         ldi temp, LOW(RAMEND)
         out SPL, temp
         ldi temp, HIGH(RAMEND)
         out SPH, temp

         ldi temp, 0x00
         out DDRD, temp

         ldi temp, 0b00001100
         out PORTD, temp

         ldi temp, 0xFF
         out DDRB, temp

         ldi temp, (1<<ISC01) | (1<<ISC11) ; INT0 und INT1 auf fallende Flanke konfigurieren
         out MCUCR, temp

         ldi temp, (1<<INT0) | (1<<INT1) ; INT0 und INT1 aktivieren
         out GICR, temp

         sei                   ; Interrupts allgemein aktivieren

loop:    rjmp loop             ; eine leere Endlosschleife

int0_handler:
         sbi PORTB, 0
         reti

int1_handler:
         cbi PORTB, 0
         reti

Mein C-Programm läuft hingegen nicht:

#define F_CPU 3686400UL
#include <avr/io.h>
#include <avr/interrupt.h>



int main(void){
  SP=RAMEND;
  DDRD=0x00;  //PortD als Interrupteingang
  PORTD=0b00001100; //Pullups am Interrupteingang
  DDRB=0xFF;  //Port B als LED-Ausgang (LED an PB0)
  MCUCR = (1<<ISC11) | (1<<ISC01); //Flankenverhalten setzen, Int0 und Int1 bei fallender Flanke auslösen
  GICR = (1<<INT0) | (1<<INT1);  //INT0 und INT1 aktivieren


  sei();  //Interruptflag setzen

  while(1){
  }

  return 0;
}

ISR(INT0_vect){
  PORTB |= 0b00000001;
}

ISR(INT1_vect){
  PORTB |= 0b00000001;
}

Der vom Compiler erzeugte Assemblercode:

   .file  "main.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
  .section  .text.startup,"ax",@progbits
.global  main
  .type  main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
  ldi r24,lo8(95)
  ldi r25,lo8(4)
  out __SP_L__+1,r25
  out __SP_L__,r24
  out 0x11,__zero_reg__
  ldi r24,lo8(12)
  out 0x12,r24
  ldi r24,lo8(-1)
  out 0x17,r24
  ldi r24,lo8(10)
  out 0x35,r24
  ldi r24,lo8(-64)
  out 0x3b,r24
/* #APP */
 ;  17 "main.c" 1
  sei
 ;  0 "" 2
/* #NOAPP */
.L2:
  rjmp .L2
  .size  main, .-main
  .text
.global  __vector_1
  .type  __vector_1, @function
__vector_1:
  push r1
  push r0
  in r0,__SREG__
  push r0
  clr __zero_reg__
/* prologue: Signal */
/* frame size = 0 */
/* stack size = 3 */
.L__stack_usage = 3
  sbi 0x18,0
/* epilogue start */
  pop r0
  out __SREG__,r0
  pop r0
  pop r1
  reti
  .size  __vector_1, .-__vector_1
.global  __vector_2
  .type  __vector_2, @function
__vector_2:
  push r1
  push r0
  in r0,__SREG__
  push r0
  clr __zero_reg__
/* prologue: Signal */
/* frame size = 0 */
/* stack size = 3 */
.L__stack_usage = 3
  sbi 0x18,0
/* epilogue start */
  pop r0
  out __SREG__,r0
  pop r0
  pop r1
  reti
  .size  __vector_2, .-__vector_2
  .ident  "GCC: (GNU) 4.7.2"

Es leuchtet einfach nichts mit dem C-Programm. Egal was passiert.
Und noch etwas: Die Adresse des MCUCR, dessen Wert ich auch im 
C-Beispiel verändere ist 0x35. Im C-Code des Compilers taucht die 
Adresse nirgens auf. Wenn ich im Programm in der leeren while-Schleife 
den Wert von MCUCR mit LED's überprüfe, ist das Register aber wie 
gewünscht gesetzt. Wie kommt das?

Gruß
Joschua

[hp-freund (Gast)]

Joschua C. schrieb:
> ISR(INT0_vect){
>   PORTB |= 0b00000001;
> }
>
> ISR(INT1_vect){
>   PORTB |= 0b00000001;
> }

???

[STK500-Besitzer (Gast)]

mach mal den PortB zum Ausgang, wenn du ihn benutzen willst.

[Peter II (Gast)]

STK500-Besitzer schrieb:
> mach mal den PortB zum Ausgang, wenn du ihn benutzen willst.

was soll er denn da noch machen?

> DDRB=0xFF;  //Port B als LED-Ausgang (LED an PB0)

[Joschua C. (Gast)]

Um den Inhalt der ISR als Fehlerquelle auszuschließen, ab ich
PORTB |= 0b00000001;
verwendet. Eine Zeile, LED anschalten, wenn eine Routine ausgeführt 
wird. Die Zeile habe ich dann nochmal in main getestet und benutze sie 
jetzt. Das dadurch nichts um- sondern nur angeschaltet wird, ist mir 
schon klar. Ich wollte möglichst alle Fehlerquellen reduzieren und ne 
Menge Google befragen und dann hier rumheulen.

[Hululu (Gast)]

Es ist sinnvoll die verwendete Hardware zu nenen oder zu beschreiben 
(Schaltplan). Üblicherweise sind LEDs mit Low zum leuchen zu bringen.

Was mir auch merkwürdig vorkommt ist die Zuweisung an den Stack-Pointer 
am Anfang. Lösche die mal raus. Sie ist unnötig.

[Peter II (Gast)]

Hululu schrieb:
> Es ist sinnvoll die verwendete Hardware zu nenen oder zu beschreiben
> (Schaltplan). Üblicherweise sind LEDs mit Low zum leuchen zu bringen.

wenn das ASM fehlerfrei arbeitet, braucht man wohl nicht über die 
Hardware zu wissen. Es gibt nur um den Vergleich der beiden Programm auf 
der gleichen Hardware.

hp-freund hat vermutlich das Problem schon gefunden

[hp-freund (Gast)]

Wir sollten nur noch wissen ob die LED gegen GND oder VCC angeschlossen 
ist.


Joschua C. schrieb:
> Die Adresse des MCUCR, dessen Wert ich auch im
> C-Beispiel verändere ist 0x35. Im C-Code des Compilers taucht die
> Adresse nirgens auf.

  ldi r24,lo8(10)
  out 0x35,r24

[Joschua C. (Gast)]

Mmh. Das Setzen von MCUCR hab ich wohl übersehen. Danke.

Die LED ist gegen GND angeschlossen. Den Inhalt von den ISRs habe ich 
auch schon mal in die Endlosschleife geschrieben => LED hat geleuchtet.

[Joschua C. (Gast)]

Hululu schrieb:
> Es ist sinnvoll die verwendete Hardware zu nenen oder zu beschreiben
> (Schaltplan). Üblicherweise sind LEDs mit Low zum leuchen zu bringen.
>
> Was mir auch merkwürdig vorkommt ist die Zuweisung an den Stack-Pointer
> am Anfang. Lösche die mal raus. Sie ist unnötig.

Erledigt. Geht leider auch nicht.

[spess53 (Gast)]

Hi

>Was mir auch merkwürdig vorkommt ist die Zuweisung an den Stack-Pointer
>am Anfang. Lösche die mal raus. Sie ist unnötig.

Beim ATMega8 wird der Stackpointer nicht automatisch geladen. Also 
notwendig.

MfG Spess

[Peter II (Gast)]

spess53 schrieb:
> Beim ATMega8 wird der Stackpointer nicht automatisch geladen. Also
> notwendig.

das macht der Compiler, um so etas muss man sich bei C nicht kümmern.

[Joschua C. (Gast)]

spess53 schrieb:
> Beim ATMega8 wird der Stackpointer nicht automatisch geladen. Also
> notwendig.

Gut, ist wieder drin.

Und wer einen Blick auf den Schaltplan werfen möchte:
http://www.myavr.info/download/produkte/myavr_board_light/techb_schaltplan-myavr-board-light.png

ICh benutze das myAVR-Board light. Hat das ganze AVR-ASM-Tutorial von 
Mikrocontroller.net anstandslos mitgemacht.

S1 ist an PD3
S2 ist an PD2
LED3 ist an PB0 (mit Vorwiderstand natürlich)

[Peter II (Gast)]

Joschua C. schrieb:
> Gut, ist wieder drin.

machst wieder raus. Man müsste es wenn man es selber macht vor main 
machen. Denn main ist selber schon eine Funktion die etwas auf dem Stack 
ablegt.

[Hululu (Gast)]

@ Spess53

Reden wir beide vom C-Code? Ich war auch der Meinung, das der 
runtime-Code den SP lädt.

[Joschua C. (Gast)]

Peter II schrieb:
> das macht der Compiler, um so etas muss man sich bei C nicht kümmern.

Hui. Ihr antwortet immer so schnell. Schneller als ich tippen kann. 
Danke =D

http://www.rn-wissen.de/index.php/Avr-gcc#Abk.C3.BCrzungen_und_Bezeichnungen

Verstehe ich das richtig: Wenn man am Stackpointer rumfummelt, ohne den 
gcc zu informieren, werden Interrupts deaktiviert? Siehe -mno-interrupts 
unter "Maschinenspezifische Optionen für avr-gcc"

[Hululu (Gast)]

>http://www.rn-wissen.de/index.php/Avr-gcc#Abk.C3.B...

>Verstehe ich das richtig: Wenn man am Stackpointer rumfummelt, ohne den
>gcc zu informieren, werden Interrupts deaktiviert?

Wo steht das in dem von Dir verlinkten Dokument?

[Hululu (Gast)]

Also ich gebs jetzt auf, da Du andauern Deine Beiträge so änderst, das 
Deine Fragen und unsere Antworten irrelevant werden. Falls Du auf eine 
Frage antwortest, tue das nach der Frage nicht in dem Beitrag der die 
Frage erst aufgeworfen hat.

Tschüss

[Joschua C. (Gast)]

Hululu schrieb:
>>http://www.rn-wissen.de/index.php/Avr-gcc#Abk.C3.B...
>
>>Verstehe ich das richtig: Wenn man am Stackpointer rumfummelt, ohne den
>>gcc zu informieren, werden Interrupts deaktiviert?
>
> Wo steht das in dem von Dir verlinkten Dokument?

"-mno-interrupts
Ändert den Stackpointer ohne Interrupts zu deaktivieren"

Hab den falschen Abschnitt verlinkt. Tschuldigung.
Wenns nicht so wäre, bräuchte man die Option nicht, oder?

[Joschua C. (Gast)]

Jedenfalls funktionieren Funktionsaufrufe bei mir auch ohne explizierte 
Stackpointerinitialisierung.

[Stefan E. (sternst)]

Joschua C. schrieb:
> Wenns nicht so wäre, bräuchte man die Option nicht, oder?

Das bezieht sich darauf, wenn der Compiler den SP verändert. Auf deine 
manuelle Änderung hat das keinen Einfluss. Verbeis dich nicht darin, 
nimmt die Zeile einfach raus, und gut ist. Ursache deines eigentlichen 
Problems ist das höchstwahrscheinlich eh nicht.


Wenn Interrupts nicht funktionieren, obwohl eigentlich alles gut 
aussieht, dann liegt das in der Regel an Problemen im Build-Process 
(z.B. nicht für den richtigen Controller gelinkt). Also poste mal den 
kompletten Build-Output.

[Joschua C. (Gast)]

Ok, ist draußen.

avr-gcc -v -Wall -o main.hex -Os -mmcu=atmega8 main.c
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ 
--prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man 
--bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib 
--enable-shared --with-system-zlib --enable-long-long --enable-nls 
--without-included-gettext --disable-libssp --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=avr
Thread model: single
gcc version 4.7.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-o' 'main.hex' '-Os' '-mmcu=atmega8'
 /usr/lib/gcc/avr/4.7.2/cc1 -quiet -v -imultilib avr4 main.c -quiet 
-dumpbase main.c -mmcu=atmega8 -auxbase main -Os -Wall -version -o 
/tmp/ccZBXFRD.s
GNU C (GCC) version 4.7.2 (avr)
  compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 
3.1.0-p10, MPC version 0.9
warning: MPFR header version 3.1.0-p10 differs from library version 
3.1.1-p2.
GGC heuristics: --param ggc-min-expand=100 --param 
ggc-min-heapsize=131072
ignoring nonexistent directory 
"/usr/lib/gcc/avr/4.7.2/../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/avr/4.7.2/include
 /usr/lib/gcc/avr/4.7.2/include-fixed
 /usr/lib/gcc/avr/4.7.2/../../../avr/include
End of search list.
GNU C (GCC) version 4.7.2 (avr)
  compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 
3.1.0-p10, MPC version 0.9
warning: MPFR header version 3.1.0-p10 differs from library version 
3.1.1-p2.
GGC heuristics: --param ggc-min-expand=100 --param 
ggc-min-heapsize=131072
Compiler executable checksum: ffb40dd2df077290892c2489ab66a6da
COLLECT_GCC_OPTIONS='-v' '-Wall' '-o' 'main.hex' '-Os' '-mmcu=atmega8'
 /usr/lib/gcc/avr/4.7.2/../../../avr/bin/as -mmcu=atmega8 -mno-skip-bug 
-o /tmp/ccERpZf1.o /tmp/ccZBXFRD.s
COMPILER_PATH=/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/g 
cc/avr/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2 
/../../../avr/bin/
LIBRARY_PATH=/usr/lib/gcc/avr/4.7.2/avr4/:/usr/lib/gcc/avr/4.7.2/../../. 
./avr/lib/avr4/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/../../../ 
avr/lib/
COLLECT_GCC_OPTIONS='-v' '-Wall' '-o' 'main.hex' '-Os' '-mmcu=atmega8'
 /usr/lib/gcc/avr/4.7.2/collect2 -m avr4 -o main.hex 
/usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr4/crtm8.o 
-L/usr/lib/gcc/avr/4.7.2/avr4 
-L/usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr4 -L/usr/lib/gcc/avr/4.7.2 
-L/usr/lib/gcc/avr/4.7.2/../../../avr/lib /tmp/ccERpZf1.o -lgcc -lc 
-lgcc

[Stefan E. (sternst)]

Ursache deines Problems ist das hier:
> avr-gcc ... -o main.hex ...

Der Compiler produziert eine ELF-Datei. Da kommt keine fertig brennbare 
HEX-Datei raus, nur weil du der Datei eine entsprechende Endung 
verpasst. Du musst die HEX-Datei erst aus der ELF-Datei mittels objcopy 
extrahieren.

[Hululu (Gast)]

Da hat es keine Fehlermeldung gegeben, als beim Flashen versucht wurde 
eine ELF-Datei als eine Hex-Datei zu interpretieren?

[Stefan E. (sternst)]

Hululu schrieb:
> Da hat es keine Fehlermeldung gegeben, als beim Flashen versucht wurde
> eine ELF-Datei als eine Hex-Datei zu interpretieren?

Das Brenn-Programm wird die Endung ignoriert und die Datei einfach als 
binäres Image betrachtet haben. Einfacher Code funktionieren dann sogar 
meist. Da der Code aber nicht an der richtigen Adresse im Controller 
liegt, gehören Interrupts zu den Dingen, die dann garantiert nicht 
funktionieren.

[Hululu (Gast)]

>Das Brenn-Programm wird die Endung ignoriert und die Datei einfach als
>binäres Image betrachtet haben.

Das wird wohl vermutlich so sein. Ist schon klar.

Aber es geht um was anderes (Zaunpfahl heraushol): Wir wissen ja 
garnicht was für ein Brenn-Programm der TO verwendet. Warum wissen wir 
das nicht?

[Joschua C. (Gast)]

LED blinken usw. hat auch funktioniert. Ich hab mich schon gewundert, 
warum so ein popeliges Programm 3k Flash braucht? Arbeite aber gerade 
zum ersten Mal mit C und Controllern, hab da so keinen schlimmen 
Verdacht geschöpft.

Was muss ich denn mit objcopy für die Quelldatei für bfdname angeben? 
Und wieso kann ich nicht einfach gcc -c verwenden? Dann erkennt avrdude 
das Format nicht.

[Stefan E. (sternst)]

Joschua C. schrieb:
> Was muss ich denn mit objcopy für die Quelldatei für bfdname angeben?

Nichts. Eine ELF-Datei ist der "natürliche" Input für objcopy. Nur wenn 
du es mit was anderem füttern willst, musst du das näher spezifizieren.

Joschua C. schrieb:
> Und wieso kann ich nicht einfach gcc -c verwenden?

Weil da kein fertig gelinktes Programm raus kommt, sondern nur ein 
Objekt-Modul.


PS:
Du würdest dich leichter tun, wenn du einfach ein erprobtes Makefile 
verwenden würdest, z.B. eines das von MFile erzeugt wurde.

[Joschua C. (Gast)]

ICH FASS ES NICHT!!!!!
DER ROTZ LEUCHTET
SO EIN DRECK

Vielen Dank euch allen.

[Joschua C. (Gast)]

avr-objcopy -O binary main.hex main

Das hats gelöst.

Ja, makefile klingt gut. Habe ich mir bei der C-Entwicklung für Linux 
auch irgendwann gebaut. Wird halt später immer zu viel.

[Stefan E. (sternst)]

Joschua C. schrieb:
> avr-objcopy -O binary main.hex main
>
> Das hats gelöst.

Nur dass deine Namenswahl für den Compiler-Output mit main.hex immer 
noch sehr unglücklich ist.