Ich habe bis jetzt immer in Assembler programmiert mit dem AVR Studio, nun würde ich gerne wissen wie dies in C++ möglich ist, habe mir zwar schon einiges ergooglet kann dies aber nicht genau einordnen da es zu viele unterschiedliche Quellen gibt. Ich wäre sehr dankbar für die Vermeidung von vielen Fachbegriffen, und einfaches erklären ich bin kein Studierter:)
Alles zu C auf dem AVR steht hier: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial C++ ist auf dem AVR mit avr-gcc nur eingeschränkt möglich. Als Alternative schau dir Arduino an. Oliver
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?
Jörg Wunsch schrieb: > Was sollte daran anders/besser sein als einfach so C++ mit einem > GCC zu compilieren? 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. Allerdings sitze ich auch auf einem aelteren gcc...
wenn du wirklich avr in c++ programmieren willst würde ich dir arduino ans herz legen! das ist billig und es gibt haufenweise material tutorials displays sensoren entwicklungsumgebungen .. alles eben ... ich persönlich halte nichts davon! ich programmiere µCs in C .. objektorientiert ist meiner meinung für pc software da mfg
Jörg Wunsch schrieb: >> Als Alternative schau dir Arduino an. > > Was sollte daran anders/besser sein als einfach so C++ mit einem > GCC zu compilieren? Ich sach mal so: Die Art der Fragestellung lässt eventuell erahnen, daß der TO gar nicht unbedingt C++ meint, wenn er von C++ schreibt, und daß er vor allem noch kein C, geschweige denn C++ kann. Mit richtigem C++ hat das das Aruduino-Zeugs auch nix zu tun, es gibt jemandem, der kein C++ kann, aber das Gefühl, es zu können. hey maaan schrieb: > ich persönlich halte nichts davon! dito Oliver
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: >> Zum Beispiel virtuelle Methoden funktionierten nicht einfach so. > > Das würde mich interessieren, da ich damit noch nie Probleme hatte. Virtuelle Funktionen funktionieren schon, verbrauchen aber kostbares SRam. "Out of the box" gehen abstrakte Basisklassen nicht, da fehlt dem Linker eine Funktion, die man aber leicht selber implementieren kann ( heisst irgend was mit _pure_virtual..., genau weiß ichs gerade nicht). Oliver
Hallo zusammen, man kann auch in C objektorientiert programmieren. Das sollte wohl eher was für den TO sein. Dann sollten aber auch die Grundlagen in C sitzen.
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.
Detlev T. schrieb: > 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?). Schon alt, und pures C, aber als Ideenspender ganz ok: http://www.procyonengineering.com/embedded/avr/avrlib/ Oliver
Das hier habe ich in meinen Quellen:
---
void* operator new( size_t Size)
{
return( NULL);
}
void operator delete( void* Buffer)
{
}
extern "C" void __cxa_pure_virtual( void)
{
}
---
Was wofuer gebraucht wird, steht in meinen Quellen leider nicht, da habe
ich offensichtlich geschlampt :-(
Was ich am Makefile schrauben musste, weiss ich nicht mehr. Aber auch
das kann ja mittlerweile obsolet sein, meine Basis war ein AVR-Makefile
von 2007.
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? :-)
Roland H. schrieb: > 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. Darum ist es in meinem Kommentar ueberhaupt nicht gegangen. Bitte mal vor dem Posten die eigene Profilneurose runterschalten, das Thema und den Kontext beachten. Das gilt uebrigens auch fuer die Pappnasen, die diesen Thread in die n-te Inkarnation von "Warum C++ auf dem Mikrocontroller" verwandeln wollen. Hier im Thread hat's genau 2 Posts die ueberhaupt auf die Frage des OT eingehen und dank dir ist dieser leider auch keiner davon :-(
Marwin schrieb: > Hier im Thread hat's genau 2 Posts > die ueberhaupt auf die Frage des OT eingehen und dank dir ist dieser > leider auch keiner davon :-( Je nun, da der TO nur einen einzigen, dazu sehr weir interpretierbaren Beitrag geschrieben hat, um danach auf die kommenden Fragen überhaupt nicht mehr zu reagieren, ist das Verhältnis doch schon prima. Wer mehr passende Antworten will, muß sich schon um seine Threads kümmern. Oder er kriegt halt die Gesamtmenge aller denkbaren Antworten... Oliver
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. ;-)
Roland H. schrieb: > Hat dieses Posting dem TO bei > seiner Frage geholfen, einen Weg zu C++ auf AVR zu finden? Zumindest hat es die Behauptung, es ginge "einfach so" relativiert - so dass er einen Ansatz hat, dass es bei Problemen durchaus nicht nur an seinem Code liegen muss. Auf einen Riesenthread zu verlinken und zu behaupten, da stecke die Antwort drin, ist auch nicht sehr sinnvoll!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.