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
SORRY AVR-GCC = WinAVR (hatte zur späten Stunde des Arbeitstages ein wenig Hirnverstopfung, AVR-GCC ist ja nur ein Compiler)
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.
@Jupp Das war hart. Ich maße mir das nicht an, da GCC nie probiert habe. ;-))
@ Crazy horse. für das ....gedöns habe ich eine probate Lösung gefunden.
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 sieht das eigentlich beim GCC mit Bitvariablen aus? Sehr nützlich und effektiv compiliert.
> - 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.
Bitte 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.