Hallo, ich habe mir kürzlich ein myAVR Board zugelegt und möchte nun erste Programme im AVR Studio dafür entwickeln. Da ich mich einigermaßen mit C++ auskenne habe ich geschaut wie ich für die Programme C++ verwenden kann. In einem Beitrag hier im Forum war beschreiben, dass ich das Makefile des Projektes exportieren und es dann etwas modifiziert für als externes Makefile benutzen soll. Soweit so gut nun habe ich aber noch ein paar offene Fragen und ich hoffe jemand aus diesem Forum kann sie mir beantworten. - Nach dem Modifizieren des Makefile bekam ich beim kompilieren eine Warnung, dass das Flag " -std=gnu99 " nicht für den C++ Kompiler geeignet ist. Welche Aufgabe hat dieses Flag und gibt es eine Alternative für den avr-g++ Kompiler? Muss ich beim Einsatz des C++ Kompilers noch andere Flags verwenden oder entfernen? - Wo bekomme gute Information über den Bau von Makefiles (habe momentan noch garkeinen Plan davon) - Kann ich mit der aktuellen Ausgabe des AVR Studios problemlos C++-Code debuggen oder gibt es irgendwelche Einschränkungen? - Wo gibt es gute Handouts rund um die Entwicklung von Software für den ATmega8 Controller Danke schon mal für eure Hilfe und Gruß, Mario
AVRStudio und C++ können nicht miteinander. Der Debugger kennt nur C. gnu99 definiert eine Sprachvariante von C. C++ ist nicht C. Handouts gibt es hier oben links in den Tutorials. Oliver
> Welche Aufgabe hat dieses Flag Es teilt dem Compiler mit, daß als Sprache C99 mit GNU-Erweiterungen angenommen werden soll. > und gibt es eine Alternative für den avr-g++ Kompiler? Ein entsprechendes Beispiel wäre -std=gnu++98 > - Wo bekomme gute Information über den Bau von Makefiles (habe momentan > noch garkeinen Plan davon) Im Manual von make. Generell geht C++ auf dem avr-g++ nur mit einigen Einschränkungen.
Danke erstmal für eure schnellen Antworten. Mich würde mal interessieren welche Programmiersprache ihr nutzt um Programme für den Controller zu schreiben. Ich meine eigentlich lässt alles wohl auch in C realisieren aber wenn man nun mal die Möglichkeit hat dem Komfort von C++ zu nutzen....? Gruß, Mario
Ich verwende durchaus auch C++-Elemente. Mit Templates, Klassen und Operator-Überladung kann man schon ganz nette Sachen machen. Aber es gibt z.B. keine Standardbibliothek, also kein std::string oder die ganzen Containertypen. Die wären auch nicht sonderlich sinnvoll bei so wenig RAM. Exceptions werden nicht unterstützt (das könnte man ändern, aber es hat sich noch keiner gefunden, der das mal einbaut - auch hier wäre allerdings ein erheblicher Ressourcenverbrauch damit verbunden). Polymorphie geht zwar, leidet aber darunter, daß der GCC beim AVR nicht zwischen Flash und RAM unterscheiden kann. Das führt dazu, daß die vtables im RAM gehalten werden. Das kostet dann für jede polymorphe Klasse pro virtueller Memberfunktion Platz für einen Zeiger im RAM. Die Operatoren new und delete gehen nicht, können aber leicht dazu gebracht werden. Auch iostreams (cout) gibt's nicht. Es wäre allerdings schön, sowas zu haben, da das sicherlich deutlich kompakter als printf wäre). Du kannst C++ durchaus nutzen, aber du wirst nicht den Komfort finden, den du vom PC gewöhnt bist.
Wie sieht es eigentlich mit der Performance aus? Ich habe mal versucht mit C eine Pseudo OOP-Umgebung (auf dem PC) nachzubauen (viele void Pointer und function-Pointer). das ging soweit gut, war aber nur mit einem enormen Overhead verbunden. Zwar glaube ich, dass C++ grundsätzlich etwas anders funktioniert als mein Ansatz damals, aber vom Verwaltungsaufwand sollte es auch nicht zu unterschätzen sein. Darüber hinaus ist ja ein echten OO-Design eines, welches konsequent die Kapselung und das Verbergen privater Daten durchführt. Auch dies ist ja mit einem erhöhten Code- und Laufzeitaufwand verbunden, wenn ständig in Setter-und Getter Funktionen gesprungen erden muss. Also ich würde gerne mal C++ auf dem AVR programmieren, bin aber noch nicht so ganz davon überzeugt, dass man mit der gleichen Codegröße und Laufzeit die gleichen Möglichkeiten hat wie mit C. Irre ich mich da?
> Zwar glaube ich, dass C++ grundsätzlich etwas anders funktioniert als > mein Ansatz damals, aber vom Verwaltungsaufwand sollte es auch nicht zu > unterschätzen sein. Ja. Wie du aber schon sagst, wenn du in C was derartiges brauchst, mußt du es nachbilden und hast dann auch nicht weniger Overhead. > Darüber hinaus ist ja ein echten OO-Design eines, welches konsequent > die Kapselung und das Verbergen privater Daten durchführt. Auch dies > ist ja mit einem erhöhten Code- und Laufzeitaufwand verbunden, wenn > ständig in Setter-und Getter Funktionen gesprungen erden muss. Sofern diese nicht inline eingebaut werden können. Mit inlining verschwindet die Funktion dann wieder komplett. > Also ich würde gerne mal C++ auf dem AVR programmieren, bin aber noch > nicht so ganz davon überzeugt, dass man mit der gleichen Codegröße und > Laufzeit die gleichen Möglichkeiten hat wie mit C. Ich hab schon C++-Programme gehabt, die kleiner und schneller waren als ein vergleichbares C-Programm. Man muß halt nur genau wissen, was der Compiler aus dem Code tatsächlich macht. Und nicht alles, was auf den ersten Blick teuer aussieht, ist das auch.
Naja, grundsätzlich denke ich, dass alles was man OO machen kann auch sequenziell geht. Also der Vorteil von C++ ist ja nicht, das man damit etwas machen kann, was man in C nicht programmieren könnte, sondern, dass der Code eher unserem menschlichen Denkmustern entspricht und leichter verständlich ist (operator Überladen etc.). darüber hinaus ist es eben oft leichter etwas in C++ umzusetzen... Aber wenn man sich etwas hinsetzt und einmal um die Ecke denkt bekommt man das dann sicher auch in C ohne den C++ Wasserkopf hin. Aber klar, die Vorteile liegen auf der Hand: Schnellere Entwicklungszeit und bessere Wartbarkeit des Codes. Selbst die 8bit µC werden immer schneller (siehe XMEGA Reihe) und so spielt der geringe Performanceverlust bald nur noch eine untergeordnete Rolle. Wenn es schnell gehen muss, wird halt doch wieder etwas Assembler in die jeweilige Routine gepackt. So gesehen, denke ich, dass C++ auch in diesem Bereich eine große Zukunft vor sich hat. Einen 8051 mit 1.3 MIPS würde ich dennoch nicht in C++ programmieren ;-) Ich werde auf jeden Fall in Zukunft mal C++ auf einem AVR ausprobieren, die Möglichkeiten reizen mich durchaus :)
C++ Programmie sind nicht grundsätzlich langsamer. Das ist ein Trugschluss. Sie sind nur dann langsamer, wenn eben Exceptions und andere Runtime Sachen eingeschaltet werden. Geht aber mangels Kompatibilität für den AVR eh nicht. Eine ganz einfache Klasse braucht ja an sich gar keinen Speicher. Daran angelegte Funktionen sind auch nur als ganz normale Funktionen im Flash abgelegt. Die Variablen dort drin sind ebenfalls ganz normal im RAM enthalten. Wo genau soll denn der C++ Overhead jetzt herkommen?
Simon K. wrote: > C++ Programmie sind nicht grundsätzlich langsamer. Das ist ein > Trugschluss. Sie sind nur dann langsamer, wenn eben Exceptions und > andere Runtime Sachen eingeschaltet werden. Geht aber mangels > Kompatibilität für den AVR eh nicht. Bleibt dann außer Klassen noch was Besonderes an C++ über?! > Wo genau soll denn der C++ Overhead jetzt herkommen? Insbesondere virtuelle Methoden werden gerne mit Zeigertabellen gestrickt, die machen "Overhead".
Sven Pauli wrote: > Simon K. wrote: >> C++ Programmie sind nicht grundsätzlich langsamer. Das ist ein >> Trugschluss. Sie sind nur dann langsamer, wenn eben Exceptions und >> andere Runtime Sachen eingeschaltet werden. Geht aber mangels >> Kompatibilität für den AVR eh nicht. > > Bleibt dann außer Klassen noch was Besonderes an C++ über?! > >> Wo genau soll denn der C++ Overhead jetzt herkommen? > Insbesondere virtuelle Methoden werden gerne mit Zeigertabellen > gestrickt, die machen "Overhead". Ja, siehe oben. Siehe dort auch die zusätzlichen Probleme wegen Harvard Architektur. Ich würde sagen, dass virtuelle Methoden aber schon in die "geschieht während der Laufzeit" Kategorie fallen, aber das habe ich ja auch schon geschrieben.
Sven Pauli wrote:
> Bleibt dann außer Klassen noch was Besonderes an C++ über?!
Beispielsweise Namespaces. Ist aber nicht wirklich wichtig, es sei denn
das Projekt wird gross.
References. Sind übersichtlicher als Pointer.
Templates. Man kann damit beispielsweise Klassen bauen, die Queues
implementieren, ohne den Datentyp des Inhalts vorweg zu definieren. Also
beispielsweise sowas wie die häufig anzutreffenden Queues/Puffer von per
Interrupt bedienten UARTs. Das geht zwar auch in C ohne Templates, ist
dann aber nicht annähernd so elegant und weit weniger(!) effizient.
> Bleibt dann außer Klassen noch was Besonderes an C++ über?! Funktions- und Operatorüberladung, Namespaces, Templates, ... Da kann man schon einiges damit machen. Ich habe schon öfters mal Beispiele erwähnt, wie man das nutzen kann. Da wäre z.B. ein "smartpointer" auf Flash, der automatisch beim Dereferenzieren die pgm_read_*-Funktionen verwendet, oder ein Fixkomma-Klassentemplate, das sich fast wie ein eingebauter Typ verhält, aber eben als Fixkomma-Typ mit wählbarer Anzahl an Vor- und Nachkommastellen, dabei hocheffizient. Oder eine Klasse, die cout aus Standard-C++ nachbildet, aber ohne den Locale-Overhead. Das wäre dann auch noch schneller, kleiner und flexibler als printf, da es nicht sämtliche Konvertierungen in eine große Funktion packen muß, die dann immer komplett gelinkt wird, wenn irgendwo eine einzige der Konvertierungen verwendet wird. > Insbesondere virtuelle Methoden werden gerne mit Zeigertabellen > gestrickt, die machen "Overhead". Man macht Memberfunktionen aber nicht zum Spaß virtuell. Da wo du in C++ virtuelle Memberfunktionen brauchst, bräuchtest du bei einem entsprechenden C-Programm auch irgendwas, das eine ähnliche Funktionalität bietet. Und da hat man den Overhead dann auch.
Die Sachen die Rolf da nennt, sind schon interessant.. Automatischer Pointer, Fixkomma Template und sowas.. Wäre eigentlich schade, wenn da nicht mal in naher Zukunft eine AVRLibC++ herauskommen würde :|
Hallo, ich mache dieses Thread doch noch einmal auf. Weiter oben wurde erwähnt, dass ... "AVRStudio und C++ können nicht miteinander. Der Debugger kennt nur C.". Ich weiß ja nicht, ob sich da inzwischen offiziel irgend etwas getan hat, aber ich habe gerade mal den gcc durch g++ ausgetauscht und eine einfache Testklasse angelegt. Dann im debugger lief alles auf den ersten Blick ohne Probleme. Die Klassenvariable wird als Struktur dargestellt, ich kann in die Memberfunktion hineinsteppen und das Watch-Window kennt sogar den "this"-Pointer. Was soll denn nicht gehen, mal abgesehen von den verschiedenen Bibliotheken? Grüße, Bernd
Hi, das was mich davon abhält c++ zu verwenden ist, dass im Debugger im Falle einer geerbten Basisklasse, die Variablen der Basisklasse nicht dargestellt werden. Grüße, Bernd
Thread mal wieder hervorhol Wenn ich die Fileextension von .c nach .cpp ändern oder eine neue Datei mit der Endung .cpp hinzufügen will bekomme ich immer wieder eine Fehlermeldung beim Umbennenen: --------------------------- Invalid Extension --------------------------- The file must have one of the extensions '.c', '.s'. --------------------------- OK --------------------------- Kann mir bitte jemand sagen, wie ich denn hinbekomme, cpp Dateien ins Projekt mit reinzukriegen? AVR Studio ist V4.13 Edit: Hat sich grade erledigt. Die Umbennenung in cpp ist gar nicht erforderlich.
Der Entwickler schrieb: > Kann mir bitte jemand sagen, wie ich denn hinbekomme, cpp Dateien ins > Projekt mit reinzukriegen? AVR Studio ist V4.13 Nur der Vollständigket halber. Nutze hier AVR-Studio 4.16 Ich kann cpp Files ohne Probleme ins Projekt mit reinnehmen Allerdings kann scheinbar der Makefile Generator nichts damit anfangen. Mit einer Endung .C geht es aber
hallo, also beim myAVR Paket ist die Möglichkeit objektorientiert zu arbeiten recht elegant gelöst. Ich mach inzwischen fast alles mit den Klassenbibliotheken von denen (wobei ich mir die noch um einiges erweitert habe). Hier mal ein Beispiel was so geht: http://www.myavr.info/download/projekte/myfinder/pjb_myFinder-mk3_de.pdf Grüße Jonas
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.