Hallo, ich kämpfe grad mit dem ATtiny40. Als Toolchain habe ich 3.2.3_315 ( AVR Studio 5) meiner Meinung der aktuelleste Stand, installiert. Das Problem fing damit an, dass ich kein Zugriff auf die Interrupthandler hatte. Nach langem Suchen, habe ich herausgefunden, dass die Interrupt Vector Nummern in der iot40.h völlig anders waren, nach Änderung gemäß Datanblatt liefen auch die Interrupts. Per Zufall sah ich auch, dass die RAMgrösse anstatt 256Byte nur 32Byte war. Naja habe ich auch geändert. Das schwierigere Problem ist, dass der µC es nicht schafft auf globale Variablen zurückzugreifen. Ohne Debuggen ist es nicht ganz einfach, daher habe ich mir mal den Assemblercode angeguckt und es tauchen ständig die folgende Fehler auf: 00000049 ICALL Indirect call to (Z) if (command == 0x10) 0000004A ???LDS R24,0x0040 Load direct from data space(Not supported by current part) ???STS 0x0040,R24 Store direct to data space(Not supported by current part) Hat jemand eine Idee oder weiß jemand wann es eine neue Toolchain gibt? Danke
Torsten A. schrieb: > ich kämpfe grad mit dem ATtiny40. Als Toolchain habe ich 3.2.3_315 ( AVR > Studio 5) meiner Meinung der aktuelleste Stand, installiert. Das Problem > fing damit an, dass ich kein Zugriff auf die Interrupthandler hatte. > Nach langem Suchen, habe ich herausgefunden, dass die Interrupt Vector > Nummern in der iot40.h völlig anders waren, nach Änderung gemäß > Datanblatt liefen auch die Interrupts. > Per Zufall sah ich auch, dass die RAMgrösse anstatt 256Byte nur 32Byte > war. Diese beiden Dinge kannst du gern als Bugreport bei avr-libc einkippen, den Rest musst du dem Atmel-Support berichten, denn die haben die Portierung auf diese tiny10-Architektur gemacht, und diese Portierung ist noch nicht in den GNU-Quellen für binutils und GCC drin. > ???STS 0x0040,R24 Store direct to data space(Not supported by > current part) Das ist eine fiese Falle, die die Entwickler des Tiny10 (& Co.) hier ihren Kollegen vom Compilerteam gelegt haben. Sie haben die Befehle LDS und STS zwar im Namen beibehalten, aber man muss schon sehr aufs "Kleingedruckte" im Instruction Set Manual schauen um zu erkennen, dass diese beiden Befehle für Tiny10 & Co. völlig anders codiert werden als für die bisherigen AVRs. (Man hat hier einen sehr stark eingeschränkten Adressraum, und daher kommen die Befehle mit 2 statt 4 Byte Opcode aus und laufen auch in einem Takt ab.) Diese Tatsache haben diejenigen, die den Tiny10-Support in den Binutils implementiert haben, folglich übersehen. Meiner Meinung nach hätte man sich neue Mnemonics ausdenken sollen stattdessen (vielleicht LDSS und STSS, für "short"), aber das ist natürlich jetzt zu spät.
danke, mit dem IAR läuft es. Weißt du, ob die Codegrössen-reduzierte Kickstartversion des IAR auch kommerziell genutzt werden darf?
Torsten A. schrieb: > Weißt du, ob die Codegrössen-reduzierte > Kickstartversion des IAR auch kommerziell genutzt werden darf? Überhaupt keine Ahnung, aber irgendwo wirst du beim Installieren garantiert die Lizenzbedingungen bestätigt haben. Die sollten dir alle zutreffenden Restriktionen genannt haben.
Jörg Wunsch schrieb: > Meiner Meinung nach hätte man sich neue Mnemonics ausdenken sollen > stattdessen (vielleicht LDSS und STSS, für "short"), aber das ist > natürlich jetzt zu spät. NACK. Für jedes Bit im Maschinencode, das sich von einem Derivat/Core zu einen anderen ändert, würde zu einem unüberschaubaren Zoo von Mnemonics führen und das Mnemo in /Mnemonic ad absurdum führen. Ich bin sehr überrascht, daß soche Fehler nicht auffallen, etwa wenn Atmel seine neue Toolchain testet. Effektiv bedeutet das, daß sie eine Toolchain portieren/freigeben/releasen, ohne je ein einzigel mal ein Programm auf ATtiny-Silizium ausgeführt zu haben... Abel selbst ohne Silizium müsste der Fehler auch in einem Simulator aufstoßen — wenn der Simulator nicht dem gleichen Fehler aufsitzt.
Johann L. schrieb: > NACK. Für jedes Bit im Maschinencode, das sich von einem Derivat/Core zu > einen anderen ändert, würde zu einem unüberschaubaren Zoo von Mnemonics > führen und das Mnemo in /Mnemonic ad absurdum führen. Naja, es sind die einzigen Befehle, die seit vielen Jahren neu dazu gekommen sind. Gemessen an den restlichen Änderungen im tiny-Core (vor allem der halbierte Registeranzahl) wäre die Änderung dieser beiden Mnemonics wohl wenig ins Gewicht gefallen. > Effektiv bedeutet das, daß sie eine Toolchain > portieren/freigeben/releasen, ohne je ein einzigel mal ein Programm auf > ATtiny-Silizium ausgeführt zu haben... Muss nicht sein. Es gibt genügend Programme, die ohne LDS/STS auskommen. Aber ich gebe dir natürlich Recht, es scheint alles mit einer recht heißen Nadel gestrickt worden zu sein und nur (zu) oberflächlich getestet. > Aber selbst ohne Silizium müsste der Fehler auch in einem Simulator > aufstoßen — wenn der Simulator nicht dem gleichen Fehler aufsitzt. Der Simulator leitet seit dem sogenannten "Simulator V2" seinen Code direkt aus der HDL-Implementierung des ICs ab. Damit ist garantiert, dass der Digitalteil exakt so simuliert wird (ggf. einschließlich der Hardwarebugs ;-), wie die Hardware auch implementiert ist. Nur die Analogbaugruppen müssen natürlich noch manuell modelliert werden.
Jörg Wunsch schrieb: > Johann L. schrieb: > >> NACK. Für jedes Bit im Maschinencode, das sich von einem Derivat/Core zu >> einen anderen ändert, würde zu einem unüberschaubaren Zoo von Mnemonics >> führen und das Mnemo in /Mnemonic ad absurdum führen. > > Naja, es sind die einzigen Befehle, die seit vielen Jahren neu dazu > gekommen sind. Wieso sind die dazugekommen? LDS und STS gibt's doch schon seit Anbeginn der Zeit.
Johann L. schrieb: >> Naja, es sind die einzigen Befehle, die seit vielen Jahren neu dazu >> gekommen sind. > > Wieso sind die dazugekommen? LDS und STS gibt's doch schon seit Anbeginn > der Zeit. Weil es vom Maschinencode her andere sind, und auch der Wertebereich der Adresse ein anderer, weiterhin die Ausführungszeit und Befehlslänge eine andere ist (kann ja wichtig sein, wenn man bspw. die Effektivität von inlining abschätzen will).
Vermutlich haben die AVRs wieder mal nen neuen Chef bekommen und der muß dann unbedingt seine Duftmarke hinterlassen und die Kunden mit völlig unnötigen Änderungen verschrecken. Daß man mit 16 Registern und 11 Befehlen weniger, etwas an Kosten einspart, kann mir keiner erzählen. Ich habe eigentlich an den AVRs gemocht, daß es gerade nicht so ein CPU-Core Wirrwarr wie bei den PICs gibt. D.h. ein ATtiny13 genauso programmiert werden kann, wie ein ATmega2560. Nun mit den neuen Tiny will wohl Atmel genau diese Unsitte auch einführen. Ich werde diese neuen Typen jedenfalls nicht verwenden. Peter
Peter Dannegger schrieb: > Daß man mit 16 Registern und 11 Befehlen weniger, etwas an Kosten > einspart, kann mir keiner erzählen. Dann fang' mal an, deinen eigenen Controller zu entwerfen, der noch in ein SOT-23 hineinpasst. Etwas Fläche für den Flash soll ja sicher auch noch übrig bleiben. :-) > Ich werde diese neuen Typen jedenfalls nicht verwenden. Dazu wird dich ja keiner zwingen. ;-) Die Dinger sind ganz gewiss keine Universal-Controller.
Peter Dannegger schrieb: > Daß man mit 16 Registern und 11 Befehlen weniger, etwas an Kosten > einspart, kann mir keiner erzählen. Würd' nicht so hart urteilen, da kann sicher gespart werden, weniger Befehle, weniger Silizium, mehr Ausbeute pro Wafer. > Nun mit den neuen Tiny will wohl Atmel genau diese Unsitte auch > einführen. Ich werde diese neuen Typen jedenfalls nicht verwenden. ATtiny4/5/9/10 sind 6-Füsser SOT, I/Os sind also ein wenig beschränkt, die nimmt sowieso nur der, der genau für so etwas 'ne Anwendung hat. Jörg Wunsch schrieb: > Weil es vom Maschinencode her andere sind, und auch der Wertebereich > der Adresse ein anderer, weiterhin die Ausführungszeit und > Befehlslänge eine andere ist (kann ja wichtig sein, wenn man bspw. > die Effektivität von inlining abschätzen will). Macht schon einen Unterschied ob man bei LDS/STS jeweils 2 oder 4 Bytes verbraucht. Das addiert sich und viel Flash haben die Dinger eh' nicht, kann also genau das "good enough" ausmachen.
Ooops, Themenverfehlung, war ja der Tiny40. Angefangen hat's bei den Tinys4-10, da war's ja auch klar wieso. Für größere Bausteine ist's aber auch mir ein wenig schleierhaft, ob das soviel ausmacht, daß es sich rechnet.
MWS schrieb: > Ooops, Themenverfehlung, war ja der Tiny40. Ist allerdings der gleiche CPU-Kern. Ich argumentiere ja auch nicht gegen diese Art der Implementierung der Speicherzugriffsbefehle, ich finde es nur nicht schön, dass man (was ansonsten beim AVR-Befehlssatz nicht der Fall ist) einem völlig anderen Opcode den gleichen Namen verpasst hat. Es ist ja nicht wie beim 8080, wo es "MOV" mit allerlei verschiedenen Parametern gibt und dann jedesmal was ganz anderes als Opcode rauskommt, sondern es gibt diverse Varianten von LD*- und ST*-Befehlen für die einzelnen Operandenkombinationen, da hätte man diesem Tiny-Kern nun auch noch ein LDSS und STSS oder dergleichen spendieren können, welches die 2-Worte-LDS und -STS des großen Kerns ersetzt. Es ist ja nicht nur der kürzere Opcode, der Flash spart (die Teile gibt es ja bis zu 512 Byte Flash herunter), sondern der SRAM-Zugriff ist damit auch doppelt so schnell.
Jörg Wunsch schrieb: > MWS schrieb: >> Ooops, Themenverfehlung, war ja der Tiny40. > > Ist allerdings der gleiche CPU-Kern. > > Ich argumentiere ja auch nicht gegen diese Art der Implementierung > der Speicherzugriffsbefehle, ich finde es nur nicht schön, dass man > (was ansonsten beim AVR-Befehlssatz nicht der Fall ist) einem völlig > anderen Opcode den gleichen Namen verpasst hat. Es ist ja nicht > wie beim 8080, wo es "MOV" mit allerlei verschiedenen Parametern > gibt und dann jedesmal was ganz anderes als Opcode rauskommt, sondern > es gibt diverse Varianten von LD*- und ST*-Befehlen für die einzelnen > Operandenkombinationen, da hätte man diesem Tiny-Kern nun auch noch > ein LDSS und STSS oder dergleichen spendieren können, welches die > 2-Worte-LDS und -STS des großen Kerns ersetzt. Eigene Mnemonics für solcherlei Befehle sind bestenfalls dann sinnvoll, wenn es eine 16-Bit und eine 32-Bit Variante gibt, so daß diese unterschieden werden können. Aber selbst dann wäre es nicht unbedingt sinnvoll. Wenn es zB eine LDS-Codierung als 32 Bit gäbe und zusätzlich noch eine LDS-Variante mit eingeschränktem Adressraum (die dafür effizienter ist) könnten die binutils immer die kürzere Variante codieren. Wichtig für einen Assembler-Programmiere ist doch, daß LDS immer das gleiche tut: Er lädt einen Wert aus dem RAM in ein register. Wie das codiert wird soll unter der Oberfläche bleiben.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.