Hallo, ich habe ein kleines Programm für den AT90S2313 geschrieben mit dem GCC v3.4.1, der Bestandteil von WinAVR 20040720 ist. Mir ist durchaus klar, dass es nicht unbedingt sinnvoll ist, für so einen kleinen µC gleich einen C-Compiler anzuwerfen, aber es ging so wesentlich schneller und das war mir wichtig. Jedenfalls ist mir dabei aufgefallen, dass der GCC für diesen µC falschen Code erzeugt (siehe Anhang). Der Befehl im roten Kasten sowie der nachfolgende Befehl dienen zum initialisieren des Stackpointers. Problem ist nur, dass der Stackpointer des 90S2313 nur aus einem Register besteht ($3D), Register $3E ist "reserved" und sollte lt. Datenblatt S. 84 niemals beschrieben werden ("Reserved I/O memory addresses should never be written."). Die Konsequenz aus diesem fehlerhaften Code ist, dass der Simulator von VMLAB z. B. an dieser Stelle mit einer Fehlermeldung einfach abbricht, so wie es eigentlich sein sollte. Weiter scheint AVR Studio dies komplett zu ignorieren, es meckert an keiner Stelle. Ich wollte das hier nur mal kurz erwähnen. Der fehlerhafte Code funktioniert in meiner Anwendung zwar problemlos, bin jedoch trotzdem auf einen anderen Compiler umgestiegen, der das richtig macht. Gruß Thorsten
WinAVR 20060125 erzeugt den gleichen fehlerhaften Code, wie folgender Auszug aus dem lst-File zeigt: 1 .file "test.c" 2 .arch at90s2313 3 _SREG_ = 0x3f 4 _SP_H_ = 0x3e 5 _SP_L_ = 0x3d Der AT90S2313 besitzt kein SPH.
Und natürlich noch das: 24 0000 C0E0 ldi r28,lo8(__stack - 0) 25 0002 D0E0 ldi r29,hi8(__stack - 0) 26 0004 DEBF out _SP_H_,r29 27 0006 CDBF out _SP_L_,r28
> Der AT90S2313 besitzt kein SPH. Stört aber auch nicht. VMLAB meckert zwar, aber du kannst danach getrost weitermachen. GCC behandelt den Stackpointer immer als 16-Bit-Zeiger, bei einem AT90S2313 wird dann ein nicht existierendes IO-Register mit 0 beschrieben, letztlich ignoriert die Hardware das einfach (im Gegensatz zum VMLAB). Die Ursache dafür ist, dass der GCC nicht für jeden einzelnen der vielen Controller einen eigenen Codegenerator implementiert, sondern die AVR-Cores nur grob klassifiziert.
Alles klar, vielen Dank. Dennoch sollte ein Compiler aber schon die Empfehlungen des Chipherstellers beachten: "Reserved I/O memory addresses should never be written."
Yep. Und wenn du schon dabei bist, den GCC entsprechend anzupassen, dann kannst du ihm auch gleich den kompletten Befehlssatz vom Tiny2313 beibringen. Der wird nämlich aus ähnlichem Grund als primitiv-AVR verstanden, was er indes nicht ist. Nur weil ihm der Multiplikationsbefehl fehlt und er daher nicht in die nächsthöhere Kategorie passt. In der Entwicklung vom GCC/AVR wurde eine Prozessor-Klassifizierung eingeführt, die sich im Laufe der Zeit als zu enges Zwangskorsett herausgestellt hat. Es wäre angebracht, statt einer Prozessorklasse die einzelnen Eigenschaften pro Modell getrennt einzupflegen. Aber solange das nicht passiert, wirst du damit leben müssen.
> Es wäre angebracht, statt einer Prozessorklasse die > einzelnen Eigenschaften pro Modell getrennt einzupflegen. Ja, mach mal. :-) Ich glaube, das macht nicht einmal AVR Studio... Die MOVW-Geschichte von ATtiny13/2313 ist aber bereits in Arbeit.
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.