|
Anzeige
|
Codevision Compiler oder AVR-GCC?
Gast
#1144053
Hallo!!! Ich will meine AVRs nun auch in C programmieren, Vorkentnisse in C hab ich schon, habe vorher oder besser noch immer meine PICs mit CCS Compiler programmiert. AVRs wurden bisher nur mit Bascom programmiert. Welche Vor- Nachteile hat Codevision gegenüber AVR-GCC???? Mit was würdet ihr anfangen?? Was würdet ihr mir empfehlen?? MFG
Gast
#1144119
AVR-GCC ist preiswerter:) ich bin mit cv glücklich, der compiler ist gut gelungen. Der Wizard ist auch was wert, vor allem für einsteiger. Andererseits kenne ich leute, die GCC dem cv vorziehen aus gewohnheit. C Regelwerk muß Du dort und dort beachten. also ausprobieren! ipirk wrote: > Welche Vor- Nachteile hat Codevision gegenüber AVR-GCC???? Vorteil: Support, neue AVRs werden schneller übernommen, z.T. einfachere Syntax (speziell beim Zugriff auf Flash und EEPROM) durch Compiler-spezifische Zusätze (die allerdings nicht vom ANSI-Standard abgedeckt und dementsprechend nicht portierbar sind!) Nachteil: Kostet, sobald man mehr als 1 KiB Code haben will, nicht portierbare nicht-ANSI-Erweiterungen > Mit was würdet ihr anfangen?? Was würdet ihr mir empfehlen?? Nimm den AVR-GCC. Der kostet nix, Du arbeitest mit ANSI-C und gewöhnst Dir keine Sachen an, die bei anderen Plattformen u.U. nicht funktionieren. V.a. besteht beim CodeVision die Gefahr, dass man den Code Generation Wizard zu intensiv nutzt. Der generiert extrem schwer wartbaren Code, der bei Änderungen bzw. Fehlersuche ganz übel ist. Ich habe mit CodeVision angefangen und bin auf AVR-GCC umgestiegen und bereue es nicht...
Gast
#1144144
ANSI-C wird von cv auch supported wt wrote:
> ANSI-C wird von cv auch supported
Was willst Du damit sagen? Dass man in CodeVision auch ANSI-C
programmieren kann? Klar versteht der CodeVision auch ANSI-C, aber er
hat eben auch einige eingebaute Features, die dazu führen, dass man u.U.
vergisst, wie ANSI-C geht...
Gast
#1144160
wenn Du vernünftigen Programmierstiel hast, ist Tooling egal. Sonst darfs Du ja kein neues Auto kaufen, weil man mit ESP, ABS usw. es verlernen könnte, zu fahren:)))
Gast
#1144169
Meine sehr persönliche Meinung zu CodevisionAVR: Sehr professionell gemachter Compiler. Ausgezeichneter Code-Wizard, der dir ein fertiges Programmgerüst mit der gesamten Hardware-Initialisation und verschiedenen Standard-Funktionen (z.B. UART senden und empfangen, Timer, ISR) in wenigen Minuten liefert. Als Programmier-Anfänger habe ich sehr viel gelernt, in dem ich mir den automatisch erstellten Code des Codewizards genauer angesehen habe. Teilweise kann man auch den Quelltext der Libs einsehen. Die mitgelieferten Libs sind ausgereift und ersparen dir bei Standardaufgaben einen Haufen Arbeit. Ein Teil der Libs ist allerdings im Compiler "eingebaut" und deshalb ohne Sourcecode. Die neueste Version bietet sehr viel Komfort beim Programmerstellen, der neue Editor hat viele nützliche Funktionen, z.B. zeigt er dir korrespondierende Anfangs- und Endklammer bei Bedarf farbig an. Bei verschachtelten Funktionen über hunderte Zeilen ist das ausserordentlich hilfreich, wenn du mal einen Fehler suchst. Es gibt einen Code-Navigator, der dir sämtliche Funktionen und Variablen in einer Baumstruktur anzeigt, durch Anklicken kommst du sofort zur entsprechenden Stelle im Quelltexteditor. Das Programm kann nach dem Kompilieren und dem Build sofort auf den AVR geflasht werden, die Software dafür ist "eingebaut" und funktioniert mit verschiedener Programmier-Hardware (z.B. AVR-ISP, AVR Dragon, STK500 etc.). Du brauchst dich nicht mit irgendwelchen kryptischen Make-Files herumschlagen, einfach Code schreiben, auf die "Build"-Taste drücken, fertiges Programm auf den AVR flashen. Einziger Nachteil: CodevisionAVR kostet natürlich was. Aber der Preis ist für die gelieferte Leistung sehr moderat und mehr als gerechtfertigt. Ausserdem kannst du dir ja eine kostenlose Demo-Version mit voller Funktionalität herunterladen. Bei der kostenlosen Version ist lediglich die Code-Größe beschränkt und ein paar Libs fehlen. ipirk wrote: > Mit was würdet ihr anfangen?? Was würdet ihr mir empfehlen?? Ich würde (und hab selber) angefangen mit avr-gcc. Oberfläche Ein Compiler ist ein Compiler ist ein Compiler. Als solcher kommt avr-gcc auch daher: Es ist ein Compiler, kein riesiges, untrennbar mit irgendeiner Oberfläche verbündeltes Konstrukt. Nichtsdestotrotz gibt es Oberflächen für avr-gcc: -- AVR Studio -- Programmer's Notepad -- Auch mal ne shell/Eingabeaufforderung -- Code::Blocks -- Was selbst angepasstes: JEdit, Emacs, TextPad, ... -- Eclipse womöglich? Dinge wie das ober erwähnte Bracket-Matching sind heutzutage Standard, ebenso: Syntax-Highlight, Code Folding, Code Outlining, Autocompletion, Refactoring, Projektverwaltung, ... Vielleicht dauert es etwas länger als mit einer Mauszauberer-Oberfläche bis zum ersten HalloWelt, dafür versteht man, was man gemacht hat. Und irgendein Code der hübbsch funktioniert von dem man aber nicht weiß was er wirklich macht, da braucht man die Zeit dann irgendwann später für's Verstehen oder die Nervem beim Debuggen... make Jedem steht frei, C-Projekte über make generieren zu lassen. Oder über shellscripte. Oder über eine Oberfläche wie AVR-Studio. Oder Apache ANT. Oder, ... Kosten avr-gcc kostet dich nichts. Upgrades/Weiterentwicklung gibt es ständig. Plattformunabhängigkeit avr-gcc läuft auf unterschiedlichsten Plattformen, am üblichsten sind wohl MinGW/MSYS (MS-Windows) und Linux. Support Es gibt zahlreiche Foren wie mikrocontroller.net, roboternetz.de oder avrfreaks.net, wo du Fragen zu avr-gcc und avr-tools stellen kannst. Das reicht von Anfängerfragen bis zu Fragen zum Eingemachten, die etwa unter http://lists.gnu.org/archive/html/avr-gcc-list/ abgehandelt werden. Dort sind dann auch avr-tool Entwickler wie Anatoly Sokolov, Eric Weddington, Jörg Wunsch et al. ansprechbar. Allerdings sollte man dort keinen Fragen stellen, die ein C-Buch oder AVR-Manual beantworten kann... Ich hatte nur 1x wirklich was zu meckern und hab das in einer Mailingliste gepostet. Nichtmal ein Fehler, nur umständlicher Code. Es konnte für die Mainline nachvollzugen werden und ein paar Tage später war das Problem von den Cracks behoben und in der nächsten gcc-Release enthalten. GCC GCC setzt sich immer mehr auch im professionellen embedded-Umfeld durch. Alle GCCs ticken gleich. Egal, ob sie für Hänflinge wie 8-Bit AVR übersetzen oder 64-Bit Boliden wie Itanium, unter MS-Windows laufen, unter Linux, SunOS oder hp-ux. Das Aufgebot an Entwicklern, die GCC entwickeln, ist beachtlich; wobei zugegebenermassen im AVR-Backend die Entwickler etwas dünn gesät sind. Mag ein proprietärer Compiler auch etwas besseren Code liefer, GCC ist wie gesagt ständig im Fluß und wird verbessert, und für private Projekte reicht die Güte allemal. Was ich aus avr-gcc raushole ist dich an Assembler (zugegeben, ich weiß rect gutwie gcc intern tickt), und ich hab da wirklich nix zu meckern -- Und wenn: Es steht jedem frei, GCC und die Tools zu verbessern und daran mitzuwirken! Johann
Gast
#1144319
> Mag ein proprietärer Compiler auch etwas besseren Code liefer, GCC ist Gerade hier schneidet der CV aber schlechter ab als der GCC. In vielen Fällen tut sich da zwar nicht viel aber sobald es ans Eingemachte geht wie verschachtelte Schleifen, viele lokale Variablen (direkt oder temporär vom Compiler benutzte), Struktur- oder Arrayzugriffe, geht der CV in die Knie. Also: Der Vorteil des CV als Compiler ist seine bessere (sprich unkomplizierte) Unterstützung des AVR, die Stärke des GCC liegt in der Codeoptimierung. Das der GCC noch 27 andere Prozessoren und elf Betriebssysteme unterstützt nützt einem AVR Programmierer hingegen nicht viel. Zumindest dann nicht wenn man ohnehin unter Windows arbeitet.
Gast
#1144320
NAchtrag: Wenn es um Gleitkomma geht macht der CV den GCC allerdings nass. Wobei ich mir hier die Frage stelle ob der CV so gut oder der GCC so schlecht ist ;). Gast wrote: > NAchtrag: > Wenn es um Gleitkomma geht macht der CV den GCC allerdings nass. > Wobei ich mir hier die Frage stelle ob der CV so gut oder > der GCC so schlecht ist ;). Die Frage ist auch, ob die "nasse" Arithmetik IEEE-konform ist? Also Dinge wie NAN, INF etc. korrekt behandelt? Rounding Modes und Guard-Bits beachtet? Ansonsten spielt man da in einer anderen Liga und vergleicht u.U. Äpfel mit Rosinen. Für nicht-FP Code hätte ich gedacht, daß ein Compiler, der speziell für AVR geklöppelt wurde, besseren Code macht als ein GCC, dessen Lebenszweck ja in erster Linie 32-Bit Architekturen sind... Johann
Gast
#1144402
Irritiert mich etwas, dass gerade die gcc-Kenner hier nicht erwaehnen, dass der generierte Code der neuesten gcc-Versionen anscheinend immer groesser wird - ein Nachteil einer eierlegenden Wollmichsau, Aenderungen fuer andere Platformen schaden schnell mal der "eigenen" Platform... Wobei man an allerlei Schaltern spielend vieles davon wieder korrigieren kann, oder doch zumindest weitgehend, so dass selten ernste Probleme auftreten. Aber es stimmt schon, das kommt vor.
Gast
#1144475
Hat eigentlich schon mal jemand einen Blick auf den MikroC, und vor allem auf den erzeugten Code, geworfen ? http://www.mikroe.com/en/compilers/mikroc/avr/ Ja. Allerdings weniger auf dessen Optimierung als auf andere "Qualitäten": Beitrag "Telegramm[3] |= (1<<2) legal?"
Gast
#1144495
Da gibt es schon einige Beiträge zu: http://www.mikrocontroller.net/search?query=mikroC+&forums[]=1&forums[]=19&forums[]=9&forums[]=10&forums[]=2&forums[]=4&forums[]=3&forums[]=6&forums[]=17&forums[]=11&forums[]=8&forums[]=14&forums[]=12&forums[]=7&forums[]=5&forums[]=18&forums[]=15&forums[]=13&forums[]=16&max_age=-&sort_by_date=0#results, aber an den gcc dürfte es nicht rankommen. ;-) Sehe ich das richtig und MikroC sitzt in Belgrad? Wie sieht's bei CodeVision eigentlich mit Unterstützung für ISO C99 aus? Der Standard ist ja nun auch schon 10 Jahre alt, und nach 10 Jahren war die Umsetzung des Vorgängerstandards ANSI C89 (aka. ISO C90) eine völlige Selbstverständlichkeit, ohne die keiner mehr hätte einen Compiler verkaufen können. Macht mich nur immer stutzig, wenn ich in so einem Zusammenhang von ,,ANSI-C'' lese. Peter Stegemann wrote: > Irritiert mich etwas, dass gerade die gcc-Kenner hier nicht erwaehnen, > dass der generierte Code der neuesten gcc-Versionen anscheinend immer > groesser wird - ein Nachteil einer eierlegenden Wollmichsau, Aenderungen > fuer andere Platformen schaden schnell mal der "eigenen" Platform... Ja, stimmt leider. Aber zum einen ist GCC im Fluß, wie es so schön heisst, zum zweiten stört das bei den meisten Projekten nicht weiter und drittens kann man auch ältere Versionen von avr-gcc einsetzen. Was das "nicht erwähnen" angeht: Teilweise wird ja mit Schuhen und Strümpfen über einen hergefallen, wenn man erwähnt, daß man einen gcc 3.x im Einsatz hat: Was das denn für altes Zeug sei und es gäbe ja viel aktuellere Versionen und alles ist altbacken und überholt und supportet wird das eh nicht mehr und überhaupt und Rhabarber Rhabarber... Wenn man in einem Auto-Forum ne Frage zu einem alten Benz stellt, dann gibt's ja auch keinen Rüffel, warum man so ne alte Banane fährt und nicht das neueste Design-Modell... Ich selbst setze avr-gcc 3.4.6 ein, weil er nach meiner Erfahrung den schnellsten und besten Code erzeugt -- auch dann, wenn man für die neue Version alle DON'Ts vermeidet. avr-gcc 4.x wird aber besser; inzwischen ist er nur noch rund 5% schlechter als avr-gcc 3.4.6 und nicht mehr rund 10%. Im übrigen kann man auch ältere Versionen von avr-gcc mit neueren Versionen der avr-binutils resp. avr-libc verwenden, wenn man weiß, was man tut :-) So bekommt man etwa recht einfach eine ATmage328-Unterstützung im avr-gcc 3.4.x. Und immerhin ist "Latest 3.4.x" die "Preferred Version" laut avr-libc 1.6.4 README: http://cvs.savannah.gnu.org/viewvc/avr-libc/README?revision=1.5&root=avr-libc&view=markup Johann
Gast
#1145358
>Wie sieht's bei CodeVision eigentlich mit Unterstützung für ISO C99 aus? Schlecht. Es gibt praktisch nur die <stdint.h> und <stdbool.h>. >Für nicht-FP Code hätte ich gedacht, daß ein Compiler, der speziell für >AVR geklöppelt wurde, besseren Code macht als ein GCC, dessen >Lebenszweck ja in erster Linie 32-Bit Architekturen sind... Theoretisch macht der CV das vielleicht auch. Es hapert an den höheren Optimierungs Routinen. Da werden z.B. Offsets für Array Zugriffe berechnet, obwohl sich der Offset für den letzten Zugriff zwei Zeilen darüber gar nicht geändert hat. Solche Dinge sind nicht plattformabhängig und der GCC bemerkt sowas.
Gast
#1322623
Das absolute KO-Kriterium für Codevision ist, das er kostenpflichtig ist. Der GCC ist kostenlos, optimiert besser und ist obendrein gratis (kann man gar nicht oft genug sagen). Warum also sollte man noch Geld ausgeben? Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
