AVR C-Compiler Vor- und Nachteile

Hallo Gruppe,

ich m=F6chte in meiner Firma den Sprung von der 8051 Familie auf den AVR (AtMega324P) wagen. Die Vorteile bez=FCglich Funktionalit=E4t und Preis liegen auf der Hand. Nur die betriebssicherheit konnte ich noch nicht testen. Leider habe ich keinen C-Compiler f=FCr die AVR-Familie. Bis her habe ich mit Keil gearbeitet und (mehr oder minder) gute Erfahrungen gemacht. Ich br=E4uchte ein paar Erfahrungswerte, da mir ein Gesp=FCr f=FCr den "richtigen" Compiler fehlt. Er muss Leistungsstark bezogen auf seine Betriebssicherheit sein nicht zwingend geschwindigkeitsoptimiert. Compilerfehler, wie ich sie auch mehrfach bei Keil erlebt habe, verzeiht mir der Kunde und auch mein Chef nicht und viele Haare zum raufen fehlen mir auch ;-)) Falls es f=FCr die Bewertung noch wichtig seien sollte: Meine C Kenntnisse w=FCrde ich im unteren Mittelsegment einstufen. Die bisherigen Informationen die ich gefunden habe helfen mir leider nicht weiter. Ich bin um jeden Tip dankbar.

Reply to
Mark Kreso
Loading thread data ...

Du könntest mal Forth ausprobieren, gibt da einige freie System, wenn man es nicht selber schreiben möchte, und Compilerfehler sind bei der Einfachheit von Forth auch recht selten:

formatting link

Ich setze Forth zur Zeit auf einem größeren embedded System ein und macht viel mehr Spaß damit zu arbeiten, als mit C, denn gerade für Hardwareentwicklungen kann man viel interaktiver das System testen und entwickeln.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Google mal nach Winavr. Das ist GCC für die AVR Prozessoren.

Läßt sich einigermaßen problemlos installieren und geht wirklich gut.

Gruß

Stefan DF9BI

Reply to
Stefan Brröring

formatting link

Gruß Henning

Reply to
Henning Paul

Mark Kreso schrieb:

http://www.hpinfotech.ro/html/cvavr.htm

Grüsse, Andy

Reply to
Andreas Haimberger

Danke f=FCr die schnellen Antworten. Von den meisten habe ich schon was gelesen. Ich frage mich wo die Vor- und Nachteile liegen, wie sieht es mit dem Debugger aus. Taugt der was, wenn er vorhanden ist... Er muss nicht gratis sein. Mein Chef ist auch bereit daf=FCr Geld auszugeben (Was recht selten ist ;-)))

Gru=DF Mark

Reply to
Mark Kreso

Mark Kreso schrieb:

Debuggen kann man mit dem AVR-Studio von Atmel (Kostenlos).

HTH, Heiko.

Reply to
Heiko Lechner

Und natürlich das Tutorial

formatting link
auf der gleichen Seite. Der avr-gcc ist recht weit verbreitet, d.h. Compilerfehler wären wohl schon aufgefallen. AVRs sind natürlich Single-Source, ich habe mir mal sagen lassen dass die AVR-Megas mit den Zweierpotenzen als Nummer (d.h. die 16,32,etc.) i.a. längere Produktlebensdauern haben sollen als die mit den dreistellingen Nummern, die immer eine Variante mit spezielleren Funktionsblöcken sind. Hat jemand ein Quelle dafür?

Thomas

Reply to
Thomas Meier

Am Thu, 18 Oct 2007 06:30:17 -0700 schrieb Mark Kreso:

Hallo!

[C für Atmel]

Ich verwende WinAVR zusammen mit dem AVR-Studio von Atmel. Funktioniert bestens und echte Compilerfehler wären mir noch nicht aufgefallen. Ich hatte allerdings in einer alten Version des GCC das Problem, daß der Code, den der GCC aus dem Atmel Beispielcode für den Zugriff auf den das interne EEProm gemacht hat, zu langsam war. Das hatte zur Folge, daß das EEProm nicht beschrieben wurde. Hat mich damals allerdings doch einiges an Nerven gekostet das herauszufinden.

Aber auch das ging dann im AVR-Studio recht komfortabel.

Liebe Grüße, Thorsten

Reply to
Thorsten Oesterlein

Obwohl der GCC nichts kostet ist er ziemlich gut. Die Frage ist, ob du ausser der Funktion noch irgendeine Zertifizierung, Support oder einen Schuldigen brauchst wenn was nicht funktioniert. Das kriegst du z.B. bei IAR, lassen die sich aber fuerstlich bezahlen.

Anderenfalls wuerde ich nur einen kommerziellen Compiler nehmen, wenn der Kunde es wuenscht oder wenn du "neue" Features brauchst (z.B. Support fuer die ATmega256x mit Adressen >0xFFFF, da wuerde ich beim GCC noch Probleme erwarten weil es die noch nicht so lange gibt).

Micha

Reply to
Michael Baeuerle

Hallo Mark,

avrgcc ist ja schon empfohlen worden. Ich verwende als Programmierumgebung eclipse, da ich damit Java, avrgcc, C, C++ und PIC-Asssembler in einer Entwicklungsumgebung habe.

Grüße, Kurt

--
Kurt Harders
MBTronik - PiN GmbH
 Click to see the full signature
Reply to
Kurt Harders

Mark Kreso schrieb:

Also so schlecht, dass man als Programmierer im unteren Mittelsegment Compilerfehler im Keil findet, ist der Keil eigentlich nicht. Für den

8051 ist der Keil wohl der Standard schlechthin und ich habe mit ihm durchweg positive Erfahrung gemacht.

Die AVR-Familie würde ich jetzt auch nicht an erster Stelle empfehlen. Hier sehe ich eher Renesas und div. ARM-Controller. Letzter werden meines Wissens auch vom Keil unterstützt, dessen Entwicklungsumgebung Du ja schon im Schlaf kennst und das ist allemal produktiver, als eine neue Umgebung aufzusetzen.

Für produktive Umgebungen setzt man sonst gern die IAR-Compiler ein. Natürlich sind die auch nicht bugfrei (welcher Compiler ist das schon?), man bekommt aber tel. Support und zertifizierte Umgebung.

Dirk

Reply to
Dirk Ruth

Der Wikipediaartikel macht einem ja den Mund wässrig.

Jedoch konnte ich noch nie die UPN leiden. Einst war ich ein paar Tage gezwungen Postscript zu programmieren. Das hatte mich in meiner Meinung bestätigt.

Kennst Du Leute, die diese Abneigung gepflegt und dann doch überwunden haben?

--
Gruß, Raimund
Mein Pfotoalbum 
 Click to see the full signature
Reply to
Raimund Nisius

Dirk Ruth schrieb:

Kommt auch auf die Anwendung an. Ich arbeite sehr gerne mit dem IAR. Arm macht Sinn wenn man etwas mehr Leistung benötigt. AVR hat den vorteil dass man sehr viele Programmierlösungen findet.

Gerald

Reply to
Gerald Oppen

Ich habe mir einige AVR C Compiler (IAR, Codevision, Imagecraft, gcc) angeschaut und bin beim Imagecraft C hängengeblieben. Daß der was kostet, war mir egal, ich verdiene damit Geld, und dabei spielen ein paar 100 Euro für nen Compiler oder die 300 für den JTAG nicht die Rolle. Es muß funktionieren, bei Problemen will ich eine Telefonnummer, wo ich jemanden ans Rohr bekomme, den ich würgen kann, und ich muß effizient damit arbeiten können. Compilerdebuggen bekomme ich halt nicht bezahlt.

IAR ist bei Atmel sozusagen die Referenz, alle Beispiele sind damit compiliert worden, aber das Zeugs ist heftig teuer, so heftig, daß sogar ich in meinem Kaufzwang deutlich gebremst wurde.

gcc fand ich nicht wirklich gut an die AVR Eigenheiten wie getrennter Code/Daten Adreßraum angepaßt, und im allgemeinen hat der gcc eine Assemblersyntax, die recht deutlich von der vom Hersteller vorgegebenen abweicht, was ich als Nachteil oder zumindest Unbequemlichkeit empfinde.

Codevision fand ich eigentlich ganz ok, verhältnismäßig preiswert.

