AVR programmieren in c++ Einstieg?

Ich hab mich vor einigen Monaten auch  mal ein bisschen damit 
beschäftigt und fand diese Sites recht interessant, hilfreich:

http://avr-cpp.de/doku.php
http://avr-cpp-lib.sourceforge.net/

Oliver schrieb:
> C++ ist auf dem AVR mit avr-gcc nur eingeschränkt möglich.

In gewissem Maße, OK.  Insbesondere sollte man auf Exceptions
verzichten, und sich genau überlegen, ob man "late binding"
tatsächlich benötigt.

> Als Alternative schau dir Arduino an.

Was sollte daran anders/besser sein als einfach so C++ mit einem
GCC zu compilieren?

hey maaan schrieb:
> ich persönlich halte nichts davon!

Das sei Dir gegönnt.

> ich programmiere µCs in C .. objektorientiert ist meiner meinung für pc
> software da

C++ heißt weder automatisch objektorientiert, noch erschöpfen sich die 
Möglichkeiten darin. Templates z. B. können ohne jeden Overhead zu ganz 
anders strukturiertem Code führen, als das mit C in der Form drin ist. 
Die Betonung liegt auf können, anders und in der Form. Am Ende ist es 
Geschmackssache.

hey maaan schrieb:
> ich programmiere µCs in C .. objektorientiert ist meiner meinung für pc
> software da

So habe ich bis vor einer Weile auch gedacht - so lange ich mich mit 
Tiny und Mega beschäftigt habe. Das hat sich geändert seitdem ich auf 
XMega umgestiegen bin. Da gibt es diverse Hardware mehrfach (z.B. bis zu 
8 USARTs), die es nahelegen, mehrere Instanzen einer einzigen 
USART-Klasse zu erzeugen. Bislang helfe ich mir damit, alle Daten in 
einem struct zu sammeln und den entsprechenden Routinen zu übergeben. 
Das ist schon ein Stück des Weges in Richtung von Objekten.

Auch werden meine Projekte immer größer und komplexer. Deswegen bin ich 
zur Zeit dabei, C++ auf dem AVR auszuprobieren. Ein Grund ist dabei 
sicher auch, ein Multitasking-OS zu vermeiden und stattdessen lieber 
voneinander getrennte Objekte zu haben.

Sicher kann man den Programmierstil vom PC nicht einfach auf den µC 
übertragen. RAM ist immer noch sehr knapp und um dessen Fragmentierung 
zu vermeiden, muss man viel "statischer" programmieren.

Mal sehen, in ein paar Wochen bin ich da wohl schlauer...

Marwin schrieb:
> Ich habe meine Quellen nicht hier und wahrscheinlich habe ich da
> Neuigkeiten verpasst, aber bisher musste man da immer ein wenig fummeln.
> Zum Beispiel virtuelle Methoden funktionierten nicht einfach so.

Das würde mich interessieren, da ich damit noch nie Probleme hatte.

Zeige mal bitte die Quellen für Deine Aussage.

Malte S. schrieb:
> C++ heißt weder automatisch objektorientiert, noch erschöpfen sich die
> Möglichkeiten darin. Templates z. B. können ohne jeden Overhead zu ganz
> anders strukturiertem Code führen, als das mit C in der Form drin ist.

Genau. OOP ist nur ein Aspekt.
Alleine die Möglichkeit, mit templates von dem Präprozessor ein Stück 
loszukommen, lohnt sich. Oder typsichere enums, Parameter mit 
Default-Werten, static_cast et. al., initializer lists, operator 
overloading, zusätzliche Warnings - setze ich alles auf µC ein.

Detlev T. schrieb:
> Da gibt es diverse Hardware mehrfach (z.B. bis zu
> 8 USARTs), die es nahelegen, mehrere Instanzen einer einzigen
> USART-Klasse zu erzeugen. Bislang helfe ich mir damit, alle Daten in
> einem struct zu sammeln und den entsprechenden Routinen zu übergeben.
> Das ist schon ein Stück des Weges in Richtung von Objekten.

Was hält Dich davon ab, es sofort in C++ zu implementieren? Der GCC wird 
in diesem Fall exakt den gleichen Code erzeugen (Funktion + struct vs. 
Klasse + this). Jeder Tag später vergrößert Deine Code-Basis, welche Du 
später evtl. dann migrieren möchtest.

