www.mikrocontroller.net

Forum: Compiler & IDEs Was ist die aktuelle, STABILE WinAVR Version?


Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist mit 20080610? Soweit OK oder sind da mal wieder böse 
Verschlimmbesserungen drin?

MFG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keiner?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau doch ins Datenblatt.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Schau doch ins Datenblatt.

Die Rache des Falk wird dich vernichten.
Der bastelt gerade an deiner Voodoo Puppe ;)

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Rache des Falk wird dich vernichten.

You made my day :-)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaum gabs mal ein, zwei unstabile, verbugte Versionen schon wirds dem 
WinAVR dauernd nachgetragen! ;)

Autor: John Small (linux_80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
apropos Datenblatt, wo findet sich eigentlich genaueres zu den Versionen 
der Teile die sich innerhalb der verschiedenen WinAVR Versionen 
befinden, also welche GCC ist in welcher WinAVR usw.
Irgendwie finde ich auf den "Seiten" von WinAVR nix dazu, liegt das an 
mir oder an der Seite :-)

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk
In der neuen Version blaehen die Eeprom-Funktionen aus der Lib das Ganze 
ziemlich auf. Wenn Du knapp mit Flash bist, musst Du diese Funktionen 
selber schreiben.

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um auf die Frage zurückzukommen:

>Was ist mit 20080610? Soweit OK oder sind da mal wieder böse
>Verschlimmbesserungen drin?

20080610 ist OK, bisher keine Probleme gehabt.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Simon K. (simon) Benutzerseite

>Kaum gabs mal ein, zwei unstabile, verbugte Versionen schon wirds dem
>WinAVR dauernd nachgetragen! ;)

If I do something right, nobody notices
If I do something wrong, nobody forgets.

;-)
Falk

P.S. Ok, das wollte ich wissen.

P.P.S. Warum blähen die EEPROM Funktionen auf? Was gibt es denn an so 
einer einfachen Sache so kompliziertes zu machen? Um wieviel Bytes reden 
wir denn hier?

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> P.P.S. Warum blähen die EEPROM Funktionen auf? Was gibt es denn an so
> einer einfachen Sache so kompliziertes zu machen? Um wieviel Bytes reden
> wir denn hier?
Einige 100 Bytes. Ich bin mir jetzt nicht ganz sicher, aber bei mir 
waren es so um die 300 oder 400 Bytes.

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehmet Kendi wrote:
> @Falk
> In der neuen Version blaehen die Eeprom-Funktionen aus der Lib das Ganze
> ziemlich auf. Wenn Du knapp mit Flash bist, musst Du diese Funktionen
> selber schreiben.

Wobei das nicht das einzige Problem mit den eEprom Funktionen ist.
Einige AVR Modelle haben einen Hardware-Bug. Wenn man mit LDS/STS statt 
den IN/OUT Befehlen auf die eEprom Register zugreift wird ein eEprom 
Interrupt ausgelöst, auch wenn dieser garnicht aktiviert ist. Und eben 
dies tut die neue AVR-LibC.

Siehe http://savannah.nongnu.org/bugs/?23969

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:

> P.P.S. Warum blähen die EEPROM Funktionen auf? Was gibt es denn an so
> einer einfachen Sache so kompliziertes zu machen?

Das bisherige Bibliotheksmodell (Einteilung der AVRs nach groben
Klassen pro physischer Bibliothek, also avr2 ... avr6) war nicht fein
genug für die EEPROMs.  Es wurde beispielsweise EEARDH beschrieben,
auch wenn der entsprechende AVR dieses Register gar nicht besitzt, und
es gab einen Bugreport, bei dem (angeblich -- ich konnte es nicht
reproduzieren) sich ein ATtiny13 deshalb aufgehängt hat.  Nun ja,
"politisch korrekt" war/ist der Zugriff auf nicht existierende
Register natürlich noch nie.

Zusammen mit den ohnehin notwendigen Änderungen für den völlig anderen
EEPROM im Xmega hat Eric das genommen, die Implementierung von
Bibliotheksfunktionen komplett auf inline umzustellen (dadurch erfolgt
sie erst zur Compilezeit, sodass sie exakt auf den jeweiligen AVR
angepasst ist).  Wenn du nur mal einen eeprom_read_block() hast,
sollte es kein großer Unterschied zu früher sein, wenn du viele
Einzelzugriffe hast, bläht das Inlining deinen Code auf.  Aber du
kannst ja selbst einen Wrapper um die inline-Funktion schreiben in
diesem Falle.

