mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Codevision Compiler oder AVR-GCC?


Autor: ipirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ANSI-C wird von cv auch supported

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:)))

Autor: CodevisionFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;).

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja. Allerdings weniger auf dessen Optimierung als auf andere 
"Qualitäten": Beitrag "Telegramm[3] |= (1<<2) legal?"

Autor: ...... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gibt es schon einige Beiträge zu: 
http://www.mikrocontroller.net/search?query=mikroC..., 
aber an den gcc dürfte es nicht rankommen. ;-)
Sehe ich das richtig und MikroC sitzt in Belgrad?

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Johann

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 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.