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.
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
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 ;-)
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.