Eigentlich steht immer noch auf dem Plan, das gesamte Bibliotheks-
modell mal auf eine physische Bibliothek pro AVR zu bringen.  Das
kostet einfach nur Arbeit, das ist der wesentliche Grund, warum es
noch nicht getan ist.  Wenn dem so ist, ließen sich die EEPROM-
Funktionen wieder problemlos in der Bibliothek unterbringen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Simon K. (simon)
>Kaum gabs mal ein, zwei unstabile, verbugte Versionen schon wirds dem
>WinAVR dauernd nachgetragen! ;)

Und welche war die Andere?  ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller wrote:
> @ Simon K. (simon)
>>Kaum gabs mal ein, zwei unstabile, verbugte Versionen schon wirds dem
>>WinAVR dauernd nachgetragen! ;)
>
> Und welche war die Andere?  ;-)

Insgesamt waren es 4:

WinAVR-20080402
WinAVR-20080407
WinAVR-20080411
WinAVR-20080512

Die finale Version ist WinAVR-20080610


Peter

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Insgesamt waren es 4:

Naja, die direkt davor liegende 20072112 hatte bei floats auch so ihre 
"Eigenarten".

Beitrag "Winavr20071221 :-("

Oliver

Autor: Klugscheisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleiner Vorschlag:
Vielleicht könnte man hier aus dem Forum (und auch woanders) die Threads 
zusammensuchen, die dann damit geendet haben, das wohl ein Bug vorliegt 
und eine kleine Testsuite daraus machen. Die kann man dann durch neue 
Versionen jagen um festzustellen ob bekannte Bugs noch vorliegen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klugscheisser wrote:
> Kleiner Vorschlag:
> Vielleicht könnte man hier aus dem Forum (und auch woanders) die Threads
> zusammensuchen, die dann damit geendet haben, das wohl ein Bug vorliegt
> und eine kleine Testsuite daraus machen. Die kann man dann durch neue
> Versionen jagen um festzustellen ob bekannte Bugs noch vorliegen.

Du kannst auch einfach in den avr-libc Bugtracker schauen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:

> Du kannst auch einfach in den avr-libc Bugtracker schauen.

...bzw. in den von WinAVR selbst.

Autor: Klugscheisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du kannst auch einfach in den avr-libc Bugtracker schauen.
>...bzw. in den von WinAVR selbst.

Ach so? Also Falk, einfach im Bugtracker und WinARV schauen! ;-)

Autor: Klugscheisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich meinen vorherigen Post so lese, klingt das doch ironischer als 
gewünscht.

Was mir an Simons und Jörgs Antworten auffällt ist, das diese Lösungen 
ja das Vorliegen der Information zur Voraussetzung haben, die ja eben 
erst ermittelt werden soll.

D.h. damit ein Bug im Bugtracker stehen kann, muss er ja erstmal bekannt 
sein.
D.h. damit er in der Hilfe von WinAVR (oder was meintest Du Jörg?) 
stehen kann, muss er ja erstmal bekannt sein.

Aber Falk, dem ich zutrauen würde, das ihm das auch klar ist, fragt ja 
gerade nach einer unbekannten Information.
Mein Vorschlag ging ja dahin diese Information systematisch zu gewinnen.

Oder habe ich mich da nicht ausreichend deutlich geäussert?

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Klugscheisser

Du studierst im Nebenfach Philosophie oder Germanistik, stimmts? :-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt Zeit kommt Rat würde ich sagen. Wenn die aktuell verfügbare 
Version schon ein paar Monate auf dem Buckel hat, dann darf man sie wohl 
als "stabil" ansehen.

Autor: Klugscheisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Klaus Falser:
Wenn ich Dir auf irgendeine Weise behilflich sein kann.... :-)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite

