C++ auf AVR wie gehts?

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?

Ja, aber soweit ich weiß gibts keine IDE die das Debuggen von c++ auf 
AVRs unterstützt.

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.

Gibt es Leute die C++ aber kein C sprechen können?

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.

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

>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...

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.

Nein, das waere Bloedsinn.

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

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