Ich kämpfa gerade mit avr-gcc 4.7.2 und einem Attiny 10. Der Compiler
weigert sich, die kurzen 8-bit LDS und STS für den Speicherzugriff zu
nutzen, sondern erzeugt stattdessen einen indirekten Zugriff über das
Z-Register. Das ist natürlich kompletter Unsinn und bläht den Code
unnötig auf.
Kann man dagegen etwas tun?
z.B.
Tim schrieb:> Kann man dagegen etwas tun?
Atmel nerven. Der ganze Reduced-Core-Kram liegt derzeit einzig und
allein bei denen. Den patchen sie selbst in den GCC rein, und meines
Wissens ist er nach wie vor in einem reichlich halbbackenen Zustand.
Johann L. schrieb:> Ich denk das ist unabhängig vom Tiny und müsste sich auch mit normalen> AVRs nachvollziehen lassen.
Wenn ich den gleichen Source für einem ATtiny85 compiliere, werden an
den gleichen Stellen 16-Bit "STS" Befehle erzeugt. Irgendwie sieht mir
das nach einem schnellen Kompatibilitätsfix aus.
Jörg Wunsch schrieb:> Atmel nerven.
Werde es mal machen.
Lustig, es geht gleich weiter. AVR-GCC scheint für den ATtiny 10 andere
calling conventions als diese hier:
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage
zu verwenden. Auf den normalen Cores können R18/R19 "geclobbered"
werden, auf dem ATtiny 10 geht der compiler offenbar davon aus, dass
diese erhalten bleiben. Nur wo ist das dokumentiert?
Tim schrieb:> Lustig, es geht gleich weiter. AVR-GCC scheint für den ATtiny 10 andere> calling conventions als diese hier:
Nicht ganz überraschend, wenn man bedenkt, dass es R0-R15 nicht gibt.
Tim schrieb:> Lustig, es geht gleich weiter. AVR-GCC scheint für den ATtiny 10 andere> calling conventions als diese hier:
Was angesichts des nur halben Registersatzes ja nicht verwunderlich
ist.
> Nur wo ist das dokumentiert?
Atmel fragen. ;-)
Naja, sieht aus, als wenn ich einfach noch mehr Assembler verwenden
muss.
Schade, ich hatte V-USB auf dem Attiny 10 schon so weit, dass die ersten
Requests beantwortet wurden.
Der code oben compiliert ohne Fehlermeldung.
Dieser aber nicht, trotz pointer auf static.
1
uint8_tout;
2
staticuint8_tadr=1;
3
4
asmvolatile(
5
" lds %0,%1 \n\t"
6
:"=&d"(out)
7
:"M"((uint8_t)&adr)
8
);
Ich habe es aber jetzt auch so in den Speicher bekommen. Ich werde erst
einmal abwarten, was vom Ateml support kommt, bevor ich Arbeit in
Workarounds investiere.
Nein, "i" steht für Immediate, also "s" (symbolic) oder "n" (compile
time constant). Folgender Code geht für nicht-Tiny und sollte auch mit
Tinys gehen:
Das "memory"-clobber keyword kann ich für Ladebefehle aber weglassen,
oder? Ansonsten würdem im schlechtesten Fall ja Variablen doppelt
geladen werden.
Das Lesen eines SFR's kann prinzipiell diese oder gar ein anderes SFR
verändern. Wenn nur RAM gelesen wird, kann das memory-clobber weg, und
auch das volatile kann dann entfallen dürfen.
Danke! Hat im ganzen Code 32 Bytes gespart. Da hat Atmel noch ein paar
Hausaufgaben.
Es handelt sich übrigens um eine minimal USB-Implementierung auf einem
ATtiny 10. Wahrscheinlich das komplexeste für den ATtiny10 existierende
Programm :)
Und es funktioniert sogar:
https://github.com/cpldcpu/u-wire
Naja, bei 1 K Flash kann man's auch gleich in ASM machen, da würde ich
nicht so einen Würg Around mit dem Compiler veranstalten.
Edit: Ich vermisse 100nF am AVR.
Falk Brunner schrieb:> Naja, bei 1 K Flash kann man's auch gleich in ASM machen, da würde> ich> nicht so einen Würg Around mit dem Compiler veranstalten.
Klar, aber irgendwie ist es nicht der Sinn der Sache, existierende
C-Programme in Assembler nachzuprogrammieren. Vor allem das Zuweisen der
Register und die Optimierung von langen Switch/If-Konstrukten überlasse
ich gerne dem C-Compiler. Das kann er aber besser, je mehr
zusammenhängenden Code er sieht.
Ich hoffe ja, das Atmel die bestehenden Bugs im Compiler noch beseitigt,
damit ich die Workaround wieder entfernen kann.
> Edit: Ich vermisse 100nF am AVR.
Du meinst den Aufbau auf dem Broadboard? Da verbergen sich etliche
passive Bauteile auf den Rückseiten der Break-Out boards.
Tim schrieb:> Lustig, es geht gleich weiter. AVR-GCC scheint für den ATtiny 10 andere> calling conventions als diese hier:>> http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage>> zu verwenden. Auf den normalen Cores können R18/R19 "geclobbered"> werden, auf dem ATtiny 10 geht der compiler offenbar davon aus, dass> diese erhalten bleiben. Nur wo ist das dokumentiert?
Hier die Antwort vom Atmel-Support. Das andere Problem schauen sie sich
noch an.
1
As per current implementation (till Tool chain 3.4.3), below is the register conventions used for AVR_TINY devices:
Der Support hat ganz erstaunt nach Codebeispielen gefragt. Bei einem so
leicht zu reproduzierenden Problem gibt mir das zu denken :) Ich hatte
ihnen den Auszug aus dem Listingfile geschickt.