>Bibliotheksfunktionen komplett auf inline umzustellen (dadurch erfolgt
>sie erst zur Compilezeit, sodass sie exakt auf den jeweiligen AVR

>kannst ja selbst einen Wrapper um die inline-Funktion schreiben in
>diesem Falle.

Kann man denn sowas nicht in der Doku mit ein paar Worten vermerken, 
sodass die Community das nicht erst per Trail & Error herausfinden muss?

MFG
Falk

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Changelog stehts immerhin:

http://cvs.savannah.gnu.org/viewvc/*checkout*/avr-...

> 2008-08-19  Eric B. Weddington  <eric.weddington@atmel.com>
>
>   Fix for bug #23969.
>   * include/avr/eeprom.h: Change part of the EEPROM read routine
>   to inline assembly to avoid problems with certain AVR parts.

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Falk:

[klugscheiss]
>sodass die Community das nicht erst per Trail & Error herausfinden muss

Du meinst 'Trial', oder?

Happy Trails to you!
[/klugscheiss]

:-D

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> Im Changelog stehts immerhin:

Es steht auch im NEWS-File (was man vielleicht als sowas wie release
notes ansehen könnte):

EEPROM functions are rewriten. Now the base procedures (eeprom_read_byte
and eeprom_write_byte) are inline: they are evaluated at compile time
of user program. This gives a possibility to add support for new AVR
arhitectures very simply. Also this fixes Avr-libc bug #21410. New
functions for 32-bit words are added.

Autor: J. S. (munk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Falk,

ich verwende die 20080610er-Version. Bei mir funktioniert die 
mitgelieferte Shell (utils\bin\sh.exe) nicht so wirklich. Die spuckt 
prinzipiell
      0 [main] sh 2848 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
    357 [main] sh 2848 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump

aus. Die Programme, die von der Shell ausgeführt werden, laufen aber 
irgendwie durch, d.h. es wird compiliert.

Gruß
Jürgen

Autor: testhro (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Unter Windows 2000 US/SP4/Upd1 kann ich die angehängte Datei ich mit dem 
WinAVR-20080610 nicht übersetzen. (Internal Compiler Error)
Mit Windows XP/SP1 funktioniert es.

Mit der Version WinAVR-20070525 funktioniert es unter Windows 2000
und Windows XP. Schon komisch...

Und bei beiden Versionen wird inline-Code erzeugt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was für ein Internal Compiler Error denn?

Autor: testhro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
testdly.c: In function '_delay_ms':
testdly.c:23: internal compiler error: Illegal instruction

siehe auch:
http://sourceforge.net/tracker/index.php?func=deta...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das würde ja bedeuten, dass das Compiler-Binary kaputt wäre (denn
eine "Illegal instruction" ist ein Trap auf deinem x86-System).
Dagegen spricht natürlich wiederum, dass es auf einer anderen
Windows-Version geht...

Ich fürchte, das wird ohne einen Debugger auf der Plattform, auf der
der Fehler auftritt, kaum zu lösen sein.

Autor: testhro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die binaries sollten zumindest auf beiden Systemen identisch sein.
Das habe ich schon getestet.

Totalcommander -> Synchronize Dirs -> by content

Der Fehler kommt auch, wenn ich WINAVR als Share vom WXP mounte,
und dann unter W2000 starte.

Da werd ich wohl mal den alten W32DASM rausholen und gucken
wo es da trapt.

Meld mich dann hier wieder.

Autor: testhro (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der Trap kommt... siehe Bild...

Falls noch Details gewünscht werden, nur zu.

Autor: Schrumpfkopf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche CPU steckt denn in dem W2k System? Vielleicht ist der gcc für 
modernere CPUs compiliert? cmovle klingt verdammt neumodisch :-)

Autor: testhro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... CMOVLE ...
>
> Added with AMD K6-2
siehe: http://www.nationmaster.com/encyclopedia/X86-instr...

Ich habe den Fehler gefunden.
Es liegt an der verwendeten CPU, die da nur ein Pentium MMX ist.
Der kann den CMOVLE noch nicht :-(


@Jörg Wunsch (dl8dtl):
Besteht Aussicht, das es dafür einen Patch gibt?

Autor: testhro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Als Zielplattform wird in der WinAVR-Doku neben NT/2K/XP immer
noch W95/W98 angeführt.
Da nimmt man normalerweise an, dass ein Pentium MMX auch noch tut :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
testhro wrote:

> Besteht Aussicht, das es dafür einen Patch gibt?

Schreib' nen WinAVR-Bugreport.  Eric wird sich dessen gar nicht
bewusst sein, dass ihm da bestimmte CPU-Typen reincompiliert werden.

Autor: jogging_cat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurde da mit dem CPU-Typ etwas geändert (cmovle )?
Ich habe einen K6-2 und WINAVR 20090313 und das gleiche Problem mit 
_delay_ms.

Grüße jogging_cat

Autor: gast2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es Pläne für ein neues WinAVR-Release?

Hintergrund: Im aktuellsten Release 20090313 befinden sich GCC 4.3.2 und 
libc 1.6.6.

Aktuell sind jedoch GCC 4.3.4 und libc 1.6.7 (wobei auch hier das 
Release vom 1.7.2009 schon etwas hinter dem CVS hinterher hinkt...)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  gast2 (Gast)

>Hintergrund: Im aktuellsten Release 20090313 befinden sich GCC 4.3.2 und
>libc 1.6.6.

>Aktuell sind jedoch GCC 4.3.4 und libc 1.6.7 (wobei auch hier das
>Release vom 1.7.2009 schon etwas hinter dem CVS hinterher hinkt...)

Und was passt dir an der aktuellen Version nicht? Grosse Bugs? Schlechte 
Performance?
Was kann die "neue" libc besser?

Nur weil es eine neue Sub-Sub-Sub Version gibt, ist dasd kein Grund zum 
Wechsel.

Never change a running system!

MFG
Falk

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nur weil es eine neue Sub-Sub-Sub Version gibt, ist dasd kein Grund
> zum Wechsel.

Naja, beim GCC gibt es immerhin schon seit einiger Zeit den 4.4.1, also
eine Änderung schon in der ersten Sub-Ebene. Trotzdem verwende ich
standardmäßig immer noch den steinalten 4.2.4, weil ich bei den neueren
Versionen bisher die für mich relevanten Innovationen (bzgl. der
AVR-Programmierung) noch nicht so richtig bemerkt habe.

Der 4.3.4 und der 4.4.1 sind aber trotzdem (als "experimental") auf der
Platte, damit ich, wenn ich von einem coolen neuen Feature erfahre, das
sofort ausprobieren kann :)

Autor: gast2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und was passt dir an der aktuellen Version nicht?

Ganz einfach: In der letzten Zeit sind so einige AVRs erschienen, die 
der 4.3.2 schlicht nicht kennt.

> Was kann die "neue" libc besser?

Da ich hier nicht seitenlang die Updates spammen will:

Schau einfach mal hier: 
http://cvs.savannah.gnu.org/viewvc/*checkout*/avr-...


Alles nach dem 13.03.2009 ist gefixt (Du wirst rudelweise bugfixes 
erwähnt finden) oder neu und somit im aktuellen Release nicht enthalten.

Autor: Al (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich muss den 4.4.1 testen, wegen dem neuen IRA feature, weil das ja 
hoffentlich ein paar Register Probleme lösen kann.

Ich habe allerdings das Problem, dass ich es nicht schaffe diesen in 
WinAVR zu integrieren.

Benutze Cygwin um ihn zu configuren und zu maken, dann hab ich 
allerdings das Problem dass ich mir nicht sicher bin, wie ich weiter 
vorgehe damit ich ihn unter AVR Studio auch nutzen kann. Wenn ich den 
frsch gebauten einfach als Compiler auswähle im Studio, gibts Error im 
Sinne von, er findet die Standard Bibliotheken wie stdio usw nich...
Manchmal findet er dann auch den cc1 nich usw...

Gibts da irgendwo ein gescheites Tut, oder kann mir jemand die 
kritischen Schritte aufzählen?

Nich aufregen über soviel Unwissenheit auf einmal, büdde!
hänge da jetzt schon min ne woche dran, plz help!

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Al schrieb:
> Hi,
>
> ich muss den 4.4.1 testen, wegen dem neuen IRA feature, weil das ja
> hoffentlich ein paar Register Probleme lösen kann.

Was ich bisher von IRA für avr gesehen hab, war nicht erbaulich... aber 
sei's drum.

> Ich habe allerdings das Problem, dass ich es nicht schaffe diesen in
> WinAVR zu integrieren.
>
> Benutze Cygwin um ihn zu configuren und zu maken, dann hab ich
> allerdings das Problem dass ich mir nicht sicher bin, wie ich weiter
> vorgehe damit ich ihn unter AVR Studio auch nutzen kann. Wenn ich den
> frsch gebauten einfach als Compiler auswähle im Studio, gibts Error im
> Sinne von, er findet die Standard Bibliotheken wie stdio usw nich...
> Manchmal findet er dann auch den cc1 nich usw...

Du machst wöohl nur den Compiler und nicht auch die ganzen Libs und all 
das Zeug.

Als Quick & Dirty kannst du irgendwo einen offiziellen avr-gcc 
installieren und nur den cc1 bzw. cc1plus mit den selbstgestrickten 
ersetzen.

Johann

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.