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?
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ß
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.
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.
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.
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
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.
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).
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:)
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.
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(constchar*);// ich will eine Zeiger auf RAM
und
1
print(constchar_flash*);// ich lieber einen auf Flash-Konstanten
und beim Aufruf brauch ich den Unterschied zwischen RAM und FLASH
(lesend!) nicht mehr beachten
1
constchar_flashflash[]="Hello FLASH";
2
constcharram[]="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
;-)
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.)
Eine eigene Frage?
Dieser Thread ist über 14 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
