Hallo zusammen, ich beschäftige mich seit einiger Zeit mit C++ Programierung am PC, habe nun auch Interesse an der Programmierung von Mikrocontrollern bekommen. Ich möchte vorerst mit einem Controller alles machen können was im AVR Assembler Tutorial auch gemacht wird, also Taster, LEDs, Displays usw. usf. Später will ich auch Motoren damit ansteuern können, ist ja mit Controllern alles kein Problem. Allerdings möchte ich bei C++ bleiben, auch wenn das bedeutet, dass es komplizierter wird einen Controller zu programmieren (weil die Architektur komplizierter ist?). Welchen Controller + IDE + Compiler könnt ihr mir empfehlen? Der Controller sollte Steckbretttauglich sein. Es wäre auch noch gut so etwas wie C++ Lessons dafür zu haben mit Beispielen, gibts ja bei zB PIC nur halt in C.
:
Gesperrt durch Moderator
Sven schrieb: > Allerdings > möchte ich bei C++ bleiben, auch wenn das bedeutet, dass es > komplizierter wird einen Controller zu programmieren (weil die > Architektur komplizierter ist?). nein, du kannst auch einfach einen AVR in C++ Programmieren.
C++ hat aber nur einen begrenzten Funktionsumfang auf dem avr (und das ist auch gut so)
Keinen. Programmiere µCs in C und fertig. Es gibt eine Minderheitengruppe von C++-Programmierern, die unbedingt auf C++ besteht - meist weil sie C nicht können oder die Möglichkeiten von C++ auf Mikrocontrollern überschätzen. (Die werden gleich hier aufschlagen und einen Riesenwind machen). Bei diesen C++-Programmierern auf µCs stellt sich schnell raus, dass sie keine der wirklich wichtigen Features von C++ im Vergleich zu C nutzen. Es wird typischerweise in C++ programmiert als ob es C ist. Genutzt werden C++-Features die man bestenfalls als Syntaktischen-Zucker bezeichnen kann. Ganz nett, aber in keinster Weise missionsentscheidend. (Das wirst du an den unwichtigen Codeausschnitten sehen, mit denen die C++-Fraktion ihre Überlegenheit demonstrieren möchte. Trivialer Scheiß).
:
Bearbeitet durch User
Sven schrieb: > Welchen Controller + IDE + Compiler könnt ihr mir empfehlen? Der > Controller sollte Steckbretttauglich sein. Es wäre auch noch gut so > etwas wie C++ Lessons dafür zu haben mit Beispielen, gibts ja bei zB PIC > nur halt in C. Für PIC32 unterstützt Microchip auch C++. Und die PIC32MX1xx/2xx gibts auch im SDIP28. fchk
Hannes Jaeger schrieb: > Bei diesen C++-Programmierern auf µCs stellt sich schnell raus, dass sie > keine der wirklich wichtigen Features von C++ im Vergleich zu C nutzen. Defaultparameter und überladenen Funktion finde ich ganz praktisch. Warum sollte man darauf verzichten wenn es keine Nachteile hat? Auch die Möglichkeit etwas per Referenz zu übergeben ist oft lesbarer als per Zeiger zu arbeiten. Ja es ist am ende nur "Syntaktischen-Zucker" aber sehr angenehm.
Hannes Jaeger schrieb: > Keinen. Programmiere µCs in C und fertig. > > Es gibt eine Minderheitengruppe von C++-Programmierern, die unbedingt > auf C++ besteht - meist weil sie C nicht können oder die Möglichkeiten > von C++ auf Mikrocontrollern überschätzen. (Die werden gleich hier > aufschlagen und einen Riesenwind machen). Und dann gibt es da noch eine (Minderheiten-?) Gruppe, die unbedingt auf C besteht. Grundsätzlich gilt: Für jeden Zweck das richtige Messer! C++ bietet sehr wohl Features, die C nicht hat. Wenn Du die nutzt, nimm C++, wenn nicht, nimm C. Übrigens bin ich davon überzeugt, dass mehr Programmierer für C sind, weil sie C++ nicht beherrschen als umgekehrt, denn wer C++ beherrscht sollte trivialerweise auch C beherrschen, schließlich ist C eine Untermenge von C++. :-)
:
Bearbeitet durch User
Hannes Jaeger schrieb: > Es wird typischerweise in C++ programmiert als ob es C ist. Genutzt > werden C++-Features die man bestenfalls als Syntaktischen-Zucker > bezeichnen kann. Tjs, was der Bauer nicht kennt, ... :-((( A. H. schrieb: > mehr Programmiere für C sind, > weil sie C++ nicht beherrschen So sieht es leider aus und es gibt viele unnötige Fehler in Programmen und schreckliche Designs. @Sven C++ beinhaltet viele unterschiedliche Features, welche möchtest du davon überhaupt nutzen?
Hannes Jaeger schrieb: > Bei diesen C++-Programmierern auf µCs stellt sich schnell raus, dass sie > keine der wirklich wichtigen Features von C++ im Vergleich zu C nutzen. > Es wird typischerweise in C++ programmiert als ob es C ist. Genutzt > werden C++-Features die man bestenfalls als Syntaktischen-Zucker > bezeichnen kann. Ganz nett, aber in keinster Weise missionsentscheidend. Nun mußt du nur noch erklären, welchen Vorteil es hat, wenn man sich dazu zwingt, auf diesen syntaktischen Zucker zu verzichten.
Hannes Jaeger schrieb: > (Die werden gleich hier > aufschlagen und einen Riesenwind machen). Anwesend! Riesen Wirbel: Nimm einen Arduino!
Danke für die bisherigen Beiträge. Bei C++ will ich eigentlich nur bleiben, weil ich gerade dabei bin C++ zu lernen, ich schätze mich als minimal fortgeschrittenen Anfänger ein. Ich nutze das Buch "Einführung in die Programierung mit C++ - Bjarne Stroustrup". Stroustrup schreibt, dass das lernen von C als erste Sprache zu einem schlechten Programmierstil führt, keine Ahnung was er im Detail damit meint, aber er wird es wissen müssen. Er zeigt in einem sepparaten Kapitel die Features auf die in C im Gegensatz zu C++ fehlen und wie man diese (so denke ich) kompensiert, also statt zB Klassen und Memberfunktionen soll man "struct" und globale Funktionen nutzen. Ups jetzt ist mein Kommentar doch etwas länger geworden.
Ich denke C++ wurde aus 2 Gründen erfunden: 1. damals eine Modeerscheinung 2. um größere Projekte in den Griff zu bekommen. Und ja, ich stimme dem zu! Der Wechsel von der funktionalen Sichtweise auf die OOP ist nicht leicht. Man muss sich erst das falsch gelernte wieder aus dem Schädel kloppen. Gelingt das nicht, pervertiert das OOP Vorhaben.
Hallo Sven, ich würde als Compiler den GCC nehmen. Der läuft auf jedem Betriebssystem und unterstützt die neusten C++ Standards. Bei einem Controller würde ich mich an einem ARM orientieren, da es dort von fast allen Herstellern startup code für den GCC gibt (CMSIS). Lesbare Dokumentation für den Microcontroller ist auch ein Kriterium, nach dem man zum Einstieg den Controller auswählen kann und das Vorhandensein von Eval Boards. Vielleicht ein STM32 auf keinen Fall ein XMC. Ich bin ja ein Fan von make/gcc plus Editor. Von daher keine IDE-Empfehlung von mir ;-) mfg Torsten
Hallo Torsten, ich habe mir den STM32 Artikel angesehen, das sieht sehr interessant aus, sagt mir sehr zu. Ich werde mich da gründlich einlesen müssen, ist ein großer Artikel mit Unterartikeln. Hallo Frank, danke auch für deinen Hinweis mit den PIC32. Ich werde mir jetzt mal in Ruhe beide Typen ansehen müssen und dann eine Entscheidung treffen. Und an alle Anderen auch vielen Dank für die vielen Infos.
Was mich noch auf die schnelle interessieren würde bevor ich anfange mich tief einzulesen, was ist denn der Hauptunterschied zwischen den STM32 und PIC32? Leistungstechnisch scheinen sie ähnlich, beide können mit C++ programmiert werden, Starterkits sind ähnlich (Touch, TFT, USB ...)
Sven schrieb: > Stroustrup schreibt, dass das lernen von C als erste Sprache zu einem > schlechten Programmierstil führt, keine Ahnung was er im Detail damit > meint, aber er wird es wissen müssen. Ich finde seine Meinung zwar etwas extrem, kann ihm aber in Teilen zustimmen. Als Beispiel seien mal Operationen mit Strings genannt. In C hat man dort toll strcpy, strcat, sprintf und Konsorten welche sicherlich für einen Großteil von Buffer Overflows und Sicherheitslücken in C Programmen zuständig sind. In C++ nimmt man einfach std::string (ja ist für µC vielleicht nicht unbedingt zu empfehlen) und damit kann man eigentlich keinen Buffer Overflow erzeugen. Eingefleischte C Programmierer werden aber kaum von sowas wie std::string zu überzeugen sein weil strcat hat man ja schon immer benutzt. Genauso Speicher reservieren. Wozu braucht man dieses neumodische std::vector wenn man malloc hat? Mir persönlich gefällt C++ sehr aber ich muss auch nicht jedes Feature auf einem µC nutzen. Außerdem halte ich es für sinnvoll ein Grundverständnis von C zu haben, um zu wissen wie die Klassen intern arbeiten oder wie man selbst sowas implementiert.
Sven schrieb: > Stroustrup schreibt, dass das lernen von C als erste Sprache zu einem > schlechten Programmierstil führt, keine Ahnung was er im Detail damit > meint, aber er wird es wissen müssen. Er dürfte damit wohl meinen, dass der Mensch ein Gewohnheitstier ist und dazu neigt, bekannten Wege zu gehen, selbst wenn es inzwischen bessere Alternativen gibt. Mein erstes Pascal-Programm sah auch aus wie Basic ohne Zeilennummern. :-) Neue Konzepte zu verstehen kostet eben seine Zeit und meistens auch Mühe, die der Mensch gerne vermeidet, wenn er kann. Man braucht nicht unbedingt Klassen und Templates, um Probleme zu lösen und die Vorteile zeigen sich oft erst auf lange Sicht, manchmal gar nicht. Also ist es bequem, sie zu vermeiden und das ist wohl das, was er als schlechten Stil beschreibt. Es gibt allerdings auch das umgekehrte Phänomen: Leute, denen als erstes das Programmieren mit Klassen beigebracht wurde neigen nicht selten dazu, alles mit Klassen zu lösen, selbst da, wo es gar keinen Sinn macht. Das Lernen von C++ ist also noch längst keine Garantie für guten Stil! („There never has been nor ever will be a programming language were it is at least a bit difficult to write bad code!“)
Sven schrieb: > Was mich noch auf die schnelle interessieren würde bevor ich anfange > mich tief einzulesen, was ist denn der Hauptunterschied zwischen den > STM32 und PIC32? Leistungstechnisch scheinen sie ähnlich, beide können > mit C++ programmiert werden, Starterkits sind ähnlich (Touch, TFT, USB > ...) Man korrigiere mich, wenn ich flashc liege, aber ich glaube, der GCC unterstützt den PIC32 nicht (ich habe zumindest auf die Schnelle nix in der Dokumentation https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/ gefunden).
klausr schrieb: > PIC32 ist MIPS M4K Trotz des Wikipedia Artikels bin ich nicht schlauer geworden. Was bedeutet das für mich in der Praxis?
Habe es einigermaßen verstanden, DMIPS = MIPS, DMIPS hat die Bezeichnung aufgrund eines bestimmten Benchmarkverfahrens. Bleibt nur die Frage was schneller ist und ob das überhaupt eine Rolle spielt.
Nein, MIPS ist hier eine Prozessorarchitektur, es geht nicht um Performancevergleiche. https://de.wikipedia.org/wiki/MIPS-Architektur
A. H. schrieb: > Neue Konzepte zu verstehen kostet eben seine > Zeit und meistens auch Mühe Ob ein grösseres Maß an Zeit und Mühe eine Aussage darüber erlaubt, wie gut ein Konzept überhaupt ist? Ulrich F. schrieb: > Der Wechsel von der funktionalen Sichtweise auf die OOP ist nicht > leicht. Muß das denn überhaupt sinnvoll sein? > Man muss sich erst das falsch gelernte wieder aus dem Schädel kloppen. Wenn es so gut da drin sitzt, so intuitiv zu erfassen, daß man es sich regelrecht aus dem Schädel kloppen muß, wie kann es dann so schrecklich falsch sein?
Bei dem Titel war es ja nur eine Frage der Zeit bis dieser Spinner wieder mal auftaucht...
Moby AVR schrieb im Beitrag #4172946: > Muß das denn überhaupt sinnvoll sein? Ab einer bestimmten Projektgröße ist es das, sogar sehr. > ... wie kann es dann so schrecklich falsch sein? "Falsch" ist vielleicht der falsche Ausdruck. Aber eine rein prozedurale Herangehensweise ist schlichtweg nicht der richtige Weg, wenn man ein Problem objektorientiert angehen möchte. Weder das eine, noch das andere ist der Königsweg, aber die Denkweise wird stark von beidem beeinflusst und behindert sich oftmals gegenseitig.
Sven schrieb: > Was mich noch auf die schnelle interessieren würde bevor ich anfange > mich tief einzulesen, was ist denn der Hauptunterschied zwischen den > STM32 und PIC32? Leistungstechnisch scheinen sie ähnlich, beide können > mit C++ programmiert werden, Starterkits sind ähnlich (Touch, TFT, USB > ...) Im Prinzip der Prozessorkern. Microchip verwendet hier einen MIPS-Kern, weil MIPS (jetzt Imagination Technologies, die mit den PowerVR GPUs, die in iPhones etc verwendet werden) geringere Lizenzgebühren verlangt. Auch in DSL-Routern und anderen Geräten, wo es nicht auf Binärkompatibilität ankommt, steckt MIPS drin. Für Dich ist es egal. Der Compiler verdeckt die Unterschiede. Was bei Microchip schön ist: Du bekommst dort alles aus einer Hand: IDE, Compiler, Debugger, Bibliotheken, und alles sauber aufeinander abgestimmt. Nachteil: Es gibt auch kaum Alternativen, denn anderer Hersteller stürzen sich eher auf andere Architekturen, mit denen mehr Geld zu verdienen ist. Aber Du bist bei Microchip gut aufgehoben. Als Bastler hast Du natürlich den Vorteil, dass Du Dir zwar ein Board kaufen kannst, es aber nicht musst. Um einen PIC32MX250F128B auf einer Lochrasterplatine in Betrieb zu nehmen, brauchst Du im Wesentlichen 10u Keramik oder Tantal, zwei 100n Abblockkondensatoren, und 10k an MCLR. Das wars, der Rest ist optional. Ist in einer Viertelstunde aufgebaut. fchk
Hans schrieb: > dieser Spinner Nun, Hochsprachenkonzepte sind allesamt ersponnen. Wenn man dabei die Entsprechung der menschlichen Intuition zum Sprachziel macht und nicht etwa irgendeine Eleganz, verpackt in phantasievollen, sprachgewaltigen, gedanklichen Winkelzügen, dann bedeutet jedes Mehr an aufzubringender Mühe und Zeit eine ganz unmittelbare Kontraindikation für die konkrete Sprachauswahl. Dem klaren, übersichtlichen unkomplizierte Hardwarekonzept zumindest der kleineren 8-Bitter sollte ohne Not keine intransparente, indirekte, konzeptüberladene Programmiermethodik aufoktroyiert werden. Außer die große Liebe gehört ihr- und nicht der eigentlichen Problemlösung ;-)
Um etwas spass zu haben: http://www.tux.org/lkml/#ss15 und ich muss ihm zustimmen. Es ist wesentlich leichter in c++ scheiss uneffizienten code zu schreiben als in C. einfach weil vieles versteckt wird. @ersteller: aber es ist überhaupt kein Problem in C++ das ganze zu programmieren, musst nur beim programmieren besser aufpasssen
Sven schrieb: > Welchen Controller + IDE + Compiler könnt ihr mir empfehlen? Der > Controller sollte Steckbretttauglich sein. Es wäre auch noch gut so > etwas wie C++ Lessons dafür zu haben mit Beispielen, gibts ja bei zB PIC > nur halt in C. Mir ist mal gesagt worden das C++ erst durch die eigene dynamische Speicherverwaltung (new,delete) Vorteile ausspielen kann. Ebenso würden Exceptions die Programmierrei erleichtern. Kann den das jedes C++ µC System? oder ist nicht erst bei Systeme mit mindestens 16k (??) RAM anfangen dynamische Speicherverwaltung möglich? Sind die C++ standardbibliotheken für jeden uC ausreichend vollständig implementiert um damit wirklich C++ mit seinen Möglichkeiten kennenzulernen? MfG,
Mobby hat von uC keine Ahnung, er versteht nichts von C un C++ kann er überhaupt nicht einordnen. So kennt man ihn zumindest aus dem Forum. :'( Warum störst du den Thread? Da warten noch ein paar verfusede avr auf dich. Du kannst wohl nur trollen. :-(
Normalerweile braucht/will man kein new/delete auf Mikrocontrollern.
cody schrieb: > Normalerweile braucht/will man kein new/delete auf Mikrocontrollern. und auch keine Exceptions
Gibt aber auch Features von C++ die gut sind und keinen Overhead haben: - Templates - Klassen - Namespaces
cody schrieb: > Gibt aber auch Features von C++ die gut sind und keinen Overhead haben: > - Templates Templates können ganz schön overhread erzeugen.
Fpga Kuechle schrieb: > Mir ist mal gesagt worden das C++ erst durch die eigene dynamische > Speicherverwaltung (new,delete) Vorteile ausspielen kann. Ebenso würden > Exceptions die Programmierrei erleichtern. Das ist sicherlich etwas verkürzt dargestellt. Klassen und Templates kann man sicher auch auf einem uC sehr sinnvoll einsetzten. Exceptions leider nicht, da das Stack-unwinding für ein uC in der Regel zu komplex ist.(Auch stellt sich die Frage, was man auf einem uC mit nicht abgefangenen Exceptions macht.) Die Speicherverwaltung ist nicht Teil der Sprache und new/delete lediglich Schnittstellen in die entsprechenden Bibliotheken. Die Standard-Speicherverwaltung ist für einen uC in der Tat nur bedingt geeignet, man kann aber durchaus eine eigene Speicherverwaltung bauen, die den jeweiligen Anforderungen besser angepasst ist.
Peter II schrieb: > cody schrieb: >> Gibt aber auch Features von C++ die gut sind und keinen Overhead haben: >> - Templates > > Templates können ganz schön overhread erzeugen. Templates werden vollständig zur Compile-Zeit ausgewertet, sie können also auf dem uC gar keinen Overhead erzeugen, allenfalls der durch sie generierte Code. Der hängt aber davon ab, wie ich die Templates einsetzte und wofür.
A. H. schrieb: > Templates werden vollständig zur Compile-Zeit ausgewertet, sie können > also auf dem uC gar keinen Overhead erzeugen, allenfalls der durch sie > generierte Code. Der hängt aber davon ab, wie ich die Templates > einsetzte und wofür. ok, ich meinte damit können den code recht stark vergrößern. Die Container werden für jeden Datentype umgesetzt. Das erzeugt recht viel Code. Klar hat man dafür auch viele Vorteile. es war bei mir sogar so, das jedes Template in jeder übersetzungseinheit auch mit dem gleichen Datentypen den code mehrfach erzeugt hat.
Zumindest die erste Begründung ist seltsam. In C hättest du genau so viel Code wenn du ihn für jeden Datentyp extra schreibst.
cody schrieb: > Zumindest die erste Begründung ist seltsam. > In C hättest du genau so viel Code wenn du ihn für jeden Datentyp extra > schreibst. richtig, aber dort würde man es vermutlich gar nicht machen. Da würde man das für einen void* Datentype machen und dann mit cast arbeiten. Ja schöner ist das damit nicht, aber sparsamer was die codegröße angeht. Das meinte ich mit overhread.
Peter II schrieb: > ok, ich meinte damit können den code recht stark vergrößern. Die > Container werden für jeden Datentype umgesetzt. Das erzeugt recht viel > Code. Klar hat man dafür auch viele Vorteile. Ja, das kann passieren. (Scharfe Messer können eben beißen :-) In solch einem Fall kann ich aber versuchen, eine generische Lösung z.B. mit void* zu implementieren und nur die Typprüfung ins Template zu verlagern. In C ohne Templates kann ein solches Vorgehen schnell im Hara-Kiri enden, in C++ habe ich dank der Kapselung durch das Templates immer noch eine typsichere Lösung. > es war bei mir sogar so, das jedes Template in jeder übersetzungseinheit > auch mit dem gleichen Datentypen den code mehrfach erzeugt hat. Stimmt auch. Was in einem Template implementiert wird ist in der Regel inline mit den entsprechenden Auswirkungen auf den Code. Deshalb ist es (im Allgemeinen wenigstens) auch nicht sehr klug, komplexe Funktionen im Template zu implementieren; besser ist in eine generische Funktion mit dem Template als Wrapper, der dann die entsprechenden Compile-Time-Checks macht. Die meiste Funktionen gerade auch der Standard-Container sind aber glücklicherweise so kurz, dass das keine Rolle spielen dürfte.
Peter II schrieb: > es war bei mir sogar so, das jedes Template in jeder übersetzungseinheit > auch mit dem gleichen Datentypen den code mehrfach erzeugt hat. Der Code wird zwar in jeder Übersetzungseinheit drin sein, aber nach dem Linken sollte der nur noch einmal da sein. Und darauf kommts ja an.
cody schrieb: > Der Code wird zwar in jeder Übersetzungseinheit drin sein, aber nach dem > Linken sollte der nur noch einmal da sein. Und darauf kommts ja an. war bei mir aber nicht der fall. Eventuell geht es ja mit LTO.
"C++ auf einem MC, wie geht das?" ****************************** hat mich motiviert mich einzulesen. [Beitrag "C++ auf einem MC, wie geht das?"] Beispielcode zeigt, wie ein c++ Programm für uC aussehen kann. text data bss dec hex filename 1086 34 16 1136 470 LCDTest_.elf aequivalent in C **************** text data bss dec hex filename 962 32 18 1012 3f4 ValueOut_.elf ****************************** Ich bin kein Informatik Profi, viel trial & error und "hat und gibt sich Mühe" ************************* Alexandra
Peter II schrieb: > cody schrieb: >> Normalerweile braucht/will man kein new/delete auf Mikrocontrollern. > > und auch keine Exceptions Und auch kein C++, also das ++ vom C.
Sebastian V. O. schrieb: > In C++ nimmt man einfach std::string Dazu mal ne Frage: was passiert genau wenn nicht genug Speicher (heap/stack) zum durchfuehren einer Stringoperation verfuegbar ist? Kann man das vorher ueberpruefen?
Also ich würde von C++ auf Mikrocontrollern abraten. Seine ganzen Vorteile spielt C++ bei dynamischen Sachen aus und gerade das hat man bei Mikrocontrollern nicht. Die Hardware ist fest und Speicher begrenzt. Finger weg von new und delete und std Containern. Gerade bei nur paar kB Speicher ist der schnell fragmentiert. Und auf PCs würde ich heutzutage, wenn es nicht auf jede Millisekunde ankommt, zu C# mit .Net Framework raten. ;-) Die ganzen C++ Fallstricke gibt es nicht mehr und die Klassenbibliothek ist sehr umfangreich.
Dumdi Dum schrieb: > Dazu mal ne Frage: was passiert genau wenn nicht genug Speicher > (heap/stack) zum durchfuehren einer Stringoperation verfuegbar ist? Kann > man das vorher ueberpruefen? Nein, dass kann man vorher nicht herausfinden! Auf einem großen Kessel würde sicherlich eine Exception geworfen. Der Fehler wäre also behandelbar. Auf einem µC kollidieren Heap und Stack. (gut dass es meistens einen WDT gibt)
MitLeserin schrieb: > aequivalent in C Hier wäre der c code zu den angaben noch wichtig. Ausserdem feht die Angabe des compilers und die Optionen. Der C++ code ist gut, aber kann sicher noch soweit optimiert werden, bis das Resultat exakt gleich wie das c equivalent ist. Dumdi Dum schrieb: > Sebastian V. O. schrieb: >> In C++ nimmt man einfach std::string > > Dazu mal ne Frage: was passiert genau wenn nicht genug Speicher > (heap/stack) zum durchfuehren einer Stringoperation verfuegbar ist? Vermutlich ne bad_alloc exception. Irgendwie kann man den Allocator ändern, um auf das implizite new zu verzichten.
Dumdi Dum schrieb: > Dazu mal ne Frage: was passiert genau wenn nicht genug Speicher > (heap/stack) zum durchfuehren einer Stringoperation verfuegbar ist? Kann > man das vorher ueberpruefen? Das sind eigentlich zwei Fragen in einer: 1.) Wie fordert ein Programm Speicher vom darunter liegenden Betriebssystem an? und 2.) Wie reagiert die Speicherverwaltung, wenn die Anforderung nicht erfüllt werden kann? Beide Fragen haben aber nichts mit der Sprache zu tun. Die Standard-Implementierung der Speicherverwaltung wir eine bad_alloc Exception werfen, Du kannst aber auch Deine eigene Speicherverwaltung implementieren für die der Standard dann auch einen Null-Pointer zulässt. In die kannst Du dann natürlich auch Abfragen einbauen, wie viel Speicher noch zur Verfügung steht. Mit der Standard-Implementierung geht das nicht. Das würde sich auch nur auf den Speicher beziehen können, der schon vom Betriebssystem angefordert wurde. Wie das geht, hängt vom Betriebssystem ab und natürlich davon, ob es überhaupt ein Betriebssystem gibt. Unter Unix/Linux gibt es dazu den brk/sbrk System Call. Eine Vorabfrage ist auf einem echten Multi-Task Betriebssystem schon deshalb nicht zuverlässig möglich, weil sich zwischen Abfrage und Anforderungen die Situation durch andere Prozesse schon wieder geändert haben kann.
@ Daniel A. ***************** aequivalent in C: valout.zip Original: ******** valout.zip: Beitrag "Formatierte Zahlenausgabe in C" (Peter Dannegger ) überarbeitet von Uwe S. ********************** valout.zip Beitrag "Variablenwert auf LCD ausgeben" (Uwe S|12-09-2011) Compiler C: ********** Atmel Studio 6,2 Atmel Toolchain\ : standard Makefile C Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-gcc.exe$(QUOTE) -x c -funsigned-char -funsigned-bitfields -DDEBUG -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=atmega644p -c -std=gnu99 -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)" -o "$@" "$<" Compiler: C++ ******** Atmel Studio 6,2 Atmel Toolchain\ : standard Makefile C++ AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-g++.exe$(QUOTE) -o$(OUTPUT_FILE_PATH_AS_ARGS) $(OBJS_AS_ARGS) $(USER_OBJS) $(LIBS) -Wl,-Map="LCDTest_.map" -Wl,--start-group -Wl,-lm -Wl,--end-group -Wl,--gc-sections -mmcu=atmega644p Toolchain optimieren: ********** kann ich derzeit noch nicht leisten. Konzept von Mcucpp finde ich interessant und ich versuche die verschiedenen Komponenten der Library im Detail zu verstehen und anzuwenden.
MitLeserin schrieb: > optimieren: > ********** > kann ich derzeit noch nicht leisten. Du könntest aber mal die Optimierung des Compilers für die C++ Variante einschalten (z.B. -Os)
@ Torsten Robitzki Danke für den Hinweis, wieder was gelernt... LCD_Test C++ ***************************************************** optimize -O1 (default) ***************************************************** text data bss dec hex filename 1086 34 16 1136 470 LCDTest_.elf optimize most -O3 // Debug ***************************************************** text data bss dec hex filename 1000 34 16 1050 41a LCDTest_.elf optimize for size -Os ***************************************************** text data bss dec hex filename 1118 34 16 1168 490 LCDTest_.elf ValueOut C ***************************************************** optimize -O1 (default) ***************************************************** text data bss dec hex filename 962 32 18 1012 3f4 ValueOut_.elf optimize most -O3 ***************************************************** text data bss dec hex filename 1162 32 18 1212 4bc ValueOut_.elf optimize for size -Os ***************************************************** text data bss dec hex filename 866 32 18 916 394 ValueOut_.elf (Werte für Release sind identisch zu Werten für Debug)
MitLeserin schrieb: > LCD_Test C++ > ***************************************************** > 1086 34 16 1136 470 LCDTest_.elf > optimize most -O3 // Debug > 1000 34 16 1050 41a LCDTest_.elf > optimize for size -Os > 1118 34 16 1168 490 LCDTest_.elf Kein Tippfehler??!! -> ? Also bei diesem C++ Compiler ist bei Optimierung auf Größe das Ergebniss am Größten? Das ist unerwartet. Das das Ergebniss für C++ größer ist als bei C dagegen nicht. MfG,
Frank K. schrieb: > Was bei Microchip schön ist: Du bekommst dort alles aus einer Hand: IDE, > Compiler, Debugger, Bibliotheken, und alles sauber aufeinander > abgestimmt. > > ...Um einen PIC32MX250F128B auf einer > Lochrasterplatine in Betrieb zu nehmen, brauchst Du im Wesentlichen 10u > Keramik oder Tantal, zwei 100n Abblockkondensatoren, und 10k an MCLR. > Das wars, der Rest ist optional. Das sind natürlich starke Argumente.
Ich hab sowohl auf einem ARM7 als auch auf einem AVR schon in C++ programmiert. Aber ganz ehrlich ... Ich seh den Hauptvorteil von C++ gegenüber C eigentlich nur in der Kapselung des Codes in Klassen ... Vererbung wird interessant, wenn man v.m.a. eine SD-Card-Library baut, die auf Flat-Files zugreifen kann und man dann zB per Vererbung eine FAT32-Lib bauen möchte oder soetwas ... Ansonsten tendiert man in C++ eher recht einfache Sachen überkompliziert zu lösen ... Mittlerweile hat für mich C++ die Relevanz komplett verloren. Bin jetzt nur noch mit C, Python und Java (wenn es sein MUSS) unterwegs :-)
Gut ich hätte kein Problem damit C zu lernen, parallel lerne ich ja sowieso C++, schaden tuts sicher nicht beides parallel zu lernen. Welches Buch könnt ihr mir empfehlen? Darf auch englisch sein. K&R ist ja sehr bekannt, soll aber nicht für Anfänger geeignet sein, eher für Fortgeschrittene und ich bin Anfänger.
Ach die alte Frage... welches ist die beste Sprache? Glaubenskriege.... Frage 3 Leute und du bekommst 5 Meinungen, und alle haben recht. Die beste Sprache ist Forth! Zumindest habe ich durch die Beschäftigung mit Forth intensiv gelernt. Mein Tor zu den Hochsprachen. (wobei man sich da bei Forth nicht sicher sein darf, ob Hochsprache, oder nicht) OOP gabs damals noch nicht (vielleicht in Ansätzen) Forth hatte da seine Komponenten orientierte Sicht auf die Dinge. Die Forth Vocabularies entsprechen, in etwa, den modernen Namespaces Nichts gegen C, ich fand es früher fürchterlich. Nicht viel mehr als ein MacroAssembler. Da konnte man 2 Buchstaben addieren, die Wurzel draus ziehen, und das Ergebnis als Pointer auffassen. Ein Gürteltier auf der Tastatur wälzen, und der Compiler hat 2 Warnings geworfen. Nach so ein paar Umwegen, über Pascal (auch OO) , Java, und lange PHP, bin ich jetzt bei Arduino und C++. Mampf F. schrieb: > Kapselung Das dürfte das Hauptargument für OO sein. Egal welche Sprache. Wartbarkeit, Wiederverwendung und weniger Möglichkeiten für unerwünschte Seiteneffekte.
Sven schrieb: > Gut ich hätte kein Problem damit C zu lernen, parallel lerne ich ja > sowieso C++, schaden tuts sicher nicht beides parallel zu lernen. > Welches Buch könnt ihr mir empfehlen? Darf auch englisch sein. K&R ist > ja sehr bekannt, soll aber nicht für Anfänger geeignet sein, eher für > Fortgeschrittene und ich bin Anfänger. Noch einmal zum Mitschreiben: C ist eine Untermenge von C++. Wenn Du C++ beherrscht beherrschst Du auch C. Beherrschen heißt in diesem Zusammenhang aber nicht nur die Syntax zu kennen, sondern auch zu wissen, wann Du welches Sprachmittel wie einsetzt. Das schließt auch ein zu wissen, wann Du auf welches Sprachmittel lieber verzichtest. Wenn Du bei der Analyse Deines Problems zu dem Schluss kommst, dass Du Dich besser auf die Untermenge von C++ beschränkst, die sich C nennt, dann nimm C. Es kann auch Gründe außerhalb der Sprache für diese Entscheidung geben, etwa Portabilität. In jedem Fall aber hängt die Entscheidung von Deinem Problem ab, nicht von der Sprache. Ich halte K&R übrigens keinesfalls für zu schwer und auch für den Anfänger für die beste Wahl, schon weil sie auch nicht wenig darüber erzählen, warum bestimmte Entscheidungen beim Entwurf der Sprache so und nicht anders gefallen sind. Das ist auch für den eingefleischten C++ Programmiere keine überflüssige Lektüre.
Ulrich F. schrieb: > Das dürfte das Hauptargument für OO sein. Egal welche Sprache. > Wartbarkeit, Wiederverwendung und weniger Möglichkeiten für unerwünschte > Seiteneffekte. Ich weiß nicht wie oft diese Weisheiten in den letzten 25 Jahren so verbreitet wurden. Wahrer werden sie deshalb nicht. Eine vernünftig strukturierte C-Lib kann genauso wartbar und wiederverwendbar sein. Genau so gut sind viele C++ Libs nur sehr schlecht wartbar und wesentlich schwerer zu durchschauen als traditioneller C-Code. Wenn man versucht, das was in den Lehrbüchern zu C++ steht auf einen kleinen µC zu implementieren, dann wir man schnell das Fluchen lernen. Hier ist es schon angebracht einen kritischen Blick auf große Teile der STL zu werfen. Insbesondere auch bei Strings. So was wie Speicherfragmentierung interessiert auf dem PC kaum noch jemanden. Bei 16kb RAM kann das aber ganz anders aussehen. Wie immer, man muss wissen was man tut.
Ulrich F. schrieb: > Die beste Sprache ist Forth! > Zumindest habe ich durch die Beschäftigung mit Forth intensiv gelernt. > Mein Tor zu den Hochsprachen. > (wobei man sich da bei Forth nicht sicher sein darf, ob Hochsprache, > oder nicht) Ich würde so weit mitgehen zu sagen, das Forth die beste Sprache zum Lernen ist, schon deshalb, weil schon zwei Zeilen zusammenhängenden Forth-Codes so unlesbar sind, dass sie den Anfänger von der ersten Zeile an zum radikalen Strukturieren zwingen. Und natürlich gewährt Forth Einblicke, wie ein moderner Compiler hinter den Kulissen arbeitet, eigentlich ein Muss für jeden ernst zu nehmen Programmierer. Freiwillig anwenden würde ich die Sprache aber allenfals noch als Zielcode in selbst gebauten Compileren. So gesehen ist Forth quasi das Latein der Programmiersprachen.
> Speicherfragmentierung
Dafür braucht man kein ++, da reicht schon C.
Und ja, nicht alle Features der OOP Welt machen auf einem µC Sinn.
Aber was man "mitnehmen kann" kann man ja auch nutzen, wenn man möchte
und Platz und Kenntnis dafür reichen.
Abseits von allen Glaubenskriegen: Es ist wichtig, was hinten raus
kommt...
Sind die Anforderungen erfüllt?
Tuts das, was man will?
Hallo Daniel, Daniel A. schrieb: > MitLeserin schrieb: >> aequivalent in C > > Hier wäre der c code zu den angaben noch wichtig. > Ausserdem feht die Angabe des compilers und die Optionen. > > Der C++ code ist gut, aber kann sicher noch soweit optimiert werden, bis > das Resultat exakt gleich wie das c equivalent ist. Im von der MitLeserin verlinkten Thread habe ich das mehrmals gemacht. Bei äquivalentem Code sind die von g++ generierten Binaries nur selten größer als die vom gcc mit denselben Compilereinstellungen. Und wenn sie einmal größer sind, dann in der Regel nur ein paar Bytes. Allermeistens optimiert der Compiler die Klassen und Methoden dabei einfach weg. In einem Fall war das von g++ erzeugte Binary sogar minimal kleiner als das von gcc. Die große Ausnahme, für die ich bislang noch keine Lösung gefunden habe, betrifft globale Variablen, die in einer ISR() und anderen Funktionen wie main() verwendet werden. Da scheint der GCC nicht gut zu optimieren. Liebe Grüße, Karl
Ulrich F. schrieb: >> Speicherfragmentierung > Dafür braucht man kein ++, da reicht schon C. Das ist nicht ganz richtig. Um in C dynamischen Speicher zu allocieren muss man das explizit hinschreiben. Der unbedarfte Umgang mit der STL insbesondere bei Strings und Listen verbirgt das komplett vor dem Anwender. Und wer weiß dann wirklich was genau ab geht.
A. H. schrieb: > Noch einmal zum Mitschreiben: C ist eine Untermenge von C++. Wenn Du C++ > beherrscht beherrschst Du auch C Das stimmt so nicht. Wenn C++ ein Superset von C wäre, und C ein Subset von C++, würde ich in C++ Compound Literale nicht vermissen, und dürfte mich in C nicht an Designated Initializers erfreuen. Ausserdem kann man anhand eines Supersets kein Subset erkennen.
temp schrieb: > Das ist nicht ganz richtig. Um in C dynamischen Speicher zu allocieren > muss man das explizit hinschreiben. Das ist in C++ genau so. Weder in C, noch in C++ sehe ich es einer Libray sofort an, ob sie dynamischen Speicher verwendet. Man kann es sich aber in der Regel ganz gut denken; eine Library für verkettet Listen in C wird sehr wahrscheinlich auch malloc/free intern verwenden.
Daniel A. schrieb: > A. H. schrieb: >> Noch einmal zum Mitschreiben: C ist eine Untermenge von C++. Wenn Du C++ >> beherrscht beherrschst Du auch C > > Das stimmt so nicht. Praktisch gesehen stimmt das schon, doch. In diesem Thread http://stackoverflow.com/questions/3879636/what-can-be-done-in-c-but-not-c wird besprochen, was es in C, aber nicht in C++ gibt. Sämtliche dieser wenigen Features lernt man zusammen in 15 Minuten, und bis auf "variable length arrays" handelt es sich wirklich nur um ein bisschen syntaktischen Zucker und/oder Workarounds für Probleme, die man in C++ gar nicht hat. Oder sag mir ein einziges Feature, wo man mit C++ wirklich im Regen steht.
Torsten Robitzki schrieb: > Das ist in C++ genau so. Im Prinzip hast du recht. Aber nur im Prinzip. Leute die heute C++ neu lernen ohne schon mal C programmiert zu haben, lernen die grundlegende Syntax und dann erst mal massenhaft STL. Mit anderen Worten C++ und STL sind für die untrennbar miteinander verbunden. Keiner käme auf die Idee für einen String einen Buffer zu verwenden, weil ja die Pointer so böse sind und es std::string gibt. Plötzlich werden aus Konstrukten bei denen strstr, strtok u.s.w. reichen würden Konstrukte die jedesmal wieder für 5 Zeichen lange Strings 20Byte dynamischen Speicher haben wollen. Klar muss ich mir eine Lib genau ansehen wenn ich sie verwenden will. Es ging mir aber um die Libs die jemand lernt wenn er heute mit C oder C++ anfängt. Vor allem auf den kleinen Controllern um die es hier ging. Sobald ein richtiges Betriebssystem vorhanden ist, sind diese Betrachtungen oft nicht mehr nötig.
Ja genau ... Oder arbeiten von hausaus mit Boost, weil das ja alles kann, was man jemals benötigen wird. Dass die Header-Files alleine schon 130MB Source-Code haben und der Kram ja nicht vorkompiliert wird, da alles Templates ... und dass dann viel reinkompiliert wird, was man garnicht braucht ... Genauso wird dann jemand, der C++ gelernt hat evtl versuchen mittels std::cout etwas ausgeben zu wollen usw ... C++ kann man verwenden, wenn man weiß, was sinnvoll ist und jede Menge Erfahrung mit C hat - quasi den Unterbau kennt. Noch besser, wenn man C und Assembler kann
P. M. schrieb: > Daniel A. schrieb: >> A. H. schrieb: >>> Noch einmal zum Mitschreiben: C ist eine Untermenge von C++. Wenn Du C++ >>> beherrscht beherrschst Du auch C >> >> Das stimmt so nicht. > > Praktisch gesehen stimmt das schon, doch. Eine Untermenge ist immer volstendig in der Obermenge Enthalten. Mit C und C++ trifft das nicht zu. Weder theoretisch noch praktisch. > In diesem Thread > http://stackoverflow.com/questions/3879636/what-can-be-done-in-c-but-not-c > wird besprochen, was es in C, aber nicht in C++ gibt. Sämtliche dieser > wenigen Features lernt man zusammen in 15 Minuten, und bis auf "variable > length arrays" handelt es sich wirklich nur um ein bisschen > syntaktischen Zucker und/oder Workarounds für Probleme, die man in C++ > gar nicht hat. Die Leute aus dem verlinkten Thread schauen wohl durch die Rosa C++-Brille. Diese "Workarounds" sind nicht mit ihrem C++ Lösungsansatz zu vergleichen. > Oder sag mir ein einziges Feature, wo man mit C++ wirklich im Regen > steht. Compound Literale: Stelle dir eine einfache Menustruktur vor, in c z.B. so:
1 | // ungetestet
|
2 | struct menu; |
3 | struct menu { |
4 | char* name; |
5 | struct menu* submenu; |
6 | };
|
7 | struct menu menu = { |
8 | .name = "test", |
9 | .menu = (struct menu[]){ |
10 | {
|
11 | .name = "a" |
12 | },{
|
13 | .name = "b" |
14 | }
|
15 | }
|
16 | };
|
Soetwas ist nur in C derart einfach möglich. Um das selbe in C++ zu erreichen benötigt man entweder dynamische Speicherreservirung, oder mehrere Declarationen, oder mehrere templatetypen, oder mehrere CopyConstructor aufrufe zur runtime. Wie kann das besser sein? Designated Initializers: Nun der Code oben ist schonmal einfacher zu lesen als ohne. Ausserdem kann man damit named arguments Emulieren. Dies ist in C++ unmöglich.
1 | // ungetestet
|
2 | struct x { |
3 | int *a,*b,*c; |
4 | };
|
5 | void func(struct x x){ |
6 | }
|
7 | #define func(...) func((struct x){VA_ARGS})
|
8 | |
9 | ///////////
|
10 | |
11 | func(.b=(int[]){2}); |
Versteht mich nicht falsch, ich finde C++ eine wunderbare Sprache, aber sie ist nicht perfekt, und nur wenige können tatsächlich damit umgehen.
:
Bearbeitet durch User
temp schrieb: > Im Prinzip hast du recht. Aber nur im Prinzip. Leute die heute C++ neu > lernen ohne schon mal C programmiert zu haben, lernen die grundlegende > Syntax und dann erst mal massenhaft STL. Mit anderen Worten C++ und STL > sind für die untrennbar miteinander verbunden. Keiner käme auf die Idee > für einen String einen Buffer zu verwenden, weil ja die Pointer so böse > sind und es std::string gibt. Das ist nicht ein Problem des C++-Lernens, sondern ein Problem von Programmiereinführungen, die nicht genügend auf die technischen Aspekte eingehen. Wer nicht lernt, wie ein Programm und diverse Bibliothekskonstrukte intern funktionieren, der wird sich mit C, C++ oder Java genau gleich verfranzen. Ich bin sogar der Meinung, C++ eigne sich sehr gut zur Programmiereinführung. Weil kaum eine andere Sprache abstrakte Aspekte des Software-Engineering so direkt mit technischen Implementationsdetails verknüpft. Beispielsweise wenn man eigene Operatoren für Vergleich und Zuweisung definiert, am besten noch unter Verwendung von rvalues. Da sieht man so richtig, was der Compiler intern macht und muss sich gleichzeitig Gedanken dazu machen, was aus Sicht des benutzenden Programmierers Sinn ergibt.
:
Bearbeitet durch User
Re: Welchen Controller für C++ Programmierung? Einen Controller der dynamische Speicherverwaltung unterstützt, den viele C++ Eigenschaften basieren darauf gewisse Speicherbereiche dynamisch zu erweitern. Insbesondere in multi-threaded Applikationen. Also ein Controller mit MMU, und das ist wiederum kein kleiner Controller. Wer einen Controller mit flat-memory, also einfachen linearen Speicher verwendet, sollte stets Speicherfragmentierung vermeiden. Das geht durchaus, indem man mit entsprechenden Memory Schematas, bzw. Allokatoren arbeitet, also z.B. guarded Memory-Pools fester Grösse. D.h. man macht sich sinnvoller weise Gedanken um das Geschehen in den unteren Schichten und schon bröselt C++ implizite Eleganz, da es da unten im Keller in C einfacher geht. Oder seh ich da was falsch?
Bodo Gravert schrieb: > Einen Controller der dynamische Speicherverwaltung unterstützt, > den viele C++ Eigenschaften basieren darauf gewisse Speicherbereiche > dynamisch zu erweitern. > ... > Oder seh ich da was falsch? Ich würde sagen, ja, falsch. Ich arbeite sehr hardwarenah (nicht Mikrocontroller) mit C++ und man muss hier wirklich mit KEINERLEI Overhead gegenüber einer C-Lösung auskommen. Aber man muss wissen, wie die Sprache und ihre Bibliothek funktionieren. Das gehört aber eigentlich zu einem anständigen Programmierer dazu :-)
Daniel A. schrieb: > Soetwas ist nur in C derart einfach möglich. Um das selbe in C++ zu > erreichen benötigt man entweder dynamische Speicherreservirung, oder > mehrere Declarationen, oder mehrere templatetypen, oder mehrere > CopyConstructor aufrufe zur runtime. Das ist falsch. Seit C++11 gibt es für solcherlei Dinge formal constexpr, allerdings haben die Compiler (MSVC, GCC) das auch vorher wegoptimiert (statische Initialisierungen wegoptimieren ist sehr einfach) und optimieren das auch ohne explizites constexpr. Touche für designated Initializer, das ist eine elegante und sehr "zeichenarme" Syntax, die C++ - vom Standard her - nicht hat. Man kann sich allerdings (wie üblich ohne Runtime-Overhead) ähnliche Dinge bauen. Zugegebenermaßen ist diese Menü-DSL dann nicht so schön wie DIs.
Daniel A. schrieb: > Soetwas ist nur in C derart einfach möglich. Ganz böse Zungen könnten jetzt natürlich auch fragen, warum es in C++ keine Designated Initializer gibt. Ich frage mich z.B., wie man sowas kopieren würde. Oder könnte man überhaupt eine Funktion schreiben, die einen Pointer auf das Wurzel-Struct als Parameter nimmt und dann das Menu ausgibt? Wohl nicht, ohne Zusatzinformationen mitzuliefern.
Welchen Controller für C++ Programmierung? war die Frage! .. und keine Auforderung zu Selbstdarstellung ..
Hallo Daniel, Daniel A. schrieb: > Soetwas ist nur in C derart einfach möglich. Die drei Dateien im Anhang habe ich mit g++/4.9.1 und clang++/3.5.0 übersetzt. Warnungen gibt es meistens nur mit -Wpedantic und die C++11-Features in o.cpp kompilieren nur mit -std=c++11 (bzw. -std=gnu++11). Liebe Grüße, Karl PS: Ja, ich weiß, daß das nicht standardkonform ist. Allerbesten Dank für die freundlichen Hinweise. ;-)
P. M. schrieb: > Daniel A. schrieb: >> Soetwas ist nur in C derart einfach möglich. > > Ganz böse Zungen könnten jetzt natürlich auch fragen, warum es in C++ > keine Designated Initializer gibt. Ich frage mich z.B., wie man sowas > kopieren würde. Was meinst du mit "sowas"? Einen Initialiser kann man nicht Kopieren, Werte und Objekte kann man kopieren, aber das hat nichtsmehr mit einer Initialisierung zu tun. Falls du dich auf die Datenstruktur im Beispiel Beziehst, diese zu kopieren wird dadurch auf Designated Initializer zu verzichten nich einfacher. > Oder könnte man überhaupt eine Funktion schreiben, die > einen Pointer auf das Wurzel-Struct als Parameter nimmt und dann das > Menu ausgibt? Wohl nicht, ohne Zusatzinformationen mitzuliefern. Spielst du auf die fehlende Mengenangabe der Menueinträge im Strukt aus dem Beispielmenu an? Die hab ich der Einfachheit weggelassen, damit nimand auf die Idee kommt den Designated Initializer für das Fehlen der möglichkeit in C wärend des Initialisierens des Objects auf dessen member zuzugreifen verantwortlich macht. C++ mag dort einen vorteil haben, aber mit c makros ist das kein Problem:
1 | // ungetestet
|
2 | #define MENU_ITEMS(x) \
|
3 | .items = x, \
|
4 | .count = sizeof x
|
5 | |
6 | struct menu; |
7 | struct menu { |
8 | char* name; |
9 | struct menu* items; |
10 | unsigned count; |
11 | };
|
12 | |
13 | struct menu menu = { |
14 | .name = "test", |
15 | MENU_ITEMS(((struct menu[]){ |
16 | {
|
17 | .name = "a" |
18 | },{
|
19 | .name = "b" |
20 | }
|
21 | }))
|
22 | };
|
Bodo Gravert schrieb: > Welchen Controller für C++ Programmierung? > > war die Frage! Den gleichen wie zur C Programmierung. Es gibt 2 Faktoren: * Minimal benötigte IO, Ram, Flash * Erfahrung (zwischen 0 und 1) Rechne dann minimalen IO, Ram und Flashbedarf mal (2-erfahrung) mal 1.2. Alternative: Schreibe zuerst dass Programm, Compilire und Teste es, und kaufe dann den Billigsten der Anwendung ausreichenden UC. Da es hier aber eher um den Einstieg geht empfehle ich einen kleinen ATiny für Hello World und nen grossen ATmega für interessantere Dinge. Das ist aber erst die halbe miete, die wahl des richtigen Programmers kann entscheidend sein. Zusetzlich ist ein Steckbrett und vorkentnisse in Elektrotechnik nützlich. Als IDE kommt von Eclipse über AvrStudio bis zu meinem Favorit: kate + shell + makefile alles in frage. PS: Ich bin ein Arduino Gegner. PPS: Man sollte immer einige ersatz-UCs haben.
:
Bearbeitet durch User
Es gibt jede Menge Meinungen zu C und C++ wie ich sehe, daher eine andere Frage: Ist der "C Primer Plus" vom Inhalt her überdimensioniert für die Programmierung von Mikrocontrollern? Wie siehts bei Mikroprozessoren aus (wenn das Projekt mal komplizierter wird zB eine kleine Werkzeugmaschine mit 3 Achsen)? Oder reicht der K&R hierfür immer noch aus?
> Oder reicht der K&R hierfür immer noch aus? Zumindest bietet er eine ordentliche Startmenge. Zusätzlich sind die Datenblätter von allen beteiligten Komponenten sicherlich sehr hilfreich und teilweise auch notwendig. Sven schrieb: > C Primer Plus Ist mir nicht bekannt Wie schon in den Vorpostings deutlich wurde, sind im Bereich C/C++ auf µC etliche Randbedingungen zu beachten. Es gibt Bücher, welche sich auf diesen Bereich eingeschossen haben. Vielleicht wäre das eine gute Zusatzliteratur zum K&R.
Sven schrieb: > Es gibt jede Menge Meinungen zu C und C++ wie ich sehe, daher eine > andere Frage: > > Ist der "C Primer Plus" vom Inhalt her überdimensioniert für die > Programmierung von Mikrocontrollern? 'überdimensioniert' gibt es nicht. Denn die kleinen Feinheiten in C (genauso wie in C++), die du am Anfang lernst, belegen schon mal gut und gerne die Hälfte jeder Literatur. Und die muss man beherrschen. Was auf der Mikrocontrollerebene ein wenig zurück tritt: * Arbeiten mit Dateien * dynamische Speicherallokierung Allerdings zeigt die Praxis, das man über kurz oder lang sich auch irgendwelche Hilfsprogramme auf dem PC machen wird bzw. muss. Und dann werden auch diese Themen relevant. > Wie siehts bei Mikroprozessoren aus > (wenn das Projekt mal komplizierter wird zB eine kleine Werkzeugmaschine > mit 3 Achsen)? Oder reicht der K&R hierfür immer noch aus? Grundsätzlich musst du unterscheiden zwischen der standardisierten Sprache und systemspezifischen Erweiterungen. Die standardisierte Sprache ist (mit allen Ausnahmen) überall die gleiche, die Regeln wie Datentypen in Ausdrücken die Auswertung beeinflussen sind zb überall dieselben, auch wenn unterschiedliche Systeme eine unterschiedliche Ansicht darüber haben, wie gross ein int ist. Kennt man die standardisierte Sprache erst mal, dann sind die systemspezifischen Erweiterungen (zb wie greift man auf ein Portbit zu) relativ einfach zu lernen. Oft wird das auch so gemacht, dass das ganze wie Standard-C aussieht und der Compiler erkennt das und setzt es entsprechend um (zb beim GCC). In der µC-Programmierung arbeitet man oft mehr auf Bitlevel als in der Desktopprogrammierung. D.h. mit den Bitoperationen muss man umgehen können. Das kann man allerdings auch auf einem reinen Desktopsystem lernen, auch wenn diese Dinge in der Literatur eher stiefmütterlich behandelt werden. Aber so um die 90% der Sprache funktionieren da wie dort identisch. Wer von einem Desktop System ein ordentliches Fundament an Sprach-Kentnissen mitbringt, tut sich in der µC-Welt relativ leicht.
:
Bearbeitet durch User
Such dir irgend eine MCU Architektur die breit vertreten ist und eine agile Community hat, z.b. Arduino. Sieh zu das du eine freie Tool-Chain nutzen kannst. Wie z.B. Arduino, hier wird implizit der avr-gcc genutzt. Ein wirklich gutes Werkzeug. Den Weg vom Arduino kannst du über den Teensy nehmen, dann bist du in der ARM Cortex-Mx Welt und hast eine moderne 32 Bit Risc Architekur vor dir und arbeitest mit relativ ähnlichen Werkzeugen, arm-none-eabi-* gcc toolchain. Wieder ein Hauch C++, aber halt genug um einen Microcontroller der 80-100 Mips (Performance diesmal) Klasse zu bewegen. Wenn dir die Arduino IDE (Integrated Development Environment) auf den Geist geht, was bei den meisten wohl irgendwann der Fall ist, dann kannst du immer noch weiterhin mit der gcc-tool-chain arbeiten, lernst ein Makefile zu erzeugen, und nutzt z.B. die unix-tool-box oder was GUI basiertes wie Eclipse. Du kannst aber auch direkt von oben in die 32-Bit RISC Welt einsteigen. Kaufst dir für kleines Geld (15 Euro) ein STM32F4-Discovery Board und ziehst dir von https://launchpad.net/gcc-arm-embedded die Pre-built GNU toolchain from ARM Cortex-M & Cortex-R processors (Cortex-M0/M0+/M3/M4/M7, Cortex-R4/R5/R7). Aber unterschätz das nicht, das sind moderne Full-Size 32 Bit RISC SoCs (System on Chip). Ein STM32F405 macht aus dem Stand 220 DMIPS und hat eine 32 Bit (single float) FPU und ISA (Instruction Set Architecture) Erweiterungen die in zu einem ganz passablen DSP machen. Also ein generischer RISC Mikrocontroller mit DSP Fähigkeiten. Damit lassen sich gut und gerne 90% aller embedded Industrie Applikationen erschlagen. Und noch was, lass dich nicht täuschen. Einen 32-Bitter nach POR (Power-On-Reset) main() ausführen zu lassen, benötigt detailliertes Verständniss der MCU Architektur. Da muss man die Augen spitzen und in die Hardware Dokumentation des betreffenden Chip eintauchen, die fast immer in Englisch. Aber wenn man sowas wie die Arduino oder Teensy IDEs nutzt, hat man erstmal das Vergnügen direkt mit den Pads der MCU zu wackeln. Einen Steppermotor kann man gut und effizient mit einem AVR bewegen, sollte es ein SVPWM geregelter PMSM* oder BLDC* Motor werden braucht man einen Cortex-Mx. *PMSM - Permanent Magnet Synchronous Motor *BLDC - Brushless Direct Current Motor
:
Bearbeitet durch User
Schau dir mal den folgenden Thread an: Beitrag "Keil free für STM32F0" mit Keil kannst du sehr gut in c++ entwickeln und debuggen. Vorteil ist noch der eingebaute Simulator, damit lassen sich auch sehr gut Unittests ohne Hardware (z.B. simulierte Uart-Ausgabe) durchführen. Das gleiche geht auch mit dem Debugger auf dem STM32F0-Discoveryboard (Uart Ausgabe). Auf jeden Fall läßt es sich damit erstmal einfach und kostenlos in die STM32F0 Welt einsteigen. Später kannst du dann auch auf die GCC-Toolchain wechseln.
Ich bin wohl gerade in einer ähnlichen Situation, und arbeite mich in stm32duino ein. Benutze dazu die Arduino IDE und eines der Stm32c8t6 minimum dev boards von eBay (knapp 4,-). Ist nicht ganz so einfach wie Arduino, aber zumindest compiliert mal was.
Persönlich würde ich für den Anfang raten, auf einer möglichst einfachen Architektur und direkt mit C oder C++* zu starten, ohne irgendwelche Libraries oder Plattformen dazwischen. Es ist sehr lehrreich, wenn man mal wirklich das gesamte System durchschauen kann. * So lange man keine virtuelle Vererbung und keine STL verwendet. Später, wenn man weiss was man tut, kann man diese Features dann dazu nehmen - nicht alle, nicht immer und nicht zu exzessiv.
Bodo Gravert schrieb: > MCU agile Community Tool-Chain Mips IDE GUI SoCs DMIPS FPU ISA > POR SVPWM PMSM BLDC Inhaltlich d'accor, aber ich habe selten so eine Ansammlung von absichtlichen Fachsprech-Abkürzungen gelesen "soll wohl den Eindruckerwecken: ich Firma, ich Ahnung, ich kann Fachchinesisch", aber immerhin erklärt er die meisten.
deshalb schreibt er auch: >Aber unterschätz das nicht, das sind moderne Full-Size 32 Bit RISC SoCs >(System on Chip). Ein STM32F405 macht aus dem Stand 220 DMIPS ....
Also ich habe alles verstanden, er hat immerhin alle Fachausdrücke erklärt. Viele hier im Forum benutzen Fachausdrücke nur erklären diese dann nicht, ganz anders Bodo Gravert.
Danke, ich such mir das nicht aus. Wir bewegen uns halt im amerikanischen Sprachraum. Keiluser: Stimmt du könntest auch mit Keil durchstarten. Je nachdem auf welcher Hostplatform du dich bewegst. Aber ich würde einen Cortex-M4F (zb. STM32F4- oder STM32F429-Discovery) nehmen. Der M4 hat einige interessante Debug Features, die auf dem kleinen M0 nicht vorhanden sind. Nimmt man ein STM32F429-Discovery, dann bekommst du für wenig Geld ein QVGA Display und 8MByte SDRAM, das für ca. 25 Euro. Single-Wire-Debug Interface (SWD) ist On-board.
Was mich noch interessieren würde: Gibt es für den Cortex-M4F und PIC32 auch sowas wie "Lessons" zB direkt vom Hersteller? Oder etwas in der Art wo mal demonstriert wird wie man die Peripherie nutzt. Bei den 8 Bit PICs gibts das PICKit3 Debug/Express Kit, dort sind C-Lessons dabei, zugeschnitten auf den PIC18F45K22. Wäre für mich eigentlich das Entscheidungskriterium schlechthin, denn ohne sowas wäre ich aufgeschmissen.
Für Arduino gibt es hält massig Tutorials. Deshalb nahm ich das ja. Wobei halt noch nicht alles auf den stm32 portiert ist. Die Details gibt es im Forum www.stm32duino.com .
Schau dir die Arduino Szene an: https://en.wikipedia.org/wiki/Arduino http://www.wired.com/2012/10/arduino-due/ https://www.sparkfun.com/ https://www.sparkfun.com/products/12646 http://www.pjrc.com/teensy/first_use.html
www.stm32duino.com, richtig, hat ich noch nicht wahrgenommen. Hier werden auch die sogenannten Nucleo-Boards, also STM32xyz mit Arduino Uno Footprint verwendet. Ich denke bei der Wahl hat man viel Qual.
Für die Cortex-M0/3/4 gibt es noch mbed: https://developer.mbed.org/ Eine Online IDE mit Compiler und Versionsverwaltung, dazu eine Basislib für Digitale/Analoge IO, SPI/I2C, Timer und einiges mehr. Weiterhin eine ganze Menge Libs für externe Komponenten wie Displays, Sensoren, Aktoren usw. Alles in C++ und durch die offenen Quellen gut zu verwenden. Damit wird der Einstieg in die Cortex Welt sehr einfach, ähnlich wie Arduino aber um einiges offener/besser. Hardware war ursprünglich nur ein LPC1768 von NXP, jetzt sind aber auch STM und eine Menge Exoten dabei. Man muss nicht unbedingt die offiziel unterstützte HW benutzen, ich arbeite gerne mit einem LPC1347 Breakoutboard, einem Projekt was auf Github zu finden ist: https://github.com/sebseb7/pentarm13uxx
Vielen Dank für die ganzen zusammengetragenen Infos. jetzt noch eine abschließende Frage, etwas off-topic, aber ich würde gerne noch ein englischsprachiges Buch über C empfohlen bekommen. Es sollte ein gutes Buch sein, am besten das beste :-)
Sven schrieb: > Was mich noch interessieren würde: > > Gibt es für den Cortex-M4F und PIC32 auch sowas wie "Lessons" zB direkt > vom Hersteller? Oder etwas in der Art wo mal demonstriert wird wie man > die Peripherie nutzt. > Bei den 8 Bit PICs gibts das PICKit3 Debug/Express Kit, dort sind > C-Lessons dabei, zugeschnitten auf den PIC18F45K22. Wäre für mich > eigentlich das Entscheidungskriterium schlechthin, denn ohne sowas wäre > ich aufgeschmissen. Bei den Compilern sind die Peripheriebibliotheken gleich dabei, für komplexere Sachen wie USB und TCP/IP gibts die Microchip Application Libraries. Und AppNotes gibts so viele, da kommt Du mit dem Lesen nicht hinterher. fchk
C Programming Language (2nd Edition) Kernighan and Ritchie, was sonst ?
Ja das K&R wird allseits empfohlen, aber nicht für Anfänger, es soll ein Nachschlagewerk sein jedoch kein Anfängerlehrbuch. Ich suche ja ein Lehrbuch. Was ist vom C Primer Plus zu halten oder von Nitty Gritty C? wird hier im uC Forum ja auch erwähnt.
newbie schrieb: > Ja das K&R wird allseits empfohlen, aber nicht für Anfänger, es > soll ein > Nachschlagewerk sein jedoch kein Anfängerlehrbuch. Ich suche ja ein > Lehrbuch. Was ist vom C Primer Plus zu halten oder von Nitty Gritty C? > wird hier im uC Forum ja auch erwähnt. K&R ist genau das: ein Lehrbuch und didaktisch auch so aufgebaut - es lehrt die Sprachkonstrukte samt Risiken und Nebenwirkungen. Ansonsten ist sicher Wolf: C von A bis Z ganz brauchbar. Als Referenz nehm ich gerne O'Reilly's "C kurz gut", gerade für irgendwelche IEEE749 Sachen oder C99-spezifisches imho ganz ok. Als blutiger Einsteiger hatte ich damals, bitte nicht lachen, mit "C für Linux in 21 Tagen" angefangen - hatte aber gehalten, was es versprochen hatte. :)
Hier http://accu.org/index.php/book_reviews_redirect gibt es gute Buch Rezensionen. Allerdings überwiegend C++, aber auch einige C Bücher. Vielleicht findest Du da etwas zu Deinen C-Büchern.
newbie schrieb: > Ja das K&R wird allseits empfohlen, aber nicht für Anfänger, es soll ein > Nachschlagewerk sein jedoch kein Anfängerlehrbuch. Ich suche ja ein > Lehrbuch. Was ist vom C Primer Plus zu halten oder von Nitty Gritty C? > wird hier im uC Forum ja auch erwähnt. Das würde ich aus eigener Erfahrung nicht bestätigen. K&R war eines der ersten Bücher, die ich damals gelesen habe (da noch in der deutschen Übersetzung), und ich bin damit besser klar gekommen als mit jedem anderen.
.. stimme ich zu, der K&R ist ein didaktisch durchdachtes buch, und halt das C Lehrbuch. Nach dem K&R liest man dann die Quellen Anderer, zum Beispiel den Linux Kernel. Ausgesprochen sauberer Code, stilistisch und inhaltlich prägnant. Nicht erschrecken, es geht nur darum die Tricks und den Style erfahrener Programmierer zu absorbieren und daraus seinen persönlichen Stil zu entwicklen. Um das ganze zu praktizieren, reicht ein Raspberry PI sammt Linux, Zugang via TCP/IP SSH, einen kompententen Editor, zb. emacs oder vi und die auf dem rasp ohnehin vorhanden gcc toolchain. Ist aber nichts für Fingerbehinderte, schreiben und lesen muss man schon. Die Lernkurve ist flach, aber das was bleibt ist von Dauer.
Na dann muss es wohl der K&R sein. Es kommt aber noch die Frage auf warum der Primer zB über 1000 Seiten hat, wohingegen der K&R knapp 300 hat. Wenn der K&R alles beinhaltet um Controller zu programmieren dann ist das für mich ausreichend. Der Seitenunterschied ist halt gewaltig.
..der K&R lehrt C. Da steht nicht drin wie man ein crt0 schreibt um einen Controller aus dem nichts zu holen. Via K&R lernt man C zu programmieren. Dann schaut man wie eigene einfache C Programme von einem Compiler (zb.gcc) in Assembler übersetzt werden. Man lernt dabei die Maschine kennen und studiert deren Architektur. Man bettet eigenen Assembler Code in C ein und lernt Schritt für Schritt die Maschine (CPU) kennen. Hat man die Architektur der Maschine verstanden, dann kann man den ersten initialen Code Schreiben, der ins main() führt. usw..
newbie schrieb: > Es kommt aber noch die Frage auf > warum der Primer zB über 1000 Seiten hat, wohingegen der K&R knapp 300 > hat. :-) In eine Abi-Zeitung stand einmal: „Wer mit zwanzig Worten das sagt, was man auch mit zehn sagen kann, der ist auch zu anderen Missetaten fähig!“ Ob das auf den Primer zutrifft kann ich nicht sagen, ich kann mich nicht erinnern, ihn gelesen zu haben. Sollte ich aber einmal in die Situation kommen, mich ganz schnell zwischen zwei Büchern entscheiden zu müssen und dabei nichts als die Seitenzahl zur Verfügung zu haben, ich würde das dünnere nehmen. Gute Autoren können das Wesentliche mit wenigen Worten beschreiben und nur wenige Themen sind so komplex, dass die vielen Worte gerechtfertigt sind. Hole Dir doch beide Bücher – und gerne noch ein paar mehr – aus der Bibliothek Deines Vertrauens und welches Dir am meisten zusagt, dass stellst Du Dir dann in den eigenen Schrank. So habe ich es immer gehalten und in meinen Schrank haben es bisher nur wenige dicke Bücher geschafft – zu den Ausnahmen gehören der Stroustrup und der C++-Standard – das Meiste was da steht aber ist nicht viel dicker als der K&R.
:
Bearbeitet durch User
A. H. schrieb: > So habe ich es immer gehalten und in meinen Schrank haben es bisher nur > wenige dicke Bücher geschafft Da liegen bei mir nur ein paar Blättchen mit den AVR Asm-Instruktionen. Für >90% typischer Bastle-Apps absolut ausreichend. Aber warum einfach wenns auch kompliziert geht?
Asm und gut ist schrieb: > Da liegen bei mir nur ein paar Blättchen mit den AVR Asm-Instruktionen. > Für >90% typischer Bastle-Apps absolut ausreichend. > Aber warum einfach wenns auch kompliziert geht? Guten Morgen Moby. Willst du deinen Avr-ASM-Semf in einen C++ Thread auch wieder dazu geben?
Asm und gut ist schrieb: > Da liegen bei mir nur ein paar Blättchen mit den AVR Asm-Instruktionen. Bei mir ganz nichts, das C(++) Wissen in Kopf und auf geht's. > Aber warum einfach wenns auch kompliziert geht? Warum sich ASM antun, wenn es auch schöne Hochsparen wie C(++) gibt? ASM nur, wenn ich auf den Taktzyklus genau wissen muss wie lange etwas dauert.
C(++) schrieb: > Warum sich ASM antun, wenn es auch schöne Hochsparen wie C(++) gibt? Nö. So wird ein Schuh draus: Mampf F. schrieb: > Ansonsten tendiert man in C++ eher recht einfache Sachen überkompliziert > zu lösen ... *** newbie schrieb: > der Primer zB über 1000 Seiten Das nenn ich dann C(++) schrieb: > antun
@Asm und gut ist Ich behaupte, jeder gute C Programierer kennt den vollständigen Syntax und jedes Sprachkonstrukt auswendig und muss nicht erst nachlesen. Kennst du die definition jeder ASM-Instruktion deiner Lieblings CPU auswendig, ohne jemals nachsehen zu müssen? Falls ja: Wie lange hat das gedauert?
newbie schrieb: > wohingegen der K&R knapp 300 hat. 300 Seiten für K&R sind nicht mal doppelt so viel wie der 8-bit ARV Instruction Set: http://www.atmel.com/images/doc0856.pdf Nur mit dem feinen Unterschied, dass man C einmal lernt. ASM hingegen, muss man für jeden neue CPU noch mal lernen.
C(++) schrieb: > Asm ... muss man für jeden neue CPU noch mal lernen. Muss man nicht. Denn in aller Regel kann der Bastler ja bei seiner CPU bleiben. Portabilität ist für ihn meist ein eher theoretischer Vorteil. Zumal es mit dieser bei hardwarenaher Programmierung und mit neuen Hardware-Architekturen eh nicht weit her ist.
Moby schrieb: > C(++) schrieb: >> Asm ... muss man für jeden neue CPU noch mal lernen. > > Muss man nicht. Aber nur wenn man in seiner kleinen, engstirnigen Welt bleit. > Portabilität ist für ihn meist ein eher theoretischer Vorteil. > Zumal es mit dieser bei hardwarenaher Programmierung und mit neuen > Hardware-Architekturen eh nicht weit her ist. Wenn der Code gut ist, muss man nur die Abstrahierungsebenen anpassen. Wenn nicht, muss man nur die hardwarespezifischen Dinge nachlerne und ändern und nicht einen kompletten Befehlssatz...
> Denn in aller Regel kann der Bastler ja bei seiner CPU bleiben.
Das entscheidet der Bastler aber selbst. Und auch ob er ein Tool zum
Register allokieren benutzen will.
Mensch (Fisch?) Moby, warum biste nicht im Urlaub geblieben?
C(++) schrieb: > muss man nur > muss man nur Natürlich. Man muss ja nur... Theoretisches Geplänkel. Ich sag Dir mal was man wirklich nur muss: Die paar Asm-Instructions und seinen Controller richtig kennen- das reicht für ewig. Nicht zuletzt, weil Asm alles aus den kleinen Wunderchips herausholt ;-)
Das schöne an Moby's Argumenten ist ja gerade, das man nur das Gegenteil davon nehmen muss um richtig zu liegen ;-)
Moby schrieb: > Ich sag Dir mal was man wirklich nur muss: > Die paar Asm-Instructions und seinen Controller richtig kennen- das > reicht für ewig. Nicht zuletzt, weil Asm alles aus den kleinen > Wunderchips herausholt ;-) Na, hast du dich durch gerungen ohne dein Synonym wieder Unruhe in einem Thread zu stiften von dem du keine Ahnung hast? Im übrigen scheint deine Interpretation von Ewigkeit genauso abwegig wie deine sonstigen Erkenntnisse zu sein. Glaubst du ernsthaft dir verkauft in 20 Jahren noch irgendwer einen AVR zu ähnlichen Preisen wie heute? Auch noch in DIP? Entweder kramen da noch irgendwelche Nostalgiker ihren Müll zu Mondpreisen aus der Schublade oder es wird schwer noch einen 8bit AVR neu zu bekommen. Ich denke zu der Zeit wirst du dann hier predigen, dass der arm-Assembler das einzig wahre ist...
Moby schrieb: > C(++) schrieb: >> muss man nur >> muss man nur > > Natürlich. > Man muss ja nur... > Theoretisches Geplänkel. Wenn man nur ASM programmiert, hat man das in der Praxis natürlich noch nie gesehen.
Noch was zum Thema "Theoretisches Geplänkel": Ich habs extra für die ausprobiert: Meinen One Wire DS18B20 C-Code hab ich in nich mal 1/4 Stunde von PIC24 (16bit CPU) nach PIC18 (8bit CPU) portiert.
Das ist doch kein Problem, da PIC's ja ALLE EXAKT den selben Befehlssatz haben ;-) Moby kann man nicht helfen, denn er kennt nur seine Nußschale und fühlt sich daran als Herscher eines unendlichen Gebiets. (frei nach William S.)
Bastler schrieb: > (frei nach William S.) Sehr frei ... ;) "O Gott, ich könnte in eine Nussschale eingesperrt sein und mich für einen König von unermesslichem Gebiete halten, wenn nur meine bösen Träume nicht wären." Hamlet, 2. Akt, 2. Szene
Bastler schrieb: > Das ist doch kein Problem, da PIC's ja ALLE EXAKT den selben Befehlssatz > haben ;-) Blödsinn² Vergleich mal: Seite 318: http://ww1.microchip.com/downloads/en/DeviceDoc/39632e.pdf Seite 257: http://ww1.microchip.com/downloads/en/DeviceDoc/39995_b.pdf
@C++: Du solltest mal Deinen Ironie-Detektor neu kalibrieren ... Gruß, Stefan
Moby ist schon ein Phänomen. Obwohl ihn C++ offenbar überhaupt nicht interessiert und er keine Lust hat, sich damit auseinanderzusetzen, scheinen ihn Threads zu dem Thema geradezu magisch anzuziehen. Da er keine Ahnung davon hat, kann er aber nicht mitreden, also versucht er den Thread in Richtung des einzigen Themas zu ziehen, das er kennt. Ich weiß ja nicht, was so der Normalfall ist, aber wenn ich am Titel eines Threads erkenne, daß es um ein Thema geht, das mich nicht interessiert, dann öffne ich ihn erst gar nicht.
Stefan schrieb: > @C++: > Du solltest mal Deinen Ironie-Detektor neu kalibrieren ... > > Gruß, Stefan Auch so kann man sich rausreden.
Rolf M. schrieb: > Moby ist schon ein Phänomen. Stimmt. Die Übersichlichkeit der 8-Bitter, kombiniert mit der Einfachheit ihrer Asm-Programmierung ist ein Phänomen. Da langt doch die Kenntnis von ein paar primitiven Asm-Codes und der Innereien eines AVR tatsächlich schon aus, die Mehrzahl der Bastlerprojekte hier ohne großes Studium der OOP-Wissenschaften zu realisieren. Ganz ohne Kenntnis, Abhängigkeit und falscher Anwendung von irgendwelchen dieser hunderttausend normierten Sprachelemente und Libraries. Ganz ohne Kenntnis der Besonderheiten irgendwelcher Compiler. Ganz ohne die Notwendigkeit von ressourcenfressenden Abstraktion-Layern und ähnlicher Hilfskonstruktionen. Einfach, transparent, effektiv, flexibel, sparsam, direkt, die Hardware allumfassend wird mit Asm das zum Ausdruck gebracht was Sache- und allein notwendig ist. Und die Zeit für das Studium tausendseitiger Handbücher und beständiges Nachlernen fließt in die eigentliche Projektentwicklung ;-) Was tut man nun bei dieser unangenehm eindeutigen Sachlage? Richtig. Persönlich werden...
temp schrieb: > Glaubst du ernsthaft dir verkauft > in 20 Jahren noch irgendwer einen AVR zu ähnlichen Preisen wie heute? > Auch noch in DIP? Auch in 20 Jahren sind die 8-Bitter samt AVRs noch aktuell. Glaubst Du ernsthaft es könnte nicht so sein? temp schrieb: > Ich denke zu der Zeit wirst du dann hier predigen, dass der > arm-Assembler das einzig wahre ist... Gewiss nicht! Das würde ja voraussetzen, die komplexe 32-Bit ARM Technik sei für alle Problemstellungen das einzig wahre ...
Sven schrieb: > Welchen Controller + IDE + Compiler könnt ihr mir empfehlen? Du nimmst natürlich einen 32-Bit ARM! Dann hast Du Spielraum genug für ineffizientes Programmieren ;-)
Moby schrieb: > Was tut man nun bei dieser unangenehm eindeutigen Sachlage? > Richtig. Persönlich werden... Ja wenn jemand so penetrant alles mögliche behauptet ohne zu Wissen wovon er überhaupt redet, dann wirds nun mal persönlich. Du forderst es ja auch immer heraus, indem du immer versuchst Threads zu kapern und ins Off-Topic zu treiben. Also was machst du in einem C++ Thread?
Moby schrieb: > Mehrzahl der Bastlerprojekte hier ohne > großes Studium der OOP-Wissenschaften zu realisieren. Kann ich in C auch. > falscher Anwendung von irgendwelchen dieser Ich glaube ASM Mnemonics kann man auch falsch anwenden. > hunderttausend normierten Sprachelemente und Libraries. C hat vllt. 50 Schlüsselwörter und die meisten Bibliotheken verwendet man auf einem µC eh kaum und wenn sie einem nicht gefallen kann man die Funktionen auch selbst implementieren. > Kenntnis der Besonderheiten irgendwelcher Compiler. Ist bei Assemblern das gleich, wenn man aber nie aus seiner kleinen, engstirnigen rauskommt fällt einem das natürlich nicht auf. > ressourcenfressenden Abstraktion-Layern Ressourcenfressenden muss er aber nicht sein, der im oben genannten One Wire C-Code braucht genau 1 ASM Befehl pro IO Zugriff. > Einfach Geht schon, implementier mal eine 32bit Division in ASM. In C dauert das keine 5 Sekunden. > effektiv, flexibel, sparsam In welcher Beziehung? > Hardware allumfassend wird mit Asm das zum Ausdruck gebracht > was Sache- und allein notwendig und unter Umständen zu wenig um effektiv zu Arbeiten > ist > Und die Zeit für das Studium tausendseitiger Handbücher Knapp 300 Seiten K&R... > und beständiges Nachlernen Wenn sich eine Sprache nicht weiterentwickelt wird man immer auf dem Stand von dem Tag als sie erfunden wurde bleiben. Nicht mit der Zeit zu gehen geht in C und ASM gleich einfach.
Achso, wenn du glaubst das Prinzip "sie hassen dich, weil du die Wahrheit sagst" gilt hier, dann liegst du falsch. Viele hier kennen nämlich, im Gegensatz zu dir, beide Seiten der Medaille, also ASM- und C-Programmierung.
TriHexagon schrieb: > Achso, wenn du glaubst das Prinzip "sie hassen dich, weil du die > Wahrheit sagst" gilt hier, dann liegst du falsch. Ach was. Soo schlimm ist es auch wieder nicht. > Viele hier kennen nämlich, im Gegensatz zu dir, beide Seiten der > Medaille, also ASM- und C-Programmierung. Dann bin ich ja beruhigt wenn damit nun erwiesen ist, daß wenigstens Du alle Seiten kennst ;-) > Also was machst du in einem C++ Thread? Feststellen, daß OOP auf einem kleinen Controller nix verloren hat. Entschuldigung, das Salz werde ich in diese Wunde weiter streuen ;-)
Moby schrieb: >> Also was machst du in einem C++ Thread? > > Feststellen, daß OOP auf einem kleinen Controller nix verloren hat. > Entschuldigung, das Salz werde ich in diese Wunde weiter streuen ;-) Du streust hier gar nix nirgendwo rein, du nervst einfach nur.
Moby schrieb: > das Salz werde ich in diese Wunde weiter streuen Was hast du falsch gemacht, dass du wie Sisyphos diesen großen Stein bergauf rollen musst? Und nein, das ist kein Salz in Wunden... Zumindest nicht in meine In deine vielleicht.... Eine Form der Selbstkasteiung?
TriHexagon schrieb: > Ja wenn jemand so penetrant Mein Gott, ich verstehs ja. Da hat sich jemand eine großartige Entwicklungsumgebung aufgebaut, jahrelang mit 1000 Seiten Schmökern gepaukt, womöglich studiert und muss sich nun von einem dahergelaufenen Bastler sagen lassen, daß sich eine große Abzahl an typischen Programmieraufgaben mit ein paar Asm-Wortfetzen erschlagen lassen. Das ist wirklich penetrant... C(++) schrieb: > Wenn sich eine Sprache nicht weiterentwickelt wird man immer auf dem > Stand von dem Tag als sie erfunden wurde bleiben. Ja sicher. Sich nicht weiterentwickeln, das hat was Anrüchiges. Ich bin jedoch der Überzeugung, daß sich viele Problemlösungen nicht durch immerfort verfeinernde= verkomplizierende Hochsprachen, sondern nur durch intelligentere, simpler programmierbarere Hardware vereinfachen lassen. Das läuft mit aktueller 32 Bit Technik leider in die andere Richtung... Also bleibt AVR & ASM weiter der einfachste Zugang.
Moby schrieb: >> Also was machst du in einem C++ Thread? > > Feststellen, daß OOP auf einem kleinen Controller nix verloren hat. > Entschuldigung, das Salz werde ich in diese Wunde weiter streuen ;-) Du solltest lieber Feststellen, dass C++ nicht gleich OOP ist, denn C++ beherrscht mehrere Paradigma unter anderem prozedurale Programmierung. Also genau das was du da mit ASM machst. Außerdem bietet C++ auch OOP Elemente an, die keinen zusätzlichen Overhead im Vergleich zu einer reinen prozeduralen Implementierung bieten. Aber warum versuche ich dir das zu erklären, mit C/C++/OOP willst du dich gar nicht auseinandersetzen, sondern nur drüber reden. Bei dir ist die Welt schwarz und weiß. Arme Seele...
Lieber Moby, "Die Grenzen meiner Sprache sind die Grenzen meiner Welt" (Wittgenstein)
TriHexagon schrieb: > Bei dir ist > die Welt schwarz und weiß. Richtig. Weiß ist die Lösung mit dem geringsten Aufwand... Ich bin ja begeistert davon was C++ alles anbietet... Nur hast Du mit Deinen redlich bemühten Ausführungen meinen eigentlichen Kritikpunkt immer noch nicht begriffen: Genau das ist zuviel! Genau das ist unnötig kompliziert! Und füllt deshalb auch tausend Bücher! Die arme Seele ist doch eher der, der das für die gegebenen Problemstellungen unnütz pauken musste...
Moby schrieb: > Richtig. Weiß ist die Lösung mit dem geringsten Aufwand... Dann ist Weiß: Arduino erwerben IDE auf den PC drauf, bisschen C++ rein hacken, aufspielen und fertig. Mit weniger Aufwand gehts kaum. Oder einen Raspberry.... Der bringt schon alles mit, bzw. ist der Kram leicht nachzuinstallieren. Und ja, um alle Vorzüge des C++ auskosten zu können ist der 32Bitter kein schlechte Wahl. Mit irgend einem OS drauf.
Moby schrieb: > Nur hast Du mit Deinen redlich bemühten Ausführungen meinen eigentlichen > Kritikpunkt immer noch nicht begriffen: Genau das ist zuviel! Genau das > ist unnötig kompliziert! Und füllt deshalb auch tausend Bücher! Nein du kappierst es nicht. Woher willst du denn eigentlich wissen, was das für ein Aufwand ist? Du hast doch keinen blassen Schimmer von C++. Du schaust dir Code an, sagst das ist viel zu kompliziert, ohne zu verstehen was er überhaupt macht, dann siehst du Bücher mit mehreren hundert Seiten und schließt daraus: das ist viel zu kompliziert, das lohnt sich nicht. Tut mir leid, dass ist an Oberflächlichkeit nicht zu überbieten. Machst du das im Leben immer so? Fremdsprachen erscheinen zunächst auch immer als extrem kompliziert. Bis man mal anfängt diese zu lernen. Plötzlich erkennt man Gesetzmäßigkeiten und die Sprache wird immer intuitiver, bis man sie flüssig und ohne aktiv nachzudenken sprechen kann. Erst dann kann man erkennen, dass die eigene Muttersprache Deutsch an vielen Stellen komplizierter und umständlicher ist, als z.B. Englisch. Aber keine Angst, eine Programmiersprache zu lernen ist nicht so aufwändig wie eine Fremdsprache. Und wenn man erst einmal eine imperative Hochsprache gelernt hat, ist es zum Teil gar kein Aufwand mehr eine neue zu lernen.
Wahrscheinlich ist eigentlich bei dieser Diskussion jedes Wort zuviel. Denn diese immer wieder aufbrandende Diskussion, riecht sehr streng nach absichtlicher Provokation. Direkt nach dem Studium 1999 hab ich auch noch, in Assembler auf 8Bit Mikrocontroller meine ersten Projekte verwirklicht. Hätte ich das aber so beibehalten, hätte ich wohl in der damaligen Firma nicht lange überlebt. Die Produktzyklen werden immer kürzer. Man kann lange theoretische Diskussionen führen. Fakt ist, die praktische Erfahrung zeigt, dass Projekte in Hochsprachen um ein Vielfaches schneller zu erstellen sind. Ausserdem ist Assembler im Bereich der sicherheitsrelevanten Software keine akzeptierte Sprache. Aktuell je nach Anforderung haben wir 3 unterschiedliche Mikrocontrollerfamilien von mehreren Herstellern im Einsatz. Es kommt nur auf die geforderte Funktion und geringe Kosten an. Wobei die Kosten bei gleicher gebotener Funktionalität dann abschliessend entscheiden. Wichtig für uns ist also die Portierbarkeit auf andere Hardware. Damit fällt Assembler aus, sonst ist diese Möglichkeit nicht gegeben. Assembler sind immer, hardwareabhängig. Es gibt nur einen Punkt bei dem Assembler interressant wird. Der Geschwindigkeitsoptimierung einzelner Routinen in Form von Inline Assembler Anweisungen. Wobei das auch immer unterinteressanter wird. Warum? Ganz einfach! Wenn ich eine Rolle ARM Cortex M3 für 1$ das Stück bekomme, dann werde ich kaum einen vergleichbaren proprietären 8Bitter zum vierfachen Preis einsetzen. Ob dabei der 32Bitter überdimensioniert ist, ist total uninteressant. Sein Gehäuse muss ja nicht grösser sein. Bei dem Ganzen denkt aber nicht an Trivial-Beispiele! Geht lieber von Projekten in der Grössenordnung eines CANopen-Stacks aus. Dann reden wir schon eher, von einer realen Projektgrössenordnung. Ddie Komplexität der embedded Softwäre ist im laufe der Zeit kontinuierlich am Steigen. Dennnoch sehe ich die 8Bitter auch nicht verschwinden. In einigen Bereichen werden sie sich sicher halten. Dabei denke ich an Mikrocontroller mit 3 oder 4 Pins z.B. So kleine Projekte kommen in meiner beruflichen Praxis aber nur in Ausnahmefälle vor. Inwieweit das oben Geschriebene für Andere auch gilt, muss jeder selbst entscheiden. Irgendwann sollte man fruchtlose Diskussionnen einfach mal sein lassen. Es ist nunmal so, das in jedem Projekt je nach Anforderung die Werkezeuge neu ausgewählt werden. Wenn das 8Bit Mikrocontroller und Assembler bedeutet, ok warum nicht. Daraus aber eine allgemeingültige Regel machen zu wollen, ist einfach nur fachlicher Blödsinn. Sorry, aber das musste ich jetzt so deutlich schreiben.
Moby schrieb: > Mein Gott, ich verstehs ja. Da hat sich jemand eine großartige > Entwicklungsumgebung aufgebaut, jahrelang mit 1000 Seiten Schmökern > gepaukt, womöglich studiert und muss sich nun von einem dahergelaufenen > Bastler sagen lassen, daß sich eine große Abzahl an typischen > Programmieraufgaben mit ein paar Asm-Wortfetzen erschlagen lassen. Hm, der durchschnittliche deutsche Muttersprachler verfügt über einen Wortschatz von etwa 7000 Worten. Eine Goethe brachte es auf etwa 21000. Mir kam gerade unweigerlich das Bild eines dahergelaufenen Bastlers in den Sinn, der einem Herrn Goethe zu erklären versucht, man könne doch auch mit ein paar Wortfetzen durchs Leben kommen. Was zweifellos stimmt! Denn schließlich hatte auch ein Goethe gezweifelt. (Stand er doch letztlich da, der arme Thor, und fühlte sich so klug als wie zuvor.) Aber hätte ihn das Argument wirklich überzeugt? Oder wäre ihm, der ja auch als etwas überheblich und humorlos galt, nicht eher der schöne Spruch in den Sinn gekommen von der guten alten Eiche, die es kaum stört, wenn sich die Sau ihr scheuert? Und prompt formte sich das nächste Bild vor meinem geistigen Auge, diesmal das einer Sau, die sich neben der Eiche aufbaut und lautstark insistiert, es habe die Eiche gefälligst zu stören. Ich bitte allseits um Entschuldigung, eigentlich hatte ich mir fest vorgenommen, zum weiteren Verlauf dieses Threads zu schweigen, aber bei diesem Bild konnte ich einfach nicht mehr widerstehen. Lieber Moby, es liegt mir fern Dich beleidigen oder bloß stellen zu wollen. Es geht mir einfach darum einmal Feedback zu geben, wie solche Äußerungen auf mich wirken. Kann sein, dass das anmaßend meinerseits ist, kann sein, dass eigentlich ich die Sau bin und Du die Eiche, und dass die Assoziationen, die sich unwillkürlich bei mir bilden nur auf meine eigene geistige Beschränktheit zurück zu führen sind. Zumindest scheine ich damit aber nicht alleine zu sein. Du hast jedes Recht, meine Meinung zu ignorieren und Du hast selbstverständlich jedes Recht, Deine Meinung hier kund zu tun. Ich teile sie nicht, aber ich werde sie respektieren. Aber der Welt erklären zu wollen, was richtig und was falsch ist ist mindestens ein sehr gewagtes Unterfangen und kann schnell ins Lächerliche abgleiten. Ich fürchte sagen zu müssen, das nach meinem Eindruck dieser Punkt bereits überschritten ist. Nun verzeihe man mir die vielen Worte, ein paar Fetzen hätten vielleicht auch genügt, aber das wäre möglicherweise unhöflich gewesen.
:
Bearbeitet durch User
Könnt Ihr die Frage "Assembler vs. Hochsprachen" bitte privat klären? Das Ganze wurde nun schon x-mal durchgekaut und hat genug Threads kaputtgemacht - es ist mir auch unverständlich, warum immer noch Leute darauf eingehen. Weitere Beiträge dazu werde ich ab hier löschen. Nochmal zur Erinnerung - die Frage war: Welchen Controller für C++ Programmierung? Danke.
:
Bearbeitet durch Moderator
Dann mach lieber gleich den Thread zu... der 2. Post war bereits die Antwort! Vielleicht noch eine Anmerkung: Sobalds einen Compiler gibt, gibts keinen Grund ihn nicht zu verwenden. 73
Hast eigentlich Recht. Ich mache hier mal zu. Wenn noch irgendjemand Erhellendes zum eigentlichen Threadthema beizutragen hat, kann er sich ja melden.
Thread beobachten
Seitenaufteilung abschalten