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
ich finde CodeVision genial, gut, hatte ein paar Macken, aber Pavel löst solche Bugs unglaublich schnell und ist dankbar über jede Rückmeldung
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
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.