Hallo! Ist ein Umstieg von der 2005er auf die 2006er Version sinnvoll? ..oder meint Ihr mehr "Don't change a running System!" ;) Gruß, Techniker
Das kann doch keiner so pauschal beantworten. Eine Firma wird ihre Produktlinie durch ein WinAVR-Update nicht so einfach riskieren. Und einem Hobbyisten reizt es stets an der "leading edge" der Entwicklung mitzumachen. Lege dir halt ein Backup des jetzigen Systems an und teste danach das neue System auf Herz und Nieren.
Wenn du nicht die Software von anderen compilen möchtest die die neue Version haben, und wenn du keine neueren AVRs verwendest (z.B. EEPROM von megax8, ATtiny2313 usw.) dann lass die alte drauf.
Danke für eure Tipps! Hab jetzt mal auf einen alten Laptop das 2006er WinAVR drauf. Was ich jetzt schon vermisse ist beim comilieren die Auslastung von Flash und RAM... :( (..oder muß ich das erst irgendwo enablen?) Was hat sich sonst noch großartiges verändert, ausser das mit den Interrupts? Gruß, Techniker
> Eine Firma wird ihre Produktlinie durch ein WinAVR-Update nicht so > einfach riskieren. It depends. Wir haben in der Firma sehnlichst auf die neue Version gewartet, damit wir für den ATmega1281 endlich auch unter Windows und nicht nur unter Unix compilieren konnten. > Was ich jetzt schon vermisse ist beim comilieren die Auslastung von > Flash und RAM... :( Eric hat dies jetzt als privaten Hack ins avr-size-Kommando aufgenommen und den externen avr-mem.sh-Script dafür fallen lassen. Ich find's nicht so toll, aber er hat sich das nicht ausreden lassen. Damit funktionieren alte Makefiles nicht mehr wie gewohnt (das neue Template kann damit umgehen), und AVR Studio weiß wohl auch noch nichts davon. Du kannst dir aber ohne weiteres den avr-mem.sh-Script aus einer alten Version über die neue drüber installieren, dann sollte alles wieder tun. (Achtung, ich glaube mich zu erinnern, dass der Script, der mit der 2005er Version direkt mitkam, einige Bugs hatte. Suche nach dem Thread mit dem Update des Scripts im AVR-GCC-Forum von avrfreaks.net.)
Hab grad nochwas festgestellt: Hab ein altes Projekt umgeschrieben und es mit dem neuen WinAVR compiliert. Dauer: 2sec, keine Fehler, keine Warnungen. Jedoch macht der Controller garnichtsmehr! :-O Dann mit dem alten Compiler die Originalversion compiliert und auf den Controller -> alles läuft wieder! :-( Finde ich schonmal garnicht gut, wenn der neue Compiler anstandslos den Code umwandelt und dieser dann nicht lauffähig ist! :-( Damit hat sich für mich die Entscheidung mit dem Umstig auch erledigt...
> Finde ich schonmal garnicht gut, wenn der neue Compiler anstandslos > den Code umwandelt und dieser dann nicht lauffähig ist! :-( Solange du nicht analysiert hast, woran's liegt, bleibt natürlich immer noch der Verdacht, dass dein Code buggy ist, ihn der alte Compiler aber dennoch zu etwas Lauffähigem übersetzt hat. Das kannst du dann schwerlich dem Compiler anlasten.
> Was ich jetzt schon vermisse ist beim comilieren die Auslastung von > Flash und RAM... :( Ja entweder alle alten Makefile umschreiben oder ein Wrapper-Script schreiben: avr-size.sh: (kopieren nach c:\winavr\bin) #!/bin/sh # wrapper which uses new binutil avr-size avr-size -C --mcu="$2" "$1" Ja ich finde diesen privaten avr-size hack auch unschön, besonders wenn dieser Patch nicht offiziell in binutils source integriert wird.
> Ja ich finde diesen privaten avr-size hack auch unschön, besonders > wenn dieser Patch nicht offiziell in binutils source integriert > wird. Dazu ist er viel zu unfertig. Bedenke, die binutils unterstützen ...zig verschiedene Prozessoren/Architekturen. Damit sowas überhaupt nur eine Chance hätte integriert zu werden, müsste man es ziemlich allgemeingültig formulieren, damit wenigstens ähnliche Architekturen (also andere embedded controller, die von GNU unterstützt werden) das auch benutzen könnten. Dafür müsste man erstmal einen Entwurf machen und ihn mit den binutils-Entwicklern diskutieren. Eric weiß das auch und weiß, dass er keine Zeit hat, das jetzt und hier richtig zu machen, trotzdem wollte er diesen Hack unbedingt ins WinAVR reinnehmen.
Man sollte alte Versionen unbedingt aufheben, wenn man damit Projekte entwickelt hat. Ehe ich eine neue Version installiere, benenne ich die alte um, z.B. in "WINAVR1", inzwischen bin ich schon bei "WINAVR4". Ich hab mir dann auch Batch-Dateien geschrieben (1.bat ... 4.bat), mit denen dann die entsprechende Version in WINAVR zurückbenannt wird. Besonders in der neuen Version sind ja erhebliche Änderungen z.B. bei den Interrupts vorgenommen worden, was bei alten Projekten tonnenweise Fehlermeldungen bringt. Ich kopiere auch in den Includes alles aus den Unterverzeichnissen nach oben, damit man nicht immer extra die Pfade mit angeben muß. Bei der neuen Version wurden nämlich auch die Pfade geändert. Für neue Projekte versuche ich die neueste Version zu nehmen. Peter
@ Jörg: weisst Du eventuell welcher Intention Eric folgt ? Im allgemeinen sagt man ja - never change a running System ... @ Der wahre (Techniker) hast Du mal verucht zu ergründen woran es liegt ? Grüße, Stefan
> weisst Du eventuell welcher Intention Eric folgt?
Wohl ungefähr so, dass er ja den avr-mem.sh-Script ohnehin
selbst pflegen musste und dass er da auch gleich einen Hack
für avr-size stattdessen pflegen kann, braucht man keinen
zusätzlichen Script mehr.
> Man sollte alte Versionen unbedingt aufheben, wenn man damit > Projekte entwickelt hat. Ich kenne Leute (professionel arbeitende) die sich für jedes abgeschlossene Projekt einen Rechner mit dem vollständig installierten und lauffähigen Tooling in den Schrank stellen. Sollten dann nach einiger Zeit ein Problem auftreten, wird der Rechner aus den Schrank geholt und man hat eine lauffähige Umgebung unter der damals auch designed wurde und kann sofort loslegen. Nach z.B. zwei Jahren ist es fast unmöglich, noch einmal die gleiche Umgebung zu restaurieren...
Da ist VMware aber besser geeignet, als 10 Rechner im Schrank zu haben...
Hi Leute, kann mal kurz jemand erläutern in welcher Weise das makefile geändert werden muss, damit diese nette Anzeige wieder auftaucht? Auch das Wrapper-Script verstehe ich überhaupt nicht. Soll in in C:\winaver\bin die Datei avr-size.sh anlegen oder wie ist das gemeint?? Wie man merkt habe ich keine Ahnung von den tiefen des Compilers und hoffe daher auf eine einfache Erklärung :-) Dirk
> kann mal kurz jemand erläutern in welcher Weise das makefile > geändert werden muss, damit diese nette Anzeige wieder auftaucht? Hmm, genügt nicht das Installieren des letzten Servicepacks von AVR Studio sogar? Sorry, ich hab' kein Windows, aber mir ist so, als wollte Torleif Sandnes das auf Erics neue Methode ändern. > Auch das Wrapper-Script verstehe ich überhaupt nicht. Soll in in > C:\winaver\bin die Datei avr-size.sh anlegen oder wie ist das > gemeint?? Nein, du sollst dir das alte avr-mem.sh-Script (z. B. von avrfreaks.net) beschaffen und das dann nach <your winavr dir>/bin legen.
Wenn man auf die neueste WinAVR Version umsteigt, muss man seine alten Makefiles anpassen, damit man die %Auslaustung von Flash und Ram wieder sieht. Wie steht im Makefile sample in C:\Winavr\sample. Oder man kann ein Wrapper Script schreiben, wie ich es oben beschrieben habe, allerdings muss das Script avr-mem.sh heissen, habe aus versehen avr-size.sh geschrieben. >Hmm, genügt nicht das Installieren des letzten Servicepacks von AVR Studio sogar? Dieses neueste Servicepack verwendet für die vom IDE generierten Makefile "avr-size -C --mcu=" anstelle "avr-men.sh", was zur Folge hat, dass AVR Studio nun nur noch mit der von Eric gehackten binutils Version aus WinAVR 2006 kompatibel ist, und nicht mehr mit älteren WinAVR Version oder mit selbst kompilierten Packeten.
Hallo Peter, danke für diesen einfachen (und doch wirkungsvollen) Tip. MfG, Daniel.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.