Roland H. schrieb:
> Was hält Dich davon ab, es sofort in C++ zu implementieren?

Das ganze ist - wie gesagt - ein allmählicher Prozess an dessen Ende 
sich jetzt herausgestellt hat, dass C++ vielleicht besser wäre.

Ich bin jetzt erst einmal dabei, mir eine Library zu schreiben um die 
Hardware in Objekte zu kapseln. (Oder kennt jemand so etwas in fertig?). 
So muss ja zum Beispiel ein Hardware-Interrupt erst einmal das 
zuständige Objekt dafür finden. Und soll die ISR dann die Daten des 
Objektes direkt manipulieren (unter Bruch der Kapselung) oder Methoden 
des Objektes aufrufen - vielleicht sogar noch virtuelle -, die die Dauer 
der ISR verlängern? Da gibt es noch so einiges auszuprobieren.

Pete schrieb:
> man kann auch in C objektorientiert programmieren.

Vom Regen unter Umgehung der Traufe direkt in die Scheiße, pflegte
ein früherer Kollege zu sowas zu sagen. :-)

Das kann man natürlich, aber es bringt keinen einzigen Vorteil,
außer Purismus natürlich.

Jörg Wunsch schrieb:
> Pete schrieb:
>> man kann auch in C objektorientiert programmieren.
>
> Vom Regen unter Umgehung der Traufe direkt in die Scheiße, pflegte
> ein früherer Kollege zu sowas zu sagen. :-)

YMMD
Merken muss, danke :-)

Man kann vieles in C machen. Auch Kunstwerke à la http://www.ioccc.org/ 
Aber das geht wahrscheinlich in allen Sprachen außer Pascal (das hat zu 
viele Airbags eingebaut, um sich selbst gegen die Wand zu fahren oder 
auch nur so zu tun).
Es ist sicher auch spannend und v.a. lehrreich, ohne vorhandenes 
Framework mit z.B. OOP in C auszuloten, was diese Sprache alles wie 
kann. Ob das abgesehen von Selbstbildung auch sinnvoll ist, sei 
dahingestellt.
Es ist ja relativ verbreitet, aus obskuren Gründen C++ so stark 
abzulehnen, dass man sich dann antut, quasi C with Classes ohne 
Zuhilfenahme von cfront mit dem Präprozessor nachzubauen. Oder Vorstufen 
davon. Dabei lässt sich C-Code im Allgemeinen mit nur kleinen Änderungen 
auch mit einem C++-Compiler übersetzen und dann ganz gezielt um Nutzung 
nur der Features der Sprache erweitern, die man vielleicht nicht 
ablehnt.
Wobei viel dieser Ablehnung m.E. auf Unkenntnis oder Unsicherheit beruht 
und v.a. auf Basis alter Entwicklungsstände von C++, Horrorstories über 
Compilerbugs aus dem letzten Jahrzehnt und allgemein der Annahme, dass 
es irgendwie doch nur eine kuriose Erweiterung von C ist und als solche 
nicht perfekt.
Seit Festfahren der entsprechenden Horizonte hat sich aber bei beiden 
Sprachen so einiges getan (C11/C++11), wobei sich am Ende zwei Dinge 
zeigen: erstens, was viele schon immer übersehen haben und dann von 
"C/C++" reden, ja es sind zwei durchaus verschiedene Sprachen bzw. im 
Sprachgebrauch äußerst unterschiedliche Abkömmlinge eines gemeinsamen 
Ursprungs. Zweitens: Trotzdem wird einem Auseinanderdriften der Sprachen 
da, wo es Sinn ergibt, durchaus entgegengewirkt, so dass die gemeinsame 
Untermenge möglichst groß bleibt und am Ende hoffentlich wirklich jeder 
die Freiheit hat, sich trotz erwähnter großer Unterschiede gewissermaßen 
fließend zwischen den Sprachen zu bewegen.

Oliver schrieb:
> Virtuelle Funktionen funktionieren schon, verbrauchen aber kostbares
> SRam.

Ich bezog mich auf "virtuelle Methoden funktionierten nicht einfach so".

