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
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:
(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}
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.
