Hi, mich würd interessieren wer avr-gcc für die "reduced" ATtinys verwendet und was die Erfahrungen bzgl. avr-gcc sind. "Reduced" Tiny sind solche AVRs, die nur 16 Register (GPR) haben.
Ich! Erfahrungen sehr gemischt. Einige Bugs sind seit Jahren ungefixed.
Tim . schrieb: > Einige Bugs sind seit Jahren ungefixed. Hast du die Nummern der Bug-Reports?
Im Wesentlich sind z.B: STS/LDS immer noch nicht richtig supported. Hatte das vor Jahren an den Atmel-Support gemeldet. Inzwischen existert das Ticketing system nicht einmal mehr...
Gast
#4814078
Für den t10 benutze ich den gcc 4.8.1 aus der AVR_8_bit_GNU_Toolchain_3.4.4_1229 von Atmel. In der Version ist zumindest der LDS/STS bug gefixt. Die anderen bugs habe ich nicht getestet bzw. sind mir noch nicht aufgefallen. Leider funktioniert das in späteren Versionen schon wieder nicht mehr.
Gast
#4814080
Nachtrag: kann nur für Linux sprechen, wie sich das unter win verhält weiß ich nicht.
Tim . schrieb: > Im Wesentlich sind z.B: STS/LDS immer noch nicht richtig supported. Also eher ein Optimierungsproblem als ein "Bug". Ab v7 gibt's -mabsdata, das außer für ATtiny40 standardmäßig aktiviert ist (bei ATtiny40 ist nicht das gesamte RAM absolut adressierbar). Zudem gibt's ein neues Variablen-Attribut "absdata", mit dem man mitteilen kann, dass ein bestimmtes Objekt absolut adressierbar ist. Ein Support in Binutils gibt's nicht dafür, d.h. der Anwender ist dafür verantwortlich, dass LDS / STS auch tatsächtlich passen, etwa durch ein adäquates Linker Description File. https://gcc.gnu.org/PR78093 https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html#index-g_t_0040code_007babsdata_007d-variable-attribute_002c-AVR-3614 > Hatte das vor Jahren an den Atmel-Support gemeldet. Zu dem was Atmochip treibt kann ich nichts sagen; bis zum GCC hat's deren Support für LDS / STS jedenfalls nicht geschafft.
Gast
#4814204
Von wem bitte ist diese Compiler-Version? Dieser avr-gcc unterstützt LDS/STS beim T10.
JoeS schrieb: > Von wem bitte ist diese Compiler-Version? > Dieser avr-gcc unterstützt LDS/STS beim T10. Die Antwort hast du schon gepostet :-) JoeS schrieb: > gcc-version.txt >> --with-bugurl=http://www.atmel.com Ist aber wohl "dead end", weil das weder im offiziellen 4.9 noch in 5 noch in 6 noch in 7 drinne ist... Vielleicht portiert Atmochip auch alle GCC Änderungen in ihren eigenen Fork, keine Ahnung. Jedenfalls sind bei dieser Strategie einige Unannehmlichkeiten zu erwarten -- aber das ist nun mal so mit einem eigenen Fork der vom offiziellen immer mehr divergiert...
JoeS schrieb: > Von wem bitte ist diese Compiler-Version? > Dieser avr-gcc unterstützt LDS/STS beim T10.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
1 | |
Gast
#4814252
Ja genau im 4.9 war das schon wieder weg. Hat mich sehr geärgert und ist wohl auch nicht geplant das wieder zu fixen. Deshalb benutze ich für den t10, und nur für den, ja auch noch diese alte Version. Hatte damit bisher keine Probleme und die Einsparung an Flash ist eben nicht unerheblich.
JoeS schrieb: > Ja genau im 4.9 war das schon wieder weg. Hat mich sehr geärgert > und ist wohl auch nicht geplant das wieder zu fixen. Deshalb benutze ich > für den t10, und nur für den, ja auch noch diese alte Version. Hatte > damit bisher keine Probleme und die Einsparung an Flash ist eben nicht > unerheblich. Die muss ich wohl übersprungen haben. Warum entfernt Atmel so etwas bitte wieder?
Tim . schrieb: > Warum entfernt Atmel so etwas bitte wieder? Vermutlich habes sie es nicht entfernt, sondern schlichtweg nicht von der 4.8 auf die 4.9 portiert :-)
Johann L. schrieb: > Vermutlich habes sie es nicht entfernt, sondern schlichtweg nicht von > der 4.8 auf die 4.9 portiert Denke ich auch. Der Wildwuchs durch die eigene angehäufte Patchsammlung wurde zu groß. Ich habe für FreeBSD auch mal derartige Patches eine Weile lokal von GCC-Version zu Version portiert (zu Zeiten, als im offiziellen Repo sich keiner um AVR gekümmert hat), ist eine Sysiphusarbeit. Seit Johann beim AVR-GCC aktiv ist, konnte ich mir die Arbeit dann glücklicherweise sparen, alle wesentlichen Bugs werden nun jeweils auch im Mainstream-GCC einigermaßen zeitnah repariert. Meine Vermutung ist übrigens keineswegs, dass Atmochip diesen privaten „fork“ vorsätzlich pflegt, sondern dass den Jungs dort ihr Management einfach keine Zeit einräumt, dass mal so weit zu sortieren, dass sie es auch bei GCC zurückfüttern können.
In AVR-GCC 4.8.1 unter Linux (debian) sind LDS/STS auch richtig implementiert.
Tim . schrieb: > In AVR-GCC 4.8.1 unter Linux (debian) sind LDS/STS auch richtig > implementiert. Das Betriebssystem ist dabei reichlich unerheblich. Die Quelle deines Compilers müsstest du nennen. Vermutlich ist das einfach der gleiche GCC 4.8.1, den wir oben schon gesehen haben, den sich Atmel damals zurechtgepfriemelt hat.
Jörg W. schrieb: > Das Betriebssystem ist dabei reichlich unerheblich. Die Quelle deines > Compilers müsstest du nennen. Vermutlich ist das einfach der gleiche > GCC 4.8.1, den wir oben schon gesehen haben, den sich Atmel damals > zurechtgepfriemelt hat. Eigentlich ein guter Punkt. Es handelt sich um das aktuelle Debian Package. Ich dachte immer, das GCC-AVR Debian Pakage würde die offiziellen Quellen nutzen. Anscheinend ist es aber doch das Atmel-release - siehe Screenshot des Changelogs. Gibt es irgendwo packages der "offiziellen" Version? Sonderlich aktuelle ist das Debian package ja nun auch nicht.
Angehängte Dateien:
-
Unbenannt.PNG
(62 KB)
Tim . schrieb: > Gibt es irgendwo packages der "offiziellen" Version? > Sonderlich aktuelle ist das Debian package ja nun auch nicht. GNU unterstützt -mmcu=avrtiny erst ab v5. http://gcc.gnu.org/gcc-5/changes.html In den 4.8er Quellen gibt es weder Core avrtiny noch irgendein dazu gehörendes Device: http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_8-branch/gcc/config/avr/avr-mcus.def?view=markup http://gcc.gnu.org/viewcvs/gcc/tags/gcc_4_8_1_release/gcc/config/avr/avr-mcus.def?view=markup Der Support für avrtiny wurde erst 2014-10-21 von Embecosm + Atmel beigetragen: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=216525 und dort gibt es eine avr.c::tiny_valid_direct_memory_access_range welche für Symbole immer false liefert. Ist eigentlich auch korrekt, denn einzig am Symbol kann man nicht erkennen, ob es brauchbar für LDS ist. Wegen weiterer Probleme wurde diese Funktion dann im Rahmen von PR65192 bereits 2015 noch vor Release v5 wieder entsorgt, was aber nichts daran änderte, dass nur für Adressen, die zur Compilezeit bekannt sind wie *(int*)0x42, LDS verwendet wurde. Soviel zu Archäologie von LDS... Funktionierende LDS / STS Unterstützung gibt's erst seit einigen Wochen mit PR78093. Das kommt aber erst mit v7 unter die Leute, also ab Frühjar 2017. https://gcc.gnu.org/PR78093 Außer für ATtiny40 ist -mabsdata standardmäßig gesetzt, weil für kleinere Devices bis hin zu ATtiny20 das gesamte RAM absolut adressierbar ist. Für ATtiny40 kann -mabsdata händisch gesetzt werden falls es passt, ansonsten muss man einzelne Objekte als absdata attributieren und selbst sicherstellen, dass sie tatsächlich per LDS / STS erreichbar sind. Hilfreich, um möglichst wenig daten im RAM zu haben, ist .rodata nicht nach .data zu lokatieren. Stattdessen belässt man .rodata im Flash und addiert Offset 0x4000 auf die VMAs. Auf PROGMEM kann dann komplett verzichtet werden, erklärt z.B. hier unter "progmem": http://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.