hallo zusammen,
ich habe mir in vorgenommen mir einen der oben genannten avr c-compiler
zu kaufen. doch momentan bin ich eher verunsichert, weil ich eben nicht
weiss welcher der bessere für mich ist.
der codevision kostet ca. 160
der imagecraft kostet ca. 250
wodurch ensteht dieser preisunterschied?
wie ich gelesen habe wird bei codevision sogar eine LCD und i2c lib mit
dabei geliefert.dies wird so wie es aussieht nicht beim icc gemacht.
wieso ist er dann teurer? ...ich habe einiges über icc und cv im
avrfreaks forum gelesen aber gehlofen hat es mir bisher nicht.
der eine sagt icc ist toll ein anderer sagt cv wäre besser.
aber richtige gründe hat keiner genannt.
was nutzt ihr denn so?...und wie sehen eure erfahrungen aus?
ich wäre über jedes feedback dankbar bevor ich nachher geld in den sand
seztzte..:)
gruss,
marcel
Hallo Marcel,
Du kannst Dir von beiden Compilern Demos kostenlos laden. Mach das bitte
unbedingt ! Vielleicht willst Du dann garkeinen von beiden. So geht es
mir.
Michael
Wie währe es denn mit dem AVR-GCC? Der kostet garnichts, und genügend
Codeschnippsel (Stichwort LCD, I²C, ...) gibt es überall im Internet!
Also ich kann ihn nur wärmstens empfehlen.
Man braucht nur noch eine geeignete Entwicklungsumgebung. Ich
missbrauche immer MSVC++, aber UltraEdit oÄ. sind ebenfalls geeignet.
Mit Ausnahme des IAR habe ich bereits alle C-Compiler für die AVRs
eingehend getestet und bin letztendlich immer wieder zu dem GNU Compiler
zurückgekehrt. Das liegt aber weniger daran, dass er nichts kostet,
sondern weil er ganz einfach de fakto mit Abstand der beste Compiler für
die Atmels ist. Und zwar aus folgenden Gründen:
1.) Er produziert besseren und kompakteren Code
2.) Er hat deutlich (!) weniger Bugs
3.) Es gibt umfangreichen Programmcode für viele Einsatzgebiete
4.) Er hat keine Klicki-Bunti Oberfläche, sondern zwingt den
Programmierer, sich mit der Materie zu beschäftigen!!!
Den GNU Compiler gibt es schon viele Jahre für die verschiedensten
Plattformen und Prozessoren, vom Palm Pilot bis zum Grossrechner, vom
kleinen 8-Bit AVR bis hin zum superskalaren 64 Bit RISC-Prozessor und er
ist einer der ausgereiftesten Compiler, die es überhaupt gibt. Und es
ist logisch, wenn es solch ein Produkt zum Nulltarif gibt, dass dies so
manchen Herstellern kommerzieller Produkte ziemlich stinkt.
Daher sind Aussagen bezüglich der Qualität von Compilern, wie man sie in
den Diskussionsforen findet (avrfreaks!), immer sehr kritisch zu
betrachten und es werden hier oft Gerüchte gestreut. Man sollte daher
gewisse Aussagen zu gunsten kommerzieller Produkte stets kritisch
hinterfragen und oft stellt man fest, dass hier keine persönliche
Erfahrungen berichtet werden, sondern dass von Nutzniessern die
Werbetrommel gerührt wird. Spätestens wenn man den Namen des
"hilfreichen Berichterstatters" auf der Webseite einer Handelsfirma oder
gar der des Herstellers wiederfindet, sollte man merken wo man dran ist.
Aber hier kann sich schliesslich jeder selbst ein Bild machen, Google
ist in diesem Fall dein bester Freund.
Auch sollte man bedenken, dass schöne bunte Fensteroberflächen nichts
bringen, wenn das was dahinter steckt nichts taugt und die verlockenden
all-inclusive Libraries entpuppen sich schnell als wertlos, wenn man
sich nur einen Finger breit neben den (wenigen!) Standardbauteilen
bewegt, für die die Routinen gemacht sind.
Soweit meine 0.02$ zu diesem Thema!
MfG Notker
Hm, ich hab mich mit dem AVR GCC noch nicht wirklich beschäftigt, und
mit den teuren C-Compilern noch gar nicht. Aber ich habe mal gehört, der
AVR GCC soll gar nicht mal so toll optimierten Code erzeugen. Zumindest,
wenn man sich den erzeugten Code in ASM anschaut. Er soll ziemlich viel
unnötigen Programmcode erzeugen. Wie der Vergleich mit den
professionellen Produkten aussieht weiß ich nicht. Kann natürlich sein
das die noch schlechter sind.
Gegen KlickiBunti hab ich nichts, wenn es mir die Arbeit erleichtert.
Ich will Programme für den AVR erstellen und mich nicht mit der
Installation und dem Umgang mit dem AVR GCC rumschlagen. Bei solchen
Teilen gehen 20-40% der Entwicklungszeit in den Compiler, nicht in das
Programm.
Wenn ich wissen will, wie der AVR Tickt nehm ich ASM und das Datenblatt
Ich arbeite mit CodeVision, neueste Version.
Die Arbeitsoberfläche ist an Keil's µVision angelehnt, also mit
Projekt-Browser und Syntax Coloring, auch im Ausdruck!
Der Nachteil von CodeVision ist z.Z., das Programm ist noch nicht
fertig. Double-Berechnungen werden wie float berechnet. Und
Float-Berechnungen werden nur mit 5-stelliger Genauigkeit(statt
6-stellig, ANSI!) berechnet.
CodeVision hat alle Chancen zum AVR-Standard-Compiler.
Norbert
Kann mich Notker's Meinung nur anschließen.
Wenn man einmal gelernt hat mit dem GCC umzugehen, dann kann man mit
wenig Lernaufwand alle möglichen Controller und Prozessoren
programmieren, ohne sich immer wieder in ein neues Entwicklungssystem
einarbeiten zu müssen. Und der Support ist meistens besser als bei
kommerziellen Compilern: bei mspgcc z.B. werden gemeldete Bugs i.d.R.
innerhalb von wenigen Stunden gefixt, möchte mal sehen welcher
Softwarehersteller das macht. Und zur Not kann man auch mal selber Hand
an den Sourcecode des Compilers legen.
Hallo Marcel,
ich habe den CodeVision und den Imagecraft Compiler vor einiger Zeit
getestet:
- sehr schlechter Code
- Fehler beim Übersetzten (von ANSI-C)
...
Leider habe ich bis jetzt nicht AVR-GCC getestet, was ich aber unbedingt
nachholen muss !
Gruß
Matthias
hi zusammen,
ich möchte mich erstmal für eure beteildigung bedanken.
also ich programmiere jetzt schon länger mit dem gcc.
was mich persönlich stört, dass stanadard befehler wie sprintf() oder
sonstige ansi c lbrs einfach fehlen.
desweiteren habe ich ziemlich lange gebraucht um
GCC, UE und das Studio gescheit zum laufen zu bekommen.
desweiteren hänge ich alle paar minuten beim gcc vor einem neuen
problem. z.b ich versuche mir eine volatile variable mit dem studio
anszuschauen...geht aber nicht weil es durch das neue objtool nicht
unterstützt wird. aber bis ich mal wieder da drauf gekommen bin sind
stunden vergangen.
im allen zusammen bin ich der meinung das wenn man diese problemem aus
dem weg schaffen kann wesentlich zeit sparen kann.
und darauf kommt es mir eigentlich an.
fazit:
jetzt bin ich noch verwirrter..:D
Hallo zusammen,
in der laufenden Diskussion stelle ich z.T. eine gewisse Unschärfe in
den Argumenten, für oder gegen einen Compiler, fest.
Es werden Nachteile/Fehler eines Compilers angeführt, aber kein
konkretes Beispiel für solche Fehlfunktionen aufgezeigt. Desweiteren
wird nicht gesagt welche Versionen miteinander verglichen werden.
Wenn man den Compilerherstellern(egal welcher) glauben darf, sind 90%
aller Fehlfunktionen auf Fehlbedienungen des Users zurückzuführen. Das
gilt für Errors, Warnings und Codeeffizienz.
Norbert
Achso, ich hab' zwar geschrieben was ich an CodeVision bemängel, aber
nicht nicht, was gut finde.
Gut finde ich: Die Optik und das Feeling einer modernen IDE.
Das problemlose Zusammenspiel mit AVRStudio 3.55.
Der Projekt-Browser. Bei einem Projekt mit
mehreren .c- und .h-Dateien eine enorme Hilfe.
Der CodeWizard für Initialisierungs-Routinen.
Für Einsteiger in die AVR-Welt eine große Hilfe.
Lib-Dateien für div. externe Hardware.
Der unverzügliche Service des Verfassers von
CodeVision. Ich habe mal das fehlen des
%f-Spezifizieres bemängelt. Innerhalb von 24-Std.
hatte ich per eMail eine neue Programmversion
auf dem Rechner.
Und dann gibt es noch einen organisatorischen
Grund für die Wahl von CodeVision:
In unserer Entwicklungsabteilung kann jeder
Mitarbeiter ohne Lernaufwand in das Projekt
eines ehemaligen Kollegen einsteigen.
Norbert
Hi Norbert,
auch meine Meinung.
Wenn jemand sagt, der Code ist ineffizient, dann bitteschön auch ein
Beispiel dazu mit Sourcetext und dem daraus erzeugtem Assembler.
Alles andere ist reine Polemik.
Bei den Libraries bin ich der Meinung, die Standard-Bibliotheken müssen
gut sein.
D.h. schnelle Routinen für 16- und 32-Bit Multiplikation und Division
sowie für 32-Bit-Floating-Point, sowie vollständige und möglichst
bugfreie Bibliotheken von printf(), scanf().
Das mit LCD und I2C ist nebensächlich, da zu speziell (nur bestimmte
LCD, I2C, nur bestimmte Portpins, nur bestimmte Quarzfrequenzen). Kann
mir nicht vorstellen, daß das einer echt universell hinkriegt und dann
auch noch bugfrei.
Speziell für den AVR sollte es auch möglich sein, Variablen in allen
Speicherbereichen (Register, I/O, RAM, EEPROM, Flash) zu definieren, und
dann auch die dafür optimalen Befehle zu verwenden.
Also wenn ich z.B. in Assembler extrem oft benutzte globale Variablen in
Registern plaziere, sollte daß auch ein C-Compiler können.
Und ein printf() sollte auch Daten direkt aus dem Flash ausgeben können,
ohne sie zuerst in den SRAM kopieren zu müssen.
Der Compiler sollte auch selber wissen, daß zum Setzen eines Bits im I/O
der SBI-Befehl gut ist, ohne das ich "ASM SBI" schreiben muß, d.h. ich
will ANSI-C konform
PORTB &= ~(1<<PORTB0);
schreiben können und er macht daraus eben CBI.
Ob es aber einen solchen Compiler gibt, weiß ich leider auch nicht.
Peter
Hm, ich weiche damit zwar etwas von der eigentlichen Diskussion ab, aber
der AVRco Pascal Compiler kommt Deiner Beschreibung schon ziemlich nahe.
Es ist z.B. kein Problem, Variablen in verschiedene Speicher und
Speicherbereiche zu legen, Bitdefinitionen in beliebigen Speicherzellen
durchzuführen usw.
Die LCD Routine setzt zwar eine bestimmte Anschlußbelegung voraus, was
aber aus Speicher- und Performancegründen gemacht wurde. Die Routine
läuft mit drei LCD Controllern bei allen Frequenzen und bisher konnte
ich noch keine Bugs feststellen, ebenso bei der I2C Routine. Die gibt es
jetzt auch wahlweise softwaresimuliert oder für die TWI Schnittstelle.
Der einzige Nachteil dieses Compilers ist wirklich nur der Preis. Dafür
gibt es eine Demoversion, die nicht nur 2kB wie alle anderen, sonder bis
zu 4kB Programmcode erstellen kann
Hier mal ein Beispiel (gekürzt) für eine Variablendeklaration
----------------------------------------------------
Implementation
{$IDATA}
{--------------------------------------------------------------}
{ Type Declarations }
type
{--------------------------------------------------------------}
{ Const Declarations }
const
// these 2 constants !must! be provided by the user
Date : string = 'dd.mm.yyyy';
Time : string = 'hh:mm';
NetErrors : array[TNetErrorType] of string[15] = ('OK', 'ChkSumErr',
'SndPktErr',
'NoAknErr',
'PktSizeErr');
{$EEPROM}
StructConst
eDummy : word = 0; // first 2 bytes
in AVR EEprom not useable
// these 9 constants !must! be provided by the user
Net_ARPTimeOut : Byte = 100; // Systicks !!!
Net_ARPRetry : Byte = 3; // Request retries
Net_SendTimeOut : Byte = 50; // Systicks !!!
Net_SendRetry : Byte = 1;
{--------------------------------------------------------------}
{ Var Declarations }
{$PDATA}
var
LED3[@PortE, 6] : bit;
LED4[@PortE, 7] : bit;
Hier wurden Konstanten und Variablen in verschiedenen Speicherbereichen
definiert, wobei das nur ein Teil davon ist.
Gruß
Markus
