Forum: Compiler & IDEs Kann ich µC con Amtel/AVR in c++ programmieren?


von Lukas S. (lukas74)


Lesenswert?

Bin noch sehr neu in sachen µC, und habe bis jetzt noch nie gelesen dass 
ich sie auch mit c++ programmieren kann, was mir am liebsten wäre:)
Also geht das? Vorallem mit µC con Amtel?

von remmos (Gast)


Lesenswert?

C++ für einen µC ist meiner Meinung nach zu viel des Guten ... 
Objektorientiert programmieren auf einem µC braucht nur ein Haufen 
Prozessor-Zeit und auch Speicher ... Programmier doch einfach in C, 
immerhin baut C++ ja auf C auf ... da hast'e dich gleich eingearbeitet 
...

Gruß

von Roland H. (batchman)


Lesenswert?

remmos schrieb:
> C++ für einen µC ist meiner Meinung nach zu viel des Guten ...
> Objektorientiert programmieren auf einem µC braucht nur ein Haufen
> Prozessor-Zeit und auch Speicher

Meinung oder Wissen/Fakten? Dann zeige uns bitte den C++-Source, welcher 
"einen Haufen Prozessor-Zeit und auch Speicher" benötigt im Vergleich zu 
seinem C-Pendant. Es gibt ein paar C++-Features, welche auch das 
Gegenteil ergeben (typsichere enums als Konstante mit switch/case oder 
operator overloading statt printf).

Ich setze C++ selbst auf den 2k-Winzlingen attiny2313 und msp430g22x1 
ein.

So wie man auf µCs mit C (im erweiterten Sinn) auf stdio und malloc 
verzichtet oder bewusst selektiv einsetzt, so wird man auch mit den 
C++-Features verfahren.

Mir fällt kein Grund ein, C++ nicht einzusetzen.

von Simon K. (simon) Benutzerseite


Lesenswert?

Roland H. schrieb:
> Mir fällt kein Grund ein, C++ nicht einzusetzen.

Da stimme ich zu. Berühmtestes Beispiel für C++ auf AVRs ist das 
Arduino-Framework.

von Rolf M. (rmagnus)


Lesenswert?

Lukas S. schrieb:
> Also geht das? Vorallem mit µC con Amtel?

Das hängt davon ab, was für µCs du meinst. Atmel verkauft einige recht 
verschiedene, z.B. ARM, AVR, AVR32, 8051.

von Peter D. (peda)


Lesenswert?

Der AVR-GCC versteht auch C++. Du kannst also ruhig in C++ 
programmieren.

Ich hab allerdings noch nicht den Punkt gefunden, der an C++ besser sein 
soll.
In C++ Tutorials wird meistens eine Datenbank als Beispiel genommen. Ich 
habe aber auf dem MC keine Datenbank. Daher fehlt mir irgendwie der 
Kick, was mir C++ bringt.
C++ sieht einfach nur unheimlich kryptisch aus (wenn man es nicht 
kennt).

In einem Thread wird von einem C++ Framework gesprochen. Aber das ist im 
Prinzip nichts anderes, wie der Wizzard in anderen Compilern oder die 
Funktionen im Bascom. D.h. man hat vorgefertigte Funktionen und weiß 
nicht, welche Ressourcen sie belegen und wie lange sie brauchen.

Im Arduino hat man z.B. ne Funkion, wo der Pin nach Nummer gesetzt 
werden kann. Ist sehr unpraktisch, da das nicht nur vom Typ, sondern 
auch von der Bauform abhängig ist.
Und es wird eine riesige Funktion aufgerufen, die aus der Nummer den 
wirklichen Portpin ermittelt und setzt.
In C schreibe ich dagegen einfach:
1
  PORT_D0 = 1; // setze Pin 0 von Port D
Und das ist keine Funktion, sondern ein SBI-Befehl und kostet auch nur 2 
CPU-Zyklen.

Wenn Du also in C++ ein Beispiel programmierst, was auch typisch für 
MC-Anwendungen ist, dann poste es ruhig.


Peter

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Peter Dannegger schrieb:

> Ich hab allerdings noch nicht den Punkt gefunden, der an C++ besser sein
> soll.

Viele Dinge sind in C++ einfach strikter geregelt als in C (wo es oft
aus historischen Gründen eher lax gehandhabt wird).  enums wurden
schon genannt, sie bilden in C++ einen eigenen Typ (der dann auch
nicht ohne weiteres mit anderen gemischt werden kann), während sie in
C kaum einen Unterschied zu einem #define CONSTX 42 haben (außer dass
es für sie noch Debug-Informationen gibt).

Polymorphismus kann zuweilen auch recht nett sein, ich kann also eine
Funktion debug_print() bauen, die wahlweise einen Integer, Float oder
String übergeben bekommt und automatisch das Richtige tut.

Sollte man tatsächlich irgendwann in die Verlegenheit kommen, "late
binding" (typabhängige Handlungsentscheidung zur Laufzeit) zu
benötigen, dann wird selbiges in C auch nicht weniger aufwändig als in
C++, dafür aber um so unübersichtlicher (und folglich
fehlerträchtiger).  Solange man late binding nicht benötigt, haben
auch in C++ die Klassen keinerlei Performancenachteil gegenüber
normalen C-Strukturen.

> C++ sieht einfach nur unheimlich kryptisch aus (wenn man es nicht
> kennt).

Wenn man C nicht kennt, sieht es auch recht kryptisch aus. :-)

