Forum: Compiler & IDEs avr-libc 2.0.0 - Changes


von N. G. (newgeneration) Benutzerseite


Lesenswert?

Hallo Forum,

als ich heute mal auf der Seite der avr-libc war fiel mir die 
Versionsnummer ins Auge: 2.0.0: 
http://www.nongnu.org/avr-libc/user-manual/

Davor war 1.8.1 wenn ich mich nicht irre.


Zu diesem "Ereignis" 2 Fragen:

1. Gibt es ein Changelog, was bei diesem wirklichen 'Sprung der 
Versionsnummer erklärt? Ich habe auf meiner kurzen Suche nämlich keins 
gefunden.

2. Lohnt sich ein Update auf die neue Version (zB wegen Bugfixes)?

mfG
N.G.

PS: Gibt es eine Möglichkeit die libc zu Unterstützen?
Ich würde mich einerseits gerne an dem Projekt beteiligen, jedoch fehlt 
mir persönlich nur noch der double-Support (64bit). Es gbt auch 2 offene 
"Stellen", jedoch trifft keine der beiden Beschreibungen auf mich zu.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

N. G. schrieb:
> 1. Gibt es ein Changelog, was bei diesem wirklichen 'Sprung der
> Versionsnummer erklärt? Ich habe auf meiner kurzen Suche nämlich keins
> gefunden.

Am ehesten wird das klar, wenn du eine avr-gcc v5.2+ Installation mit 
einer 4.9 oder älter vergleichst (5.0 und 5.1 sind nicht funktional):

v5 unterstützt keine Devices mehr; der Device-Support läuft über die 
Abbildung von -mmcu= auf Device-spezifische Specs in
1
lib/gcc/avr/$version/device-specs

Es gibt Device-Libs in
1
avr/lib/$multidir
welche Device-abhängige (und damit nicht-Standard) Funktionen enthalten 
wie die für den EEPROM-Zugriff.

Die Namenskonvention für Startup-Objekte haben sich geändert, z.B. von 
crtm8.o zu crtatmega8.o, d.h. der crt-Name leitet sich direkt aus -mmcu= 
ab.

> 2. Lohnt sich ein Update auf die neue Version (zB wegen Bugfixes)?

Die Version muss zum avr-gcc passen, siehe die GCC 5 Release Caveats, 
d.h. mit v5.2+ brauch man avr-libc 2+ oder eine entsprechende 
Entwicklungsversion von 1.8.1 SVN trunk.

Umgekehrt müsste die neuere avr-libc auch auf alte avr-gccs passen, was 
per avr-libc configure erkannt wird.

> jedoch fehlt mir persönlich nur noch der double-Support (64bit).

Das wäre ein echt dicker Brocken und kein dünnes Brett zu bohren.  Nicht 
zuletzt will man dann auch double-support im avr-gcc haben, was momentan 
nicht der Fall ist (und nein, es genügt nicht, ein Makro 
umzudefinieren).

Jörg machte mal den Vorschlag, double per 48 Bit zu implementieren; 
wieviel Ärger das im GCC macht kann ich nur schlecht abschätzen.

: Bearbeitet durch User
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
Noch kein Account? Hier anmelden.