mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Codevison oder Imagecraft??


Autor: Marcel (Gast)
Datum:

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

Autor: Michael (Gast)
Datum:

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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich finde CodeVision genial, gut, hatte ein paar
Macken, aber Pavel löst solche Bugs unglaublich schnell und ist dankbar 
über jede Rückmeldung

Autor: Sascha Weitkunat (Gast)
Datum:

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

Autor: Notker (Gast)
Datum:

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

Autor: Markus Burrer (Gast)
Datum:

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

Autor: Norbert (Gast)
Datum:

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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: Matthias (Gast)
Datum:

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

Autor: Marcel (Gast)
Datum:

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

Autor: Norbert (Gast)
Datum:

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

Autor: Norbert (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Markus Burrer (Gast)
Datum:

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

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.