Der Imagecraft ist es dann geworden. Kann alles, was ich brauche, ist relativ nah an der IAR Syntax (zB bei den #pragmas) und den zusätzlichen Keywords, unterstützt alle Prozessoren, und wenn man mag, gibts dazu auch eine IDE, bei der man nicht viel nachdenken muß, sondern sich ganz auf seinen eigenen Code konzentrieren kann.

Wer das ganze nur als Hobby macht, hat natürlich andere Prioritäten.

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

Ist nur eine Frage der Gewöhnung und des richtigen Programmierstils. Wie der Wikipedia-Artikel schon schreibt, ist es eigentlich recht natürlichsprachig. Z.B. könnte man folgendes schreiben:

led on led off

"on" und "off" könnten dabei dann Wörter sein, die ein IO-Port-Bit setzen bzw. löschen, und "led" eine Konstante für die Bitnummer.

Wenn man mal ein paar Wochen drin programmiert hat, dann gewöhnt man sich daran. Und man sollte sowieso nie mehr als 3-4 Werte auf dem Stack innerhalb eines Wortes haben, dann bleibt es auch später noch leicht lesbar und man macht weniger Fehler.

Gegenüber Postscript gibt es noch einige schöne Dinge, wie z.B., daß man Wörter (=Funktion in anderen Sprachen) definieren kann, die den weiteren Eingabestrom lesen und interpretieren. So ist in ANS Forth z.B. kein Wort vorhanden, um die von C bekannten structs zu definieren, aber man kann es damit recht leicht und elegant selber implementieren und dann genauso wie den Rest der Sprache verwenden.

Das ist natürlich auch eine Herausforderung, denn man kann mit so einer Flexiblität auch unleserlichen Code schreiben. In den meisten Fällen kommt man aber gut damit aus, "normale" Wörter zu definieren, die nur Werte vom Stack lesen und wieder dort ablegen und das ganze in passend gewählte und kleine, wiederverwendbare Wörter aufteilt, die man in Dateien zu Schichten oder Libraries gruppiert, z.B. für die Abstrahierung der Hardware-Ebene, Anwendungsebene, GUI-Library usw.

Empfehlenswert für den Einstieg ist das Online-Buch hier:

formatting link

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

"Raimund Nisius" schrieb:

Mir geht es genau umgekehrt, ich ärgere mich über die 'neueren' Taschenrechner die mich dazu zwingen, einen zu berechnenden Ausdruck komplett umständlich einzutippen und am Ende steht das Ergebnis da... und wenn falsch=unplausibel, dann heisst es, die Eingabe editieren, Fehler suchen, u.U. alles nochmal von vorne... meist ist ne Klammer vergessen worden oder sowas.

wie umständlich!

Mit meinem alten Taschenrechnermodell rechne ich sowas wie sin(1-1/e^x)^2 so, wie schon in der Schule gelernt und wie ich es auch schriftlich rechnen würde, also "von innen nach aussen":

x eingeben, die [e^x] Taste drücken, dann die [1/x] Taste drücken, dann Vorzeichenwechseltaste, dann einen drauf [+1], dann 'Quadrat' und zum Schluss die Sinustaste... und die angezeigten Zwischenschritte geben manchmal schon ne Plausibilitätsabschätzung, falls vertippt.

Wenn du nachzählst, sind es weniger Tastendrücke (die Klammern fehlen). Jetzt meine Frage an dich: Wie rechnest du auf dem TR?

Vielleicht isses Gewohnheitssache, aber mir erscheint die UPN viel natürlicher. Auch, wenn ich schriftlich was ausrechne. Vermutlich, weil ich es so sehr gewohnt bin, Funktionen auf Argumente anzuwenden, ich denke einfach so.

Wie rechnest du z.B. eine Standardabweichung schriftlich?

Ich würde eine Tabelle machen und dann: Erst die Abweichungen errechnen (eine Spalte), dann die Abweichungsquadrate (zweite Spalte), dann aufsummieren, dann noch final 1/n. (Eigentlich würde ich gleich mit den Abweichungsquadraten anfangen). Und hätte mein TR einen stack, wär sogar die Tabelle gänzlich überflüssig und alles wäre noch viel schöner. Und ja, mein TR hat auch 'Klammern' um die Tabelle zu umgehen, aber damit fängt für mich ja das Elend an! (wäre es anders, wäre ich LISP-Programmierer geworden *g*).

Um z.B. die SA von auch nur 20 Werten in einem Rutsch zu berechnen, ist weder das Anzeigefeld eines modernen TR lang genug, noch mein Gedächnis beim Eintippen...

Nochmal gefragt: Wie bedienst du deinen TR bei 'stino' Rechnungen?

Reply to
Ruediger Klenner

Guten Morgen,

Forth scheint eine immer gr=F6=DFere Interessengemeinschaft zu bekommen, leider kriege ich vom meinem Chef f=FCr dieses Projekt nicht die Zeit mir eine neue Programmierschprache anzueigen, noch nicht einmal die Zeit mir die verschieden Compiler mal anzusehen :-((, aber das hohle ich nach. So wie ich es bisher absch=E4tzen kann, ist der avr-gcc ausreichend f=FCr kleine und mittere Aufgaben. Das Projekt mit dem ich beim AVR Starte ist leider ein (f=FCr mich) sehr gro=DFes, welches komplexe Men=FCs, verschiedene Ger=E4te, diverse serielle Protokolle und verschiedene analoge Messwerte (langzeit und kurzzeit) auswerten und bewerten soll (Soll sogar von extern parametrierbar sein). Damit ist die intiuitive und einfache Bedienung, sowie die Fehlererkennung wichtig. Wenn Funktionen, wie z.B. Debug Funktionen, die ich suche, erst nach einigen Stunden Internetrecherche genutzt werden k=F6nnen bringt mich das Programm nicht weiter. Mir w=E4re ein einfacher Einstieg wichtig, da ich direkt in die Vollen muss Daher weis ich nicht ob, wie Frank-Christian und Michael schrieben, ein komerzieller nicht meinen Anforderungen eher Gerecht wird, und wenn ja welcher und warum....

Gru=DF Mark

Reply to
Mark Kreso

Ich fand den Einstieg in WINAVR ziemlich problemlos. Man muss manches einfach ausprobieren, aber man findet eigentlich alle nötigen Infos recht schnell im WWW.

Debuggen kann man mit dem AVR-Studio. Einfach das entsprechende GCC Projekt in AVR Studio öffnen. Man kann dann entweder durch den C Quelltext durchsteppen oder auf Assembler-Ansicht wechseln. Wobei: Ich sehe so einen Debugger eher als Lernhilfe.

Ich habe bei mir in den bei Winavr beiliegenden "Prgrammers Notepad" als Tools den Compiler und Ponyprog eingebaut und kann dann mit wenigen Tastendrücken mein Programm compilieren und anschließend direkt auf das Zielsystem schreiben.

Beschränkungen bezüglich der Projektgröße sehe ich auch keine. Was mit irgendeinem kommerziellen Produkt geht, sollte auch mit WINAVR gehen.

Du benötigst: AVE-Studio, von der Atmel Website WINAVR und ein Programmiertool, z.B. Ponyprog Dazu dann noch einen Programmieradapter. Entweder selber löten (1x

74HC244) oder kaufen (bei Ebay ca. 10,- ?)

Das sollte nach der Installation dann alles direkt funktionieren. Anpassen musst du dann nur noch das Makefile.

Gruß

Stefan DF9BI

Reply to
Stefan Brröring

Zum Debuggen brauchst Du immer das AVR Studio. Entwickle Deinen Code auf einem Controller, der JTAG hat, und kauf Dir gleich den JTAG-ICE mk2 dazu. Über die ISP-Schnittstelle kannst Du nur Programmieren, schauen ob geht, neu compilieren, programmieren, wieder schauen,... Singlestep etc geht nur über JTAG oder Debugwire (für die kleinen Controller mit wenig Pins, kann der JTAG-ICE auch). Für den eigentlichen Zielprozessor kaufst Du den AVR-ISP mk2.

Nicht daß Ponyprog oder avrdude nicht auch funktionieren würden. Aber über USB (und zwar natives USB ohne serielle Schnittstelle dazwischen) läuft das bei den heutigen Rechnern besser und ist schneller.

Denk einfach dran: Du bist kein Hobbyist, jede Deiner Stunden kostet die Firma richtig Asche, und für die Zeit=Geld, wo Du Dir so einen Parallelport-Adapter zusammenlötest, kann die Firma 3 oder 4 fertige kaufen.

Zur IDE: Die vom Imagecraft ist ... wie sagt man anderswo so schön ... ein "no-brainer". Keine Makefiles schreiben, keine Linkerscripts, nur halt Deinen Code. Rest macht die IDE. Du kannst wenn Du willst auch das AVR-Studio als IDE verwenden - es gibt ein Plugin, das den icc ins AVR-Studio einbindet, so daß Du nicht immer hin und herwechseln mußt. Ist Geschmackssache, was man verwendet.

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.