Es war mir bewusst, dass das auf AVR RAM kostet. Und? Es gab kürzlich 
einen Thread, in welchem diskutiert wurde, was zuerst auf AVR zur Neige 
geht. Das ist bei nicht ekzessivem Einsatz von "virtual functions" bzw. 
im Allgemeinen eher der Flash: 
Beitrag "Re: Atmel AVRs: SRAM so unwichtig?" und 
Beitrag "Re: Atmel AVRs: SRAM so unwichtig?"

Falls dennoch der RAM knapp wird, dann nimmt man einfach einen größeren 
AVR. Wenn das wg. Stückzahlen nicht geht, dann nimmt man einfach einen 
ARM/MSP430/Renesas RX/PIC32. Alle anderen haben dieses Problem - zu dem 
auch die PROGMEM-Problematik gehört - nicht. Oder man nimmt einen 
anderen Compiler.

Aus Gründen des "kostbaren RAMs" auf gutes SW-Design zu verzichten ist 
teurer.

Marwin schrieb:
> Was wofuer gebraucht wird, steht in meinen Quellen leider nicht, da habe
> ich offensichtlich geschlampt :-(

Für den "new" und den "delete" operator, außerdem für "pure virtual 
functions".

Die ersten beiden benötigt man genauso oft (oder selten) wie malloc() 
und free() in C. Momentan verwende ich weder malloc/free noch 
new/delete, Instanzen lege ich statisch an. Die beiden ersten benötigt 
man m. W. nach nicht, wenn new/delete nicht verwendet wird (GCC 4.5 / 
GCC 4.6).

"__cxa_pure_virtual" benötige ich, da ich vom Design her entweder 
"abstract" oder "final member functions" verwende.

Marwin schrieb:
> Was ich am Makefile schrauben musste, weiss ich nicht mehr.

Vermutlich werden die Exceptions und RTTI abgeschaltet.

Alles in allem vielleicht 15 Zeilen. Bitte mal ins Verhältnis zum 
restlichen Source-Code bzw. Makefile setzen. Kein Vergleich zum Gewinn 
durch bessere Möglichkeiten, das SW-Design anders gestalten zu können.

Detlev T. schrieb:
> So muss ja zum Beispiel ein Hardware-Interrupt erst einmal das
> zuständige Objekt dafür finden.

Das ist in C nicht anders. Auch dort muss in der ISR der Puffer gefunden 
werden.

> Und soll die ISR dann die Daten des
> Objektes direkt manipulieren (unter Bruch der Kapselung) oder Methoden
> des Objektes aufrufen - vielleicht sogar noch virtuelle -, die die Dauer
> der ISR verlängern?

Direkt ist nicht Sinn der Sache, dafür gibt es "inline member functions" 
unter Beibehaltung der Kapselung und Performance. Ich hab's gemessen, es 
entsteht exakt der gleiche Code wie bei einer direkten Zuweisung in C. 
Der Vorteil ist, dass der Compiler prüft, ob erlaubt oder unerlaubt 
manipuliert wird.

Zum zweiten Punkt "virtual functions": Das ist in C genauso schnell oder 
langsam. Ein "function pointer" in C oder "virtual function" in C++ - da 
ist kein Unterschied. Kurios dürfte es auf AVR sein: Durch das etwas 
unfreiwillige Ablegen der vtable im RAM könnte es sogar schneller sein 
:-)

Ein paar Anregungen zu UART und templates finden sich hier: 
Beitrag "Re: C++ für Embedded: ab welchen Prozessormerkmalen?"

Detlev T. schrieb:
> dass C++ vielleicht besser wäre.

Was ist denn wirklich schlechter? :-)

Marwin schrieb:
> Bitte mal
> vor dem Posten die eigene Profilneurose runterschalten, das Thema und
> den Kontext beachten.

Die Messlatte mit dem Thema/Kontext könntest Du zunächst bei Dir selbst 
anlegen, nämlich an Dein erstes Posting. Hat dieses Posting dem TO bei 
seiner Frage geholfen, einen Weg zu C++ auf AVR zu finden?

Zurück zum Thema: Zu den technischen Hintergründen findet sich hier 
einiges: 
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59453&postdays=0&postorder=asc

Pete schrieb:
> Hallo zusammen,
>
> man kann auch in C objektorientiert programmieren.

Man kann auch in Assembler objektorientiert programmieren.

;-)