Was ist mit 20080610? Soweit OK oder sind da mal wieder böse Verschlimmbesserungen drin? MFG Falk
>Schau doch ins Datenblatt.
Die Rache des Falk wird dich vernichten.
Der bastelt gerade an deiner Voodoo Puppe ;)
>Die Rache des Falk wird dich vernichten.
You made my day :-)
Kaum gabs mal ein, zwei unstabile, verbugte Versionen schon wirds dem WinAVR dauernd nachgetragen! ;)
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 :-)
@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.
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.
@ 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?
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.
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
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.
@ Simon K. (simon) >Kaum gabs mal ein, zwei unstabile, verbugte Versionen schon wirds dem >WinAVR dauernd nachgetragen! ;) Und welche war die Andere? ;-)
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
>Insgesamt waren es 4: Naja, die direkt davor liegende 20072112 hatte bei floats auch so ihre "Eigenarten". Beitrag "Winavr20071221 :-(" Oliver
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.
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.
Simon K. wrote: > Du kannst auch einfach in den avr-libc Bugtracker schauen. ...bzw. in den von WinAVR selbst.
>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! ;-)
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?
@ Klugscheisser Du studierst im Nebenfach Philosophie oder Germanistik, stimmts? :-)
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.
@ Klaus Falser: Wenn ich Dir auf irgendeine Weise behilflich sein kann.... :-)
@ 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
Im Changelog stehts immerhin: http://cvs.savannah.gnu.org/viewvc/*checkout*/avr-libc/avr-libc/ChangeLog?content-type=text%2Fplain&revision=HEAD > 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.
@ Falk:
[klugscheiss]
>sodass die Community das nicht erst per Trail & Error herausfinden muss
Du meinst 'Trial', oder?
Happy Trails to you!
[/klugscheiss]
:-D
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.
Hallo Falk, ich verwende die 20080610er-Version. Bei mir funktioniert die mitgelieferte Shell (utils\bin\sh.exe) nicht so wirklich. Die spuckt prinzipiell
1 | 0 [main] sh 2848 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION |
2 | 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
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.
Was für ein Internal Compiler Error denn?
testdly.c: In function '_delay_ms': testdly.c:23: internal compiler error: Illegal instruction siehe auch: http://sourceforge.net/tracker/index.php?func=detail&aid=2144298&group_id=68108&atid=520074
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.
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.
Angehängte Dateien:
-
CC1.PNG
28 KB
Der Trap kommt... siehe Bild... Falls noch Details gewünscht werden, nur zu.
Welche CPU steckt denn in dem W2k System? Vielleicht ist der gcc für modernere CPUs compiliert? cmovle klingt verdammt neumodisch :-)
> ... CMOVLE ... > > Added with AMD K6-2 siehe: http://www.nationmaster.com/encyclopedia/X86-instruction-listings 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?
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 :-)
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.
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
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...)
@ 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
> 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 :)
> 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-libc/avr-libc/ChangeLog?content-type=text%2Fplain&revision=HEAD Alles nach dem 13.03.2009 ist gefixt (Du wirst rudelweise bugfixes erwähnt finden) oder neu und somit im aktuellen Release nicht enthalten.
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!
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
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.