Hallo Leute,
privat programmiere ich mit BascomAVR, jetzt muss ich jedoch
arbeitstechnisch scheinbar auf CodevisionAVR umsteigen.
- Wo sind die Vorteile des "teuren" CodeVisionAVR gegenüber dem
kostenlosen AVR-GCC?
- Wie läuft das bei CodevisionAVR mit (für mich elementar gewordenen)
Standardfunktionen wie die Ansteuerung von LCDs, das ansprechen des
AD-Wandlers etc.? (vielleicht bitte kurze Pseudecode-Schnipsel)
- Wie "schwer" ist es allgemein von einem Basic-Dialekt auf C
umzusteigen? Ist das ein "völlig anderes programmieren"??
...irgendwie habe ich vor dem Zwangumstieg ein wenig Angst, da ich
Bascom etwa seit 3 Jahren nutze und eben auch allgemeines Basic-Kind bin
- sei es früher QuickBasic, qBasic, PowerBasic sowie aktuell auch
VisualBasic.
mfg - Henning
in basic ist halt alles schon vorgegeben, in c musst du dir größtenteils
selber gedanken machen.
man muss halt verstehen was man macht. bascom ist da eher was für
anfänger, da eben viele sachen schon vorgegeben sind und sich kaum einer
die mühe macht einmal selber etwas zu programmieren (z.b. RC5 und der
gleichen).
Henning wrote:
> - Wo sind die Vorteile des "teuren" CodeVisionAVR gegenüber dem> kostenlosen AVR-GCC?
Er hat einige Codegeneratoren die z.B. die Timer, UART, ADC usw. alles
schon vorkonfigurieren.
Mal davon abgesehen, würde ich aber den GCC bevorzugen, denn dieser
hält sich (im Gegnsatz zum Codevision) an die C Standards, und er ist
eben kostenlos.
Benedikt K. wrote:
> Er hat einige Codegeneratoren die z.B. die Timer, UART, ADC usw. alles> schon vorkonfigurieren.
Wobei ich damit jedenfalls SEEEEEHR vorsichtig wäre. Zum einen sind die
AVR-Datenblätter wohl mehr als vorbildlich was die
Registerbeschreibungen angeht. Zum andren führen diese Codegeneratoren
geradewegs zum "Ich-bin-dumm-du-machst-das-drum" und zu Copy&Paste-Code.
Also ich mag Wizzards nicht, bzw. ich traue ihnen nicht zu, alles zu
wissem.
Ich hab z.B. den ICP1 zum Tastverhältnis messen gebraucht (SMT160) und
den OCR1B als 16Bit PWM (Heizleistung).
Dann schaut man einfach ins ATmega168 Datenblatt,
T1-Registerbeschreibung und setzt die Register entsprechend.
Sowas dürfte kein Wizzard können, da sich Capture und Comparemodus sehr
leicht gegenseitig stören können.
Peter
P.S.:
Nachdem ich erstmal in die Timer-Highbyte Falle getappt war, regelt der
Thermostat nun schön auf +/-0,01°C aus.
Ich habe lange mit Codevision gearbeitet, weniger mit dem Wizard als mit
der bequemen IDE und der doch recht guten Library. Aber jetzt nehme ich
WinAVR (eben doch viel näher am C-Standard), aber mit der (freien)
CodeBlocks IDE. Notepad++ und emacs etc. sind nicht so mein Fall. Auch
wegen meines Protel Simu, der kommt mit den Coff files des Codevision
Compilers nicht zurecht, mit den elf/dwarf2 files des GNU-CC aber schon.
Fried
Entscheidungen in Firmen über Entwicklerwerkzeuge sind nicht immer
(sogar eher selten) rational. Solange man damit leben kann, nimmt man
was vorgegeben ist.
Was einen übrigens nicht daran hindert, mal ein anderes Werkzeug zu
installieren und nebenbei als Weiterbildung zu evaluieren. Vielleicht
fällt den Kollegen, die zufällig über die Schulter schauen, auf, dass
dieses andere Werkzeug gar nicht so schlecht ist.
Man kann die Ergebnisse einer solchen Weiterbildung ganz vorsichtig beim
Mittagessen erwähnen. Was allerdings nicht geht ist penetrantes "mit GCC
wäre das nicht passiert!" oder "in GCC geht das so ..." Genörgel.
CodeVision ist afaik immer noch die preisgünstigste der kommerziellen
AVR-IDEs mit Compiler. IAR und Konsorten kosten deutlich mehr.
Der Code Generation Wizard von CodeVision kann ganz nett sein, wenn man
"mal eben schnell" was ausprobieren will und keine Zeit hat, die
Initialisierung im Datenblatt zusammenzusuchen und in Klartext
hinzuschreiben. Der erzeugte Code ist aber extrem wartungsunfreundlich,
da in den Steuerregistern keine Bitnamen benutzt werden, sondern die
Bitmasken als Hex eingefügt werden, so dass man bei Änderungen im
Datenblatt nachsehen muss. Für Projekte würde ich von solchen Wizards
abraten.
Generell haben kommerzielle Umgebungen den Vorteil des besseren Supports
(Unterstützung neuer Devices, technische Anfragen), aber das lassen sich
die Anbieter eben auch bezahlen. WINAVR mit AVRStudio oder anderen IDEs
ist eben kostenlos, dafür dauert es aber i.d.R. auch eine Weile, bis
neue Devices vollständig unterstützt werden und es können bei einem
neuen Release auch schon mal einige dickere Bugs drin sein (wie bei den
April-Versionen vom WINAVR geschehen), da diejenigen, die an der
Distribution arbeiten, darauf angewiesen sind, dass andere Leute das
Werk testen und eventuelle Bugs melden. Kommerzielle Anbieter können
sich so etwas nicht leisten, aber da sind es eben auch keine
"Ehrenamtlichen", die daran arbeiten...
Ich kann nur sagen, ich benutzte den CVAVR auch für größere Projekte und
bin sehr zufrieden. Nach kurzer Einarbeitung kamen schon meine ersten
Projekte zügig voran. Auch ich kam von Basic her über ASM und bin
dankbar für den Codewizzard, erleichtert er doch die Grundeinstellung
der SFR-Register erheblich was gerade dem Ungeübten anfänglich
schwerfällt. Der erzeugte Code ist übersichtlich und für mich leicht
nachzuvollziehen.
Nachteilig ist, dass man mit den Codewizzards schon bearbeiteten
Quelltext nicht direkt nachträglich manipulieren kann.
Also empfiehlt es sich "Hilfsprojekte" anzulegen, in denen man sich mit
dem Codewizzard austobt und dessen Ergebnisse ins Hauptprojekt zu
portieren.
Auch wird die Prototypenerstellung nicht unuterstützt.
Hier bin ich generell dazu übergegangen für jede Funktion die
Prototypendeclaration in umgekehrter Reihenfolge den
Funktionsdefinitionen voranzustellen. Das vermeidet Fehler bei der
Compilierung wenn Funktionen aufgerufen werden bevor sie definiert
wurden.
Kurz um ich bereue die private Investition nicht!
Ich bin auch mehr als zufrieden damit.
Hat sich über die Jahre gut entwickelt und ich habe verdammt viele
Projekte damit erfolgreich abgeschlossen.
Gerade die nicht C-conformen Erweiterungen haben es mir angetan :-)
Libs sind auch ok, Optimierungen ebenso.
Das einzige, was mich vor ca. 1 Jahr fast zum Wechseln gebracht hat, war
das Lizensgedöns. Das war nicht mehr tragbar, da ich öfter mit dem
Laptop bei Kunden unterwegs war. Einmal ist der ganze Mist sogar beim
Übertragen komplett abgeschmiert - da stand ich ganz ohne Compiler da
und hatte einen Termin. Ich habe jetzt eine freie Version :-)
>Vorteile von CodeVisionAVR gegenüber AVR-GCC
Codevision ist ein kommerziellen Produkt mit erstklassigem Support und
hoher Leistungsfähigkeit. GCC ist eine gigantische Softwarebaustelle
ohne klar erkennbare Linie.
Da gibts schon diverse Lösungen - allerdings betreibe ich das Ganze
gewerblich und mache aus diesem Grund keine Softwareschummeleien. Ich
habe ne ganz offizielle Version ohne Lizenskram.
> - Wie "schwer" ist es allgemein von einem Basic-Dialekt auf C> umzusteigen? Ist das ein "völlig anderes programmieren"??
Der Umstieg sollte nicht allzu schwer sein. Vorausgesetzt du hast dir in
Basic nicht zu viele Schweinereien angewöhnt.
Allerdings würde ich C nicht gerade als einsteigerfreundlich bezeichnen.
Man hat dort sehr viele Freiheiten durch die Anfänger auch erstmal böse
Fehler machen können. Vielleicht solltest du dir noch ein Buch über die
C Programmierung zulegen. Ein paar Tipps findest du hier:
http://www.mikrocontroller.net/buecher/
Ach ja und übe Fuse setzen! Negative Logik, beim CVAVR gilt Häcken == 0
== programmiert, kein Häckhen == 1 == unprogrammiert)
Im Fall des Verbrennens: externer Takt an XTAL 1 vollbringt das Wunder
der wiederbelebung.
;-)))
Jupp wrote:
> Codevision ist ein kommerziellen Produkt mit erstklassigem Support und> hoher Leistungsfähigkeit. GCC ist eine gigantische Softwarebaustelle> ohne klar erkennbare Linie.
Soso. Was wäre für dich eine klar erkennbare Linie? Vollständiger
C99-Support als Ziel beispielsweise? Eine große Anwenderschar?
Support bekommst du für GCC übrigens auch, wenn du willst. Warum auch
nicht? Wenn dir der kostenlose nicht genügt, nimmst du dir jemanden
unter Vertrag, der das für dich macht.
>Was wäre für dich eine klar erkennbare Linie?
Z. B. Codegröße und Ausführungsgeschwindigkeit optimieren. Wenn eine
neuere Version größeren Code erzeugt, als eine ältere, dann bringt mir
das nicht viel.
Wer auf einen Code-Generator nicht verzichten will und trozdem bei GCC
bleiben will: http://www.atmanecl.net/EnglishSite/softwareEnglish.htm
Desweiteren hat auch Imagecraft einen Application-Builder, der auch bei
der Free-Version voll funktionstüchtig ist.
Aber wie schon Peter Dannegger gesagt hat: "ich traue ihnen nicht".
Hingegen muss ich eingestehen, dass ich sie hin und wieder benutze, um
meinen Code zu kontrollieren.
Wow, ich hab mir mal den Wizard vom AtmanAvr angeschaut und bin positiv
überrascht :-)
Im Vergleich zu den Wizards : CodeVision, IO-Designer, AvrWiz, MakeApp
bekomme ich hier genau das was ich haben möchte. Und zwar jeden Teil
(UART, PORTS, TIMER, ADC .... ) in einer eigenen .c und .h Datei und nur
die gewünschten Settings sowie die zugehörigen Funktionsrümpfe nicht
mehr und nicht weniger.
Ob er es nun richtig macht, kann ich noch nicht beurteilen aber der
Code-Style in dem der Wizard sein Ergebnis präsentiert ist so neutral
gehalten das er gut zu meinem Style passt. Das hat mich bei den obigen
Wizards immer am meisten gestört, ich bekam immer eine Unmenge an
generierten Defines und Code-Schnipseln die nicht zu meinem Style
passten und ich vor der Aufgabe stand, entweder die Konfiguration zu Fuß
zu machen oder das generierte an meinen Style anzupassen. Beides war
immer sehr aufwendig.
Nun zum Hauptthema :
Ich denke, der Vorteil am Codevision liegt nur darin, dass er als
kommerzielles Produkt einem ganz anderen Support unterliegt als der
WinAVR. Für kommerzielle Entwicklungen würde ich auch immer zu
kommerziellen Produkten greifen bzw. bzw. nur kostenlose Tools der
Hersteller verwenden. Dies schützt mich hauptsächlich vor Fragen meiner
Vorgesetzten wenn tatsächlich mal eine Rückrufaktion wegen eines
Kompilerfehlers in der Firmware passiert. Und wer mit seinen Produkten
Geld verdient, sollte vor 500-1000€ für eine Entwicklungsumgebung nicht
zurückschrecken. Schließlich ist auch dies eine Firmeninvestition.
Vorteile CV:
+ Einfacher für den Einstieg durch (einfache) Lib (I2C, LCD usw. ist
schon drin).
+ Harvard Architektur wird direkt unterstützt ('flash' Attribut
für Pointer.
+ Sehr schnelle Gleitkomma-Arithmetik.
+ Sehr kurze Compilierzeiten.
+ Gute IDE (aber ohne Debugger-Support).
Nachteile:
- Lizenzmanagment (ich habe meine Liz. durch Neuinstallation
verloren, warte auf neuen Schlüssel)
- Optimierer deutlich schlechter als der vom GCC.
- Nur max. fünf Register werden für lokale Variablen verwendet,
der Rest landet auf dem Stack. Zuordnung erfolgt in der Reihe-
folge der Definition der Variablen. D. h. Schleifenzähler werden
nicht bevorzugt.
- Kein Linker. Soll aber angeblich mit der Version 2 kommen.
- Umständliches Flash-Tool.
- Ansteuerung des AVR-ISP mkII langsam.