(Ich kann mich noch an meinen ersten C-Kontakt nach einigen Jahren
Pascal erinnern ... "Was zum Teufel sollen denn all die vielen
Kommentare da?" :-)

> Und es wird eine riesige Funktion aufgerufen, die aus der Nummer den
> wirklichen Portpin ermittelt und setzt.

Das ist nur eine Bequemlichkeitsfrage für den Nutzer.  Wenn du ein
vergleichbar portables Framework aufbauen willst, bei dem der Nutzer
eben einfach nur noch "Pin 42" sagt, und das dann für beliebig
verschiedene Hardwareplattformen passend gebogen wird, ist das auch in
C nicht einfacher.

> In C schreibe ich dagegen einfach:
>
1
>   PORT_D0 = 1; // setze Pin 0 von Port D
2
>

Daran hindert dich in C++ auch niemand.  Allerdings musst du deinen
Quellcode dann eben anpassen, wenn du ihn auf was anderes portieren
willst.  Der Anspruch von Arduino ist offenbar, komplett generisch
arbeiten zu können.  Für die dortige Zielgruppe scheint das erstmal
wesentlicher als die Performanceeinbuße, da geht's um eine möglichst
einfache Anwendbarkeit.

Machen wir uns nichts vor, man kann die Dinger mögen oder nicht, aber
sie haben mit ihrem Konzept Mikrocontroller an eine Zielgruppe
herangeführt, die sonst nie in der Lage gewesen wäre, mit derartiger
Technik zu experimentieren und zu arbeiten.

Wer über diesen Rahmen hinaus gewachsen ist, braucht das Framework
nicht mehr, C hin, C++ her.

von Dosmo (Gast)


Lesenswert?

Ich hab vor einigen Jahren meine AVR-Plattform von C auf C++ umgestellt, 
weil sich in C++ besser kapseln läßt als in C.
Wenn man weiß, was man tut, und z.B. an den richtigen Stelle statische 
Klassen benutzt, entsteht auch kein Nachteil bzgl. Laufzeit und 
Codegröße.
C++ hat den Vorteil, daß es beim Compilieren strenger prüft als C, 
aber (entgegen der häufigen Meinung) keinen zusätzlichen Code erzeugt 
(wenn man es richtig verwendet).

von Lukas S. (lukas74)


Lesenswert?

Was muss ich denn bei avr studio einstellen um in c++ zu programmieren?
der grund dafür wäre das ich nur in c++ programmieren kann:D und für ein 
schulprojekt gern einen µC programmieren würde:)

von Peter II (Gast)


Lesenswert?

Lukas S. schrieb:
> der grund dafür wäre das ich nur in c++ programmieren kann

aber die Frage ist ob dieses C++ überhaupt für den µC geht. std::string 
kannst du schon mal vergessen. Auch für NEW muss du dir selber etwas 
einfallen lassen.

Und wenn du C++ kannst, wirst du doch wohl auch C können.

Wenn du nicht sehr genau weisst was du in C++ machst, kann das sehr 
schnell auf einem µC schief gehen.

von Peter D. (peda)


Lesenswert?

Lukas S. schrieb:
> Was muss ich denn bei avr studio einstellen um in c++ zu programmieren?

Du mußt das Sourcefile *.cpp oder *.C nennen.


Peter

von Lukas S. (lukas74)


Lesenswert?

Dankeschön:)

von AVR C++ fan (Gast)


Lesenswert?

Stimme fast komplett zu, was C++ auf AVR angeht.
Klarer (wegen strengerer Prüfung, Overloading), ohne wirklichen 
Overhead.

Nur kann GCC aktuell mit NamedMemSpaces (hab grad die korrkte 
Bezeichnung nicht) umgehen, d.h. RAM und FLASH sind in der Deklaration 
(und später natürlich im .lss) unterschiedlich, aber nicht in der 
Verwendung.

G++ hat das (Stand 4.7) noch nicht, obwohl es gerade mit C++ perfekt 
harmonieren würde. Man hätte dann z.B.
1
print(const char *); // ich will eine Zeiger auf RAM
und
1
print(const char _flash *); // ich lieber einen auf Flash-Konstanten
und beim Aufruf brauch ich den Unterschied zwischen RAM und FLASH 
(lesend!) nicht mehr beachten
1
const char _flash flash[] = "Hello FLASH";
2
const char ram[] = "Hello RAM";
3
print(flash); // und nicht print_P(flash);
4
print(ram);
Das ist quasi eine zusätzliche "Overloading-Dimension".

Da hier ja auch Jörg Wunsch mitliest, in dessen großer Schuld wir alle 
AVR-GCC Benutzer stehen, dies als kleine Anregung. (Ja Jörg, ich weiß, 
da ist nicht nur das AVR-Backend beteiligt, auch davor kann der G++, 
nach meinem Kenntnisstand, das noch nicht, aber schön wär's halt schon 
;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

AVR C++ fan schrieb im Beitrag #2704734:
> Da hier ja auch Jörg Wunsch mitliest, in dessen großer Schuld wir alle
> AVR-GCC Benutzer stehen, dies als kleine Anregung.

Laut Aussage von Johann gibt's bei C++ keine named memory spaces.
Beschwer' dich also beim C++-Standard-Komittee. ;-)

(Ich selbst habe mit der Entwicklung des GCC nicht viel zu tun.)

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
Noch kein Account? Hier anmelden.