Hallo, habe den Eindruck, die ISR wird niemals aufgerufen: ----------------------- ISR (USI_OVF_vect) { PORTA |= _BV(PA0); //Test-Ausgang setzen usi_complete = 1; // Copy USIDR to buffer to prevent overwrite on next transfer. usi_DR = USIDR; } ----------------------- Hab mir daraufhin die .lst Datei angeschaut, "normalerweise" gibts dort immer so eine Tabelle mit: 00000000 <__vectors>: 0: 10 c0 rjmp .+32 ; 0x22 <__ctors_end> 2: 28 c0 rjmp .+80 ; 0x54 <__bad_interrupt> ...usw. In diesem Programm fehlt diese Tabelle, statt dessen gehts gleich mit: 00000000 <__ctors_end>: 0: 10 e0 ldi r17, 0x00 ; 0 2: a0 e6 ldi r26, 0x60 ; 96 los. Ich bin vollkommen ratlos. Hat schon mal jemand so was gesehen ? Habe avr-gcc 4.1.1 & avr-libc 1.4. Grüsse rolf-harry
Hmm, dann hast du beim Linken irgendwas vermasselt. Ich habe dein Stückchen um die fehlenden Definitionen der beiden Variablen sowie um ein leeres main() ergänzt, mit
1 | avr-gcc -Os -mmcu=attiny24 -o foo.elf foo.c |
compiliert und bekomme:
1 | % avr-objdump -d foo.elf |
2 | |
3 | foo.elf: file format elf32-avr |
4 | |
5 | Disassembly of section .text: |
6 | |
7 | 00000000 <__vectors>: |
8 | 0: 10 c0 rjmp .+32 ; 0x22 <__ctors_end> |
9 | 2: 28 c0 rjmp .+80 ; 0x54 <__bad_interrupt> |
10 | 4: 27 c0 rjmp .+78 ; 0x54 <__bad_interrupt> |
11 | 6: 26 c0 rjmp .+76 ; 0x54 <__bad_interrupt> |
12 | 8: 25 c0 rjmp .+74 ; 0x54 <__bad_interrupt> |
13 | a: 24 c0 rjmp .+72 ; 0x54 <__bad_interrupt> |
14 | c: 23 c0 rjmp .+70 ; 0x54 <__bad_interrupt> |
15 | ... |
16 | 1e: 1a c0 rjmp .+52 ; 0x54 <__bad_interrupt> |
17 | 20: 1a c0 rjmp .+52 ; 0x56 <__vector_16> |
18 | |
19 | 00000022 <__ctors_end>: |
20 | 22: 11 24 eor r1, r1 |
21 | 24: 1f be out 0x3f, r1 ; 63 |
22 | 26: cf ed ldi r28, 0xDF ; 223 |
23 | ... |
Danke für die Antwort. So langsam glaube ich, das mit meinem gcc (oder linker) was nicht passt. Wenn ich das Gleiche mache, fehlt immer noch __vectors: ----------------- c-code: #include <inttypes.h> #include <avr/io.h> #include <avr/interrupt.h> volatile char usi_complete; volatile char usi_DR; ISR (USI_OVF_vect) { PORTA |= _BV(PA0); //Test-Ausgang setzen usi_complete = 1; // Copy USIDR to buffer to prevent overwrite on next transfer. usi_DR = USIDR; } int main (void) { DDRA |= _BV(DDA5); // DO PORTA |= _BV(PA4) | _BV(PA6); // Pull-ups für DI/CLKL PORTA |= _BV(PA2)| _BV(PA3)| _BV(PA7); PORTB |= _BV(PB0) | _BV(PB2)| _BV(PB3); DDRA |= _BV(DDA0); //Test-Ausgang PORTA &= ~_BV(PA0); DDRA |= _BV(DDA1); //Test-Ausgang PORTA &= ~_BV(PA1); // Configure USI to 3-wire slave mode, with int USICR = _BV (USIWM0) | _BV(USICS1)|_BV (USIOIE); sei(); for (;;){ if(usi_complete ){ PORTA |= _BV(PA1); switch(usi_DR){ case(0x11):{ USIDR=0xaa; break; } case(0x22):{ USIDR=0xbb; break; } case(0x33):{ USIDR=0xcc; break; } } usi_complete=0; USISR = _BV(USIOIF); loop_until_bit_is_set(USISR, USIOIF); } } return (0); } ----------------------------- ende c-code avr-gcc -Os -mmcu=attiny24 -o foo1.elf ghl.c avr-objdump -d foo1.elf foo1.elf: file format elf32-avr Disassembly of section .text: 00000000 <__ctors_end>: 0: 10 e0 ldi r17, 0x00 ; 0 2: a0 e6 ldi r26, 0x60 ; 96 4: b0 e0 ldi r27, 0x00 ; 0 6: e8 ea ldi r30, 0xA8 ; 168 8: f0 e0 ldi r31, 0x00 ; 0 a: 03 c0 rjmp .+6 ; 0x12 <.do_copy_data_start> 0000000c <.do_copy_data_loop>: c: c8 95 lpm Grüsse rolf-harry
Ruf mal den Compiler mit -v auf (und dem Rest der Kommandozeile natürlich). Was für eine Installation/Version/... ist das denn?
Hallo, hier ist der Aufruf mit -v: ------------------------------------------------- avr-gcc -v -Os -mmcu=attiny24 -o foo2.elf ghl.c Using built-in specs. Target: avr Configured with: ../configure --prefix=/usr/local/avr --target=avr --enable-lang uages=c --disable-nls --disable-libssp --with-dwarf2 Thread model: single gcc version 4.1.1 /usr/local/avr/libexec/gcc/avr/4.1.1/cc1 -quiet -v ghl.c -quiet -dumpbase ghl.c -mmcu=attiny24 -auxbase ghl -Os -version -o /tmp/ccrTCpBl.s ignoring nonexistent directory "/usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr /sys-include" #include "..." search starts here: #include <...> search starts here: /usr/local/avr/lib/gcc/avr/4.1.1/include /usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/include End of search list. GNU C version 4.1.1 (avr) compiled by GNU C version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13sa rge1). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129534 Compiler executable checksum: a8184b2ff31c5a915e800b494000c2c7 /usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/bin/as -mmcu=attiny24 -o tmp cc4zujlS.o /tmp/ccrTCpBl.s /usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/bin/ld -o foo2.elf -L/usr/loca l/avr/lib/gcc/avr/4.1.1 -L/usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/lib / tmp/cc4zujlS.o -lgcc -lc -lgcc ------------------------------------------------- Habe Debian Sarge i386. Die ganze avr-toolchain hab ich nach der (übrigens sehr guten) Anleitung auf nongnu.org/avr-libc gebaut, weil die aktuellen (stable) Pakete von Debain den tiny24 nicht kennen. Habe also zuerst die binutils gebaut, dann gcc, dann avr-libc. Beim gcc hab ich alle Patches (wpatch-0b-constants, patch-bug25672, patch-libiberty-Makefile.in, patch-zz-atmega256x, patch-attribute_alias, patch-dwarf, patch-newdevices) vor dem ./configure angewendet. Für die binutils werden in der Anleitung ja auch Patches empfohlen, allerding muss ich gestehen, dass ich das gelassen habe, ich wusste nicht welche ich nehmen sollte. Zusammengefasst siehts also so aus: binutils 2.17 gcc 4.11 (mit Patches) avr-libc 1.4.5 Grüsse rolf-harry
Mir ist noch dieses ignoring nonexistent directory "/usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/sys-include" in der Ausgabe aufgefallen. Kann das ein Ansatz sein ? Grüsse rolf-harry
> Kann das ein Ansatz sein?
Nein, das ist OK. Aber irgendwas ist mit dem Compiler vergurkt, denn
er übergibt dem Linkeraufruf das crttn24.o nicht mit. So sieht das
bei mir aus:
1 | Using built-in specs. |
2 | Target: avr |
3 | Configured with: ./../gcc-4.1.1/configure --target=avr --disable-libssp --prefix=/usr/local i386-portbld-freebsd6.1 |
4 | Thread model: single |
5 | gcc version 4.1.1 |
6 | /usr/local/libexec/gcc/avr/4.1.1/cc1 -quiet -v ghl.c -fno-delete-null-pointer-checks -quiet -dumpbase ghl.c -mmcu=attiny24 -auxbase ghl -Os -version -o /var/tmp//ccJmFa5r.s |
7 | ignoring nonexistent directory "/usr/local/lib/gcc/avr/4.1.1/../../../../avr/sys-include" |
8 | #include "..." search starts here: |
9 | #include <...> search starts here: |
10 | /usr/local/lib/gcc/avr/4.1.1/include |
11 | /usr/local/lib/gcc/avr/4.1.1/../../../../avr/include |
12 | End of search list. |
13 | GNU C version 4.1.1 (avr) |
14 | compiled by GNU C version 3.4.4 [FreeBSD] 20050518. |
15 | GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64436 |
16 | Compiler executable checksum: e05a4be084b8452f07f20cde87edd4f1 |
17 | /usr/local/lib/gcc/avr/4.1.1/../../../../avr/bin/as -mmcu=attiny24 -o /var/tmp//ccTRstgR.o /var/tmp//ccJmFa5r.s |
18 | /usr/local/lib/gcc/avr/4.1.1/../../../../avr/bin/ld -m avr2 -o foo2.elf /usr/local/lib/gcc/avr/4.1.1/../../../../avr/lib/crttn24.o -L/usr/local/lib/gcc/avr/4.1.1 -L/usr/local/lib/gcc/avr/4.1.1/../../../../avr/lib /var/tmp//ccTRstgR.o -lgcc -lc -lgcc |
(Der Präfix ist bei mir /usr/local, nicht /usr/local/avr. Aber das ist eigentlich egal, solange alle Teile der Toolchain gleichermaßen damit konfiguriert worden sind.)
OK, ich frage mich, ob ich wohl mit dem Patchen was falsch gemacht hab, aber der gcc hatte sich ohne Meckern gebaut. Den Päfix hab immer benutzt. Kann es auch an den binutils liegen (da hab ich nix gepatched), oder kann man anhand der Ausgaben das Problem auf den gcc eingrenzen ? Grüsse rolf-harry
Ich denke, dass es der GCC ist, der die Kommandozeile flashc zusammmen baut. Du kannst mal "avr-gcc -dumpspecs" aufrufen. Da muss sich unter *crt_binutils finden: %{mmcu=attiny24:crttn24.o%s}
Aha, "avr-gcc -dumpspecs |grep attiny24" ergibt: nix! Habe die Ausgabe als Datei angehängt. Grüsse rolf-harry
Wenn ich aber das hier mache (tiny26): "avr-gcc -v -Os -mmcu=attiny26 -o foo3.elf ghl.c" "avr-objdump -d foo3.elf" Ist die __vectors Tabelle vorhanden. Grüsse rolf-harry
Ich muss doch nochmal mit den binutils nerven: Wie gesagt, da hab ich ja nix gepatched, eben hab ich nochmal unter http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-binutils/files/patch-newdevices geguckt, dort gibt es unter Revision 1.3 "Add support for ATtiny24/44/84 devices" etwas, das ich möglicherweise doch hätte nehmen sollen ? Grüsse rolf-harry
rolf-harry wrote: > ..., dort gibt es unter Revision 1.3 "Add support for ATtiny24/44/84 > devices" etwas, das ich möglicherweise doch hätte nehmen sollen ? Nein, wenn du dir den aktuellen "newdevices"-Patch ansiehst, fügt der nur noch ein paar von den neuen Picopower-AVRs hinzu, der Rest ist bei binutils 2.17 bereits von Haus aus dabei. Das muss in deinem GCC liegen, irgendwie sieht mir das aus, als hättest du den nicht vollständig gepatcht. Dadurch wird zwar -mmcu=attiny24 prinzipiell erkannt, aber der Teil des Patches, der das crttn24.o zu den (internen) Specs hinzufügt, scheint wohl zu fehlen: @@ -799,6 +854,15 @@ %{mmcu=at86rf401:crt86401.o%s} \ %{mmcu=attiny13:crttn13.o%s} \ %{mmcu=attiny2313:crttn2313.o%s} \ +%{mmcu=attiny24:crttn24.o%s} \ +%{mmcu=attiny44:crttn44.o%s} \ +%{mmcu=attiny84:crttn84.o%s} \ +%{mmcu=attiny25:crttn25.o%s} \ +%{mmcu=attiny45:crttn45.o%s} \ +%{mmcu=attiny85:crttn85.o%s} \ +%{mmcu=attiny261:crttn261.o%s} \ +%{mmcu=attiny461:crttn461.o%s} \ +%{mmcu=attiny861:crttn861.o%s} \ %{mmcu=atmega103|mmcu=avr3:crtm103.o%s} \ %{mmcu=atmega603:crtm603.o%s} \ %{mmcu=at43usb320:crt43320.o%s} \ Hast du denn beim Patchen irgendwo ein .rej-File bekommen? Ich würde ja vermuten, dass die anderen in obigem Stück genannten CPUs unter dem gleichen Problem leiden.
Nein, hab eben nochmal /usr/local nach *.rej abgesucht, da ist nix. Der Teil oben ist jedenfalls in der avr.h gelandet. Bin aber trotzdem nicht so sicher, alles richtig gemacht zu haben, habe die patches (wie weiter oben beschrieben) runtergeladen, und vor dem .configure so aufgerufen: patch -p0 < /usr/local/patches/files/patch-newdevices patch -p0 < /usr/local/patches/files/patch-0b-constants patch -p0 < /usr/local/patches/files/patch-attribute_alias patch -p0 < /usr/local/patches/files/patch-bug25672 patch -p0 < /usr/local/patches/files/patch-dwarf patch -p0 < /usr/local/patches/files/patch-libiberty-Makefile.in patch -p0 < /usr/local/patches/files/patch-newdevices Und richtig, mit einem tiny44 z.B. habe ich das gleiche Problem... Grüsse rolf-harry
Die reject-Dateien würden auch nicht in /usr/local liegen, sondern in deinem GCC-Build-Verzeichnis (nach dem Patchen). Du hast den newdevices-Patch in obiger Folge zweimal drin, also das muss schief gehen. :-o Ansonsten werden die Patches der FreeBSD-Ports in alphabetischer Reihenfolge appliziert.
Tausend Dank, Jörg, das wars. Ich hatte das wohl beim Patchen vermasselt. Nach dem "Neubau" des gcc ist die __vectors Tabelle da! Grüsse rolf-harry
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.