Hallo ich möchte mir ein C++ Programm für meinen Atmega 16 schreiben und das am besten dann mit hilfe des JTAGICE mk2 debuggen usw. Ich muss im Juli C++ an der Uni ablegen und wollte mir die graue Theorie mit etwas Hardware versüssen. Gibt es da ne möglichkeit? DAnke
Das Programmieren geht zwar einigermaßen, aber dem Debuggen stehe ich skeptisch gegenüber. Du kannst dir einen avr32 zulegen, damit kannst du C++ Programmieren ohne auf den JTAGICE mk2 verzichten zu müssen. Wenn du unbedingt mit sichtbaren Ergebnissen C++ lernen willst, wieso fängst du nicht mit OpenGL oder DirectX auf einem PC an?
C++ auf dem AVR ist unsinnig, dafür sind die AVR viel zu klein. Es geht schon, aber es bringt halt unterm Strich nix.
>C++ auf dem AVR ist unsinnig ... Na, dann hast du wohl noch nicht viel C++ auf einem Atmega AVR gemacht? >... dafür sind die AVR viel zu klein. Wer erwarted, auf einem 8KB AVR mit 1KB SRAM die C++ Standard Biobliotheken & Klassen einsetzten zu können, oder auch nur genauso wie auf einem 2GHz 1GB PC Programmieren zu können, wird natürlich kläglich Schiffbruch erleiden. Wer jedoch die verschieden Grundkonzepte und Sprachkonstrukte von C++ wirklich verstanden hat und sich angeschaut hat was der jeweilige Compiler dafür an ASM Code ausspuckt, der wird auch C++ gewinnbringend auf einem AVR einsetzten können. ASM ist mühsam, C ist und bleibt ein gefrickel und mit C++ kommt wenigstens etwas glanz und Komfort in die Hütte. Allerdings Programmieren lernen auf dem AVR, egal ob mit ASM oder C++, das tuns sich nur die wahren Masochisten an...
Naja, welche Vorteile spielt denn C++ auf dem AVR aus? Templates -> zu dick. Standardbibliothek -> zu dick. Klassen -> vielleicht. Dynamische Speicherverwaltung -> ist schon mit malloc() zu fett. Ich gestehe aber offen ein, dass ich nicht viel mit C++ mache.
@Sven: Neben den ganzen dynamischen Schnick-Schnack der bei C++ besonders gerne benutzt wird (der aber nicht zwangläufig benutzt werden muss) hat C++ gegenüber reinem C einen ganz großen Vorteil: Bessere Lesbarkeit des Codes. Wenn man die C++ Mittel mit Bedacht einsetzt, kann man einen wesentlich schöneren Code mit C++ erzeugen als mit C. Man kann einfach etwas schöner Strukturierenen. Klar, das sind alles keine Argumente weswegen man unbedingt C++ einsetzen muss, aber wer nach 2 Jahren sich den eigenen Code noch einmal ansehen muss der freut sich, wenn statt irgendwelchem kryptischen Code hat man einen Operator geschickt überladen und einen leichter verständlichen Code. Ist eben Geschmacksache... Auf jeden Fall sollte man bei C++ und AVR aufpassen welche Elemente man benutzt und welche nicht. Virtuelle Methoden und dynamische Objekte, sind eben mit Vorsicht zu genießen. Das gilt aber genauso für C und malloc. Wenn es wirklich nur um das Lernen von C++ angeht, würde ich abraten, dies auf einem µC zu machen. Dann lieber am PC C++ lernen, dort hat man andere Randbedingungen und kann die Möglichkeiten von C++ voll ausschöpfen ohne Ständig an Speichergrenzen und so zu denken.
netb wrote: > @Sven: > gegenüber reinem C einen ganz großen Vorteil: Bessere Lesbarkeit des > Codes. Wodurch das denn? Also ich meine, spontan fallen mir da Referenzen und Überladerei ein, wobei man mit beidem auch Schindluder treiben kann -- genauso wie man mit C sauberen Code schreiben kann. Wie auch immer. > [...] Joa, wobei ich überladene Operatoren nicht unbedingt lesbarer halte, das birgt ja auch wieder Risiken in sich. > Wenn es wirklich nur um das Lernen von C++ angeht, würde ich abraten, Das sowieso, gar keine Frage.
>Naja, welche Vorteile spielt denn C++ auf dem AVR aus? Templates -> zu >dick. Standardbibliothek -> zu dick. Klassen -> vielleicht. Dynamische >Speicherverwaltung -> ist schon mit malloc() zu fett. Sag ich ja, vergiss alle Unarten an C++/Objektorientierter Programmierung die du auf dem PC gelernt hast und schau dir jedes Sprachkonstrukt von C++ genau an ob du es auf dem AVR verwenden kannst. Mühsam aber es lohnt sich, denn wenn die Alternative C heisst, gibt es in C++ nichts was das Programmieren zwingend ineffizienter oder mühsamer macht, aber jede Menge Features, die wohl überlegt eingesetzt, einem das Leben leichter machen.
Kupfer Michi wrote: > Mühsam aber es lohnt sich, denn wenn die Alternative C heisst, gibt es > in C++ nichts was das Programmieren zwingend ineffizienter oder mühsamer > macht, aber jede Menge Features, die wohl überlegt eingesetzt, einem das > Leben leichter machen. Welche denn dann?
>> macht, aber jede Menge Features, die wohl überlegt eingesetzt, einem das >> Leben leichter machen. >Welche denn dann? Ja bekommst du denn z.B. mit Sprachkonstrukten wie Klassen und Templates deine Programme nicht aufgeräumter und effizienter hin? Gerade Templates ermöglichen sehr effiziente Variantenprogrammierung, die helfen auch das letzte bisschen an Speicher und Laufzeit Overhead aus deinem Programm herauszukompilieren. Wenn das auf dem AVR nicht wichtig ist, was dann? Mann mag sich ja garnicht anschauen, wie da die C Fraktion versucht, mit #defines und Preprozessor Gewürge, etwas vergleichbares hinzubekommen.
Sven P. wrote: > Naja, welche Vorteile spielt denn C++ auf dem AVR aus? Saubere Modularisierung beispielsweise. Hat eher ästhetische Relevanz, kostet aber wenig. Vereinheitlichung von Sensoren gleicher Klasse aber verschiedener Arbeitsweise lässt sich prima über abgeleitete Klassen einer Basisklasse und virtuelle Funktionen realisieren. So beispielsweise Temperatursensoren, die sicherheitshalber teils digital (DS18x20) teils analog (LM335) realisiert wurden. Nutzen ist gross, zusätzlicher Aufwand gering. Es hängt allerdings von der Architektur ab, wie gut sich typische C++ Sprachkonstrukte umsetzen lassen. Ziemlich wichtig ist dabei die Möglichkeit, relativ zu einem Pointer adressieren zu können. Bei AVR oder MSP430 ist das einfach, ein 8051 hingegen muss jedesmal die Adresse zu Fuss ausrechnen. > Templates -> zu dick. Nein. Beispiele in denen ich C++ Templates verwendet habe: - Generische Klasse für Ringpuffer zwischen Anwendung und Interface, verwendbar für beispielsweise UART (oder CAN, ...). Ist nicht viel erzeugter Code dahinter und der vervielfacht sich auch bei mehreren Interfaces gleichen Typs nicht weil: - Interface-Modul für beispielsweise UART, in dem die Datenpuffer (s.o.) für jeden UART-Kanal statisch gespeichert werden. Ich verwendet bei Controllern nur sehr ungern dynamischen Speicher, weil sich statischer Speicherverbrauch besser kalkulieren lässt. Der Code steckt zu 95% in einer nicht generischen für alle UART-Kanäle verwendbaren Basisklasse, vervielfacht sich bei mehreren Kanälen nicht. Über das Template werden nur Häppchen relevant für Initialisierungsparametrisierung und ggf. Interruptabhängigkeiten vervielfacht.
Dieses ganze Blablabla "C++ auf dem AVR ist besser, weil ..." ist doch Bockmist. Der Grund warum Leute C++ auf dem AVR verwenden wollen ist, weil sie nichts anderes kennen und können. Dazu werden dann stundenlang Ausreden wie "ist besser lesbar" oder "hat ganz tolle Features" an den Haaren hergezogen. Einmal, nur ein einziges Mal möchte ich von den C++-Jammerern hören "ich verwende C++ weil ich es nicht besser kann oder weiß". Das wäre einmal nicht gelogen. Nur die Java-Typen sind noch schlimmer. Wir reden hier von MCUs mit lächerlichen Speichergrößen. Nichts, absolut nichts, was C++ wirklich interessant macht (z.B. STL oder RTTI) lässt sich auf einem AVR sinnvoll in Stellung bringen. Das ist wie der Versuch mit einem Vorschlaghammer zu arbeiten, bei dem man den Stiel nicht verwenden kann. Im besten Fall, beim größten AVR lassen sich vielleicht ein paar tausend Zeilen C in einen AVR quetschen. Wie man bei so ein paar lächerlichen Zeilen Code den Überblick verlieren kann und warum das mit C++ nicht passieren soll verstehe ich nicht. Wer in ein paar tausend Zeilen C keine Ordnung halten kann, der programmiert auch in C++ nur Scheiße. Wem von so ein paar Zeilen C schwindelig wird, der sollte sich vielleicht nach einem anderen Job umsehen.
Um mal Zahlen zu bringen: Quelltext eines Programms inklusive Includes (bei C++ durchaus relevant) = 7800 Zeilen, eher sparsam kommentiert. Nur gehört der verwendete Mega32 nicht wirklich zu den Monstern. Weder will ich jemanden zu C++ überreden, noch halte ich das für es Nonplusultra (mein erster Eindruck, als diese Sprache noch recht frisch war, lässt sich nicht magenfreundlich ausdrücken). Ich verstehe bloss nicht, warum ich angesichts dessen Verfügbarkeit auf die nützlichen Aspekte von C++ verzichten soll. Ich mache das ja nicht beruflich, sonst wäre evtl. relevant, dass viele kommerzielle Compiler nur für C existieren.
Sven P. wrote: > C++ auf dem AVR ist unsinnig, dafür sind die AVR viel zu klein. > Es geht schon, aber es bringt halt unterm Strich nix. ACK. Ausserdem ist C++ nur mit Einschraenkungen verwendbar, es steht also nicht der gesamte Sprachumfang und die library zur Verfuegung. In C++ kann man seine Programme so leicht aufblasen (code bloat) dass sie in keinen AVR mehr passen.
Michael G. wrote: > C++ kann man seine Programme so leicht aufblasen (code bloat) dass sie > in keinen AVR mehr passen. Ack. Wobei ich eine recht gute Vorstellung davon habe, wie gut oder schlecht sich Code umsetzen lässt. Man muss schon mit der Schere im Kopf programmieren, sonst wird das nix. Wobei das in reduziertem Umfang auch für C gilt. Schon mancher wurde vom Codeverbrauch durch Fliesskommarechnung überrascht. Und bei Architekturen, die sich mit Stackframes etwas schwer tun (z.B. 8051 und 8bit PICs einschliesslich älterer PIC18), ist es ebenfalls ziemlich hilfreich, um deren Schwächen sorgsam herumzuprogrammieren. Auch da ist also diese Schere angebracht.
Ich will ja nicht sagen dass es garnicht geht. Aber C++ ohne "new"... naja ;) Wenn danach 70% des Codes doch wieder reines C ist, weil auch fast alle libs fuer den AVR in reinem C geschrieben sind kann man ja gleich bei C bleiben.
Naja, ich sehe schon. Diese Diskussion gleitet mal wieder in religiöses Gehabe ab. Ein Wunder, dass hier noch nicht jemand behauptet hat, dass man mit dem Vi einen, für µCs, besseren Code schreiben kann als mit emacs... Nahezu jedes C Programm kann problemlos mit einem C++ Compiler übersetzt werden. Daher spricht nichts dagegen, sich an geeigneter Stelle bestimmter C++ Sprachkonstrukte zu bedienen, um damit die Lesbarkeit zu erhöhen. Falls jemand der Meinung ist, dass er C Code grundsätzlich schneller und besser (nach 2 Jahren) wieder lesen kann als C++ Code, dann spricht doch nichts dagegen einfach C Code zu schreiben. Falls man dann doch mal einen Operator überladen möchte, dann macht man das einfach... der Rest bleibt halt C. Das kommt eben auf die persönlichen Vorlieben eines jeden Entwicklers an, aber pauschal zu sagen, dass C++ und µC nicht zusammen passt ist schlichtweg dumm.
>Ausserdem ist C++ nur mit Einschraenkungen verwendbar, es steht >also nicht der gesamte Sprachumfang und die library zur Verfuegung Lustige Logik: Nur weil ich nicht ALLES verwenden kann, verzichte ich gleich in Bausch und Bogen auch auf die nützlichen Dinge? - Also ich gehe da pragmatischer vor. >In C++ kann man seine Programme so leicht aufblasen (code bloat) dass sie >in keinen AVR mehr passen. Tja, sollte man beim Programmieren eines AVR nicht generell wissen was man tut? Gilt das selbe Argument nicht auch gegenüber C, wenn ich mir beliebigen Code reinziehe. Ein AVR ist nun mal kein PC. Oder liegt darin vielleicht das grosse Missverständniss? Erwarten die Leute etwa, dass mit C++ auf magische Weise und ohne eigene Anstrengungen und Programmier Know How, der AVR doch so komfortabel wie ein PC wird und geben dann C++ (anstatt sich selber) die Schuld wenns nicht klappt? Wenn ich mir die Beiträge so anschaue, scheint mir das fast so. Ständig wird von Dingen geredet die nur auf dem PC Sinn machen.
>Aber C++ ohne "new"... naja ;)
Genau das meinte ich.
Dynamische Programmierung wie auf dem PC und dann entäuscht sein wenns
nicht geht.
Oder bist du genauso konsequent und schmeisst C auch gleich auf den
Müllhaufen und nimmst ASM, nur weil in der gleichen Situation in C das
malloc genauso wenig funktioniert?
Kupfer Michi wrote: > Wenn ich mir die Beiträge so anschaue, scheint mir das fast so. > Ständig wird von Dingen geredet die nur auf dem PC Sinn machen. Ich habe eher den Eindruck, viel mehr als ein BlinkeLEDs haben hier viele noch nicht gemacht. Im Chat gab's auch schon ein paar Debatten, wo Leute meinten sie haetten gigantische Applikationen geschrieben, weil sie 1000 Zeilen C-Code zusammen hatten. Ich habe hier fuer eine Fernsteuerung auf Atmega2560 Basis 20.000 Zeilen C++-Code und bin weder fertig, noch habe ich den Kontroller voll. Objektorientierte Programmierung hat mit new/delete, Templates und Co. erstmal gar nichts zu tun. Das faengt ganz primitiv damit an, dass man Objekte hat, bei denen Methoden und benoetigte Variablen zusammen liegen. Natuerlich kann man alles auch in Modulen mit Prefixen und weiss der Geier was organisieren, das ist dann auch objektorientiert - aber wieso sollte man, wenn es einen Compiler gibt, der das eleganter macht? Und genau das macht 80% von den Vorteilen aus und bringt die bessere Uebersichtlichkeit.
Luk wrote: > ich möchte mir ein C++ Programm für meinen Atmega 16 schreiben > und das am besten dann mit hilfe des JTAGICE mk2 debuggen usw. > Ich muss im Juli C++ an der Uni ablegen und wollte mir die graue Theorie > mit etwas Hardware versüssen. Gibt es da ne möglichkeit? Mit avr-gcc und avrdude kannst du mit Einschraenkungen in C++ fuer den Atmega entwickeln. Wie andere schon schrieben, wuerde ich auf dynamische Speicherverwaltung und komplexe Konstrukte verzichten. Leider funktionieren zumindest bei meiner avr-gcc-Version die virtuellen Methoden nicht - da musst du dir mit Funktionspointern behelfen. Wenn du C++ erst lernen willst, wuerde ich davon die Finger lassen.
Peter Stegemann wrote: > funktionieren zumindest bei meiner avr-gcc-Version die virtuellen > Methoden nicht - da musst du dir mit Funktionspointern behelfen. Habe damit keine Probleme. Meinst du evtl. pure virtuals? Workaround dafür ist harmlos.
Manche von euch haben den Sinn meiner Frage nicht verstanden? Ich möche C++ nicht auf meinen Microkontroller laufen lassen weil ich es muss sondern weil ich es lernen will natürlich geht das ganze auch mit dem PC aber ich wollte es halt mit einem Mikrokontroller machen zumindest für einige Sachen. Also mit dem AVR Studie geht es nicht das einzige was eventuell geht ist der IAR Combiler. Der kann auf jedenfall ganz offiziell C++. Ich muss in nur noch Knacken. MFG
Wenn du C++ der Sprache wegen lernen willst, dann vergiss AVRs und andere Zwerge. Denn dann solltest du dich unbedingt auch mit der STL beschäftigen, und die ist genau jene Sorte Code, die selbst wenn verfügbar bei Zwergen zu schwer kalkulierbarer Menge Code sorgt. Dem PC ist das herzlich egal, dem Zwerg nicht. Vom Debugging ganz zu schweigen. C++ auf AVRs läuft m.E. andersrum besser. Man kennt die Sprache vom PC und verwendet eine Untermenge auf dem AVR.
Luk wrote:
> Ich muss in nur noch Knacken.
Gehört "IAR knacken" bei deiner Uni auch zum Ausbildungsprogramm?
>Also mit dem AVR Studie geht es nicht das einzige was eventuell >geht ist der IAR Combiler. Der kann auf jedenfall ganz offiziell C++. ??? Lad dir WinAVR herunter und du hast gcc, der kann C++ und kannst weiter mit dem AVRStudio arbeiten. Nicht vergessen: C++ Source Files mit grossem .C enden lassen, dann erkennt der gcc automatisch, dass es sich um einen C++ File handelt. http://www.mikrocontroller.net/articles/WinAVR
@Peter Stegemann, kann dir in deiner generellen Aussage nur zustimmen. (wollte jedoch nicht so deutlich sagen, dass viele kategorische Ablehnungen wohl eher der mangelnden Erfahrung geschuldet sind, das kommt bei den Leuten nicht so gut an ... Zeig mir einen Programmierer der sich nicht für sehr erfahren hält ;-) )
A. K. wrote: > Peter Stegemann wrote: >> funktionieren zumindest bei meiner avr-gcc-Version die virtuellen >> Methoden nicht - da musst du dir mit Funktionspointern behelfen. > Habe damit keine Probleme. Meinst du evtl. pure virtuals? Workaround > dafür ist harmlos. Nein, normale virtuals. Ich wollte fuer meine Screen-Klasse so Sachen wie entrySelected() etc. natuerlich virtuell zum ueberschreiben machen, das fuehrte zu recht obskuren Compilerfehlern - irgendwo habe ich das auch noch von Anderen beschrieben gefunden, also habe ich es anders geloest und mich nicht weiter darum gekuemmert. Gut moeglich, dass es inzwischen geht. Ich nutze noch Version 4.1.2 und wenn es sich nicht wirklich lohnt, werde ich nicht updaten, da die neueren Versionen wohl fetteren Code erzeugen...
Hab nochmal nachgesehen. Das hier hängt bei mir seit Jahren als C-Code mit drin: void __cxa_guard_acquire(void) {} void __cxa_guard_release(void) {} Im Link von Mehmet steht es präziser drin.
Ich hab's dann doch nochmal probiert, ich muss nur einfach new und delete implementieren, im Prinzip, wie Mehmet es beschrieben hat. Allerdings mappe ich die beiden nicht auf malloc, da ich sie ja sowieso nicht brauche.
Hey, das ist ja ein ganz schön lange, abgehoben Diskussion. Könnt Ihr nicht mal zwei kurze Codeteile posten, die die Überlegenheit von C++ auf dem AVR zeigen? Dann kann man sich direkt ein Urteil bilden.
Hi >Hey, das ist ja ein ganz schön lange, abgehoben Diskussion. >Könnt Ihr nicht mal zwei kurze Codeteile posten, die die Überlegenheit >von C++ auf dem AVR zeigen? >Dann kann man sich direkt ein Urteil bilden. Richtig. Und das was der Compiler dann daraus macht würde mich noch mehr interessieren. MfG Spess
Beim oben skizzierte Beispiel mit den Temperatursensoren kann ich das erklären: In jeder struct sitzt ein Pointer auf eine Funktionstabelle. Statt also die Funktion direkt aufzurufen erzeugt der Compiler einen zweifach indirekten Funktionsaufruf. Also:
1 | fuction_pointer_t vtbl1[]; |
2 | struct Sensor { |
3 | function_pointer_t *vtbl_ptr; |
4 | ... Daten ...; |
5 | }
|
und aus einem Funktionsufruf object->function(parameters) wird (object_ptr->vtbl_ptr[2])(object_ptr, parameters); Das war's auch schon.
Hmm. editieren geht grad nicht, also müssen die Schönheitsfehler halt drin bleiben.
So Problem gelöst ich mache es nun mit der 30 Tage Version des IAR Combiler sollte jemand ne besser Idee haben dann bitte schreiben
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.