Moin Ich habe anfangs mit Bascom gearbeitet und stoße an die grenzen von Basic. Nun möchte ich mich weiterentwickeln und steh zwischen den zwei oben genannten Programmiersprachen. Welche Sprache lohnt es sich zu lernen? Im hinblick das ich in ca. 7 Monaten mein Elektrot. Studium beginne. Schwierigkeit spielt keine Rolle. Ich will nur keine Sprache lernen die ich irgendwann wieder vergessen kann.
Ich kenne leider beide Sprachen noch nicht. Ich habe nur zwei Scripte, mit der selben Aufgabe, verglichen
Es gibt hier etliches Schimpfen über Arduino // AVR-gcc. avr-gcc kann alles, Du solltest aber die 500seitigen englischen Datenblätter von Atmel lesen (wollen). Arduino ist dasselbe, nur mächtig eingeschränkt. Da gibt es nur eine Quarz-Frequenz und eine handvoll CPU. Dafür sind Beispiele, die aber auch gleich funktionieren, wenn ... Ein Beispiel gleichzeitig funktioniert, aber da die Hardware die gleichen Timer für mehrere Aufgaben nutzt, kommen sich mehrere Beispiele häufig in die Quere. Und es gibt keine Doku, um das vorherzubestimmen. (außer reverse engineering). Die Port-Befehle sind etwas komisch, dafür brauchen sie auch 10µs pro Bit, aber man muß sie ja nicht benutzen. Für eine Bastel-Arbeit ist Arduino gut, aber was industrielles kann man damit nicht machen. Ich verwende übrigens die Arduino-Hardware und programmiere direkt über Linux-Befehlszeile und usbasp ohne bootloader. Das ganze Maus-geklicke nervt etwas und ich brauche 2 Hände für die Tasten; die dritte Hand steht an meinem Lötplatz ;-) und nicht an der Maus.
Patrick Schneidewind schrieb: > Ich kenne leider beide Sprachen noch nicht. es ist die gleiche Sprache!
Mir gefällt die Arduino Hardware auch zum entwickeln von Ideen, mögen manche nicht verstehen aber Menschen sind so. ( Siehe Apple;) ) Also wäre das sinnvollste für den Einstig ein Arduino UNO mit AVR Studio zu betreiben und sich ins C++ zu quälen?! C++ bekam ja mächtig Kritik, wie man liest.
abc.def schrieb: > Arduino ist dasselbe, nur mächtig eingeschränkt. Umgekehrt. Arduino stellt einen Haufen Bibliotheken zur Verfügung, die gewisse Mindestanforderungen an die Hardware stellen. Und natürlich läßt sich unter Arduino auch ganz normal in C++ programmieren. Da ist nichts eingeschränkt oder verboten.
Wenn du C++ nicht magst, kannst du auch mit C anfangen. Das Problem mit C++ auf solch kleinen Controllern ist, dass du wissen musst, welche Features du verwenden darfst und welche nicht. Insofern: Fang erstmal mit C an.
Patrick Schneidewind schrieb: > C++ bekam ja mächtig Kritik, wie man liest. Ja, von Leuten die es nicht verstehen. C++ ist wunderbar für Mikrocontroller geeignet, und es gibt kaum einen Grund noch C zu verwenden. Im ET-Studium wird nur vermutlich doch C gelehrt, dann musst du aufpassen was du da nicht verwenden kannst. Das ist allerdings einfahcer als erst C, dann C++ zu lernen (weil du dann die ganzen schlechten C-Angewohnheiten wieder un-lernen müsstest). Svenska schrieb: > Das Problem mit C++ auf solch kleinen Controllern ist, dass du wissen > musst, welche Features du verwenden darfst und welche nicht. Bei C aber genauso. Siehe malloc, fopen, system, ...
Ihr habt mich von c++ überzeugt. Danke für die Hilfe :) Jetzt wäre noch eine Frage übrig, was wäre aus eurer sich gut fürs Lernen geeignet. Bücher, Webseiten, Videos,...
hei, betreffend Studium kann ich dir ev. weiterhelfen. Ich schliesse gleich mein 1. Semester an der Fachhochschule ab, und wir haben bis jetzt einen halben Tag pro Woche mit C verbracht. Im nächsten Semester sollen Projektarbeiten kommen, damit wir in Gruppen programmieren können. Im 3. Semester soll "Hardware-Nahes Programmieren" kommen, doch leider haber ich hier dinge in erfahrung gebracht, die absolut nichts mit Hardarenahe zutun haben: Man kriegt ein 32Bit Arm-Prozessor von Toradex und soll hier dann die UART mit Assemble codieren...?? Für mich komplett sinfrei, aber ja. im 4. Semester kommt Objektorientiertes Programmieren in C++ und Java. Ich gebe dir einen guten Rat: Lerne zuerst C auf einem 8-Bit Controller, dann hast du sehr viele Probleme schon mal nicht. C++ mit allen Variationen (dynamischer Speicher, Listen, Vektoren, Bäume, dynamische Klassen...) macht in nur auf einem 32Bit mit genügend RAM sinn. Alles andere ist Ressourcenverschwendung (Zeit und Speicher).
Patrick B. schrieb: > C++ mit allen > Variationen (dynamischer Speicher, Listen, Vektoren, Bäume, dynamische > Klassen...) macht in nur auf einem 32Bit mit genügend RAM sinn. Alles > andere ist Ressourcenverschwendung (Zeit und Speicher). Was hat das mit der Sprache C++ zu tun ? Das können andere Sprachen wie C auch. Und was sind dynamische Klassen in C++ ?
:
Bearbeitet durch User
C++ ist viel mächtiger als C, und somit kann man bei C++ grössere und umfangreichere Projekte machen, aber auf einem kleinen 8-Bitter ist genau das der Nachteil aus meiner Sicht. Dynamische Klasse (keine Ahnung, ob man dem wirklich so sagt) ist die Instanzierung einer Klasse in einer einzigen Funktion. Wenn dies global geschieht ist der Speicher sowieso schon belegt, aber wenn man das in einer Funktion machen möchte, muss man auch sicherstellen, dass genügend RAM vorhanen ist (alle Member) auch wirklich geladen werden können. Hatte einmal grosse Probleme damit bei einem Projekt (auf einem Cortex-M4). Hier wurde mir nach gewisser Zeit der Heap komplett fragmentiert, was übel war. Ich habe mich dann auf das statische Programmieren beschränkt, und dazu braucht man kein C++. Also, lieber mit C anfangen. Für Bildbearbeitung, GUIs, Speicherverwaltung und alles weitere kann man dann auf C++ wechseln. Ausserdem werden bei sauberen Klassen eine Menge Ressourcen bei kleinen Projekten verschwendet, da alle Members über Get- und Set-Funktionen angesprochen werden sollten (somit können die Daten auch gleich überprüft werden). Aber auf einem uC weiss ich normalerweise, wie die Daten vorliegen, also unnötig.
Patrick B. schrieb: > C++ ist viel mächtiger als C, und somit kann man bei C++ grössere > und > umfangreichere Projekte machen, aber auf einem kleinen 8-Bitter ist > genau das der Nachteil aus meiner Sicht. Keineswegs. Die Features von C++ helfen auch bei kleinen Projekte, und bei der Skalierbarkeit. Und wie viele ja beteuern, kann man eben auch auf 8-Bittern große Projekte umsetzen; man muss schon einige Zeilen Code schreiben, um einen ATmega2560 vollzukriegen?! > Dynamische Klasse (keine Ahnung, ob man dem wirklich so sagt) ist die > Instanzierung einer Klasse in einer einzigen Funktion. Meinst du so?
1 | void someFunction () { |
2 | MyClass myInstance; |
3 | }
|
Das hat mit der Klasse gar nichts zu tun, und die Allokation geschieht auf dem Stack. > Wenn dies global > geschieht ist der Speicher sowieso schon belegt, aber wenn man das in > einer Funktion machen möchte, muss man auch sicherstellen, dass genügend > RAM vorhanen ist (alle Member) auch wirklich geladen werden können. Genau wie wenn man es in C machen würde, mit structs oder einzelnen Variablen. Bloß dass man in C++ noch Konstruktoren und RAII gratis dazubekommt. > Hatte einmal grosse Probleme damit bei einem Projekt (auf einem > Cortex-M4). Hier wurde mir nach gewisser Zeit der Heap komplett > fragmentiert, was übel war. Obige Instanz wird überhaupt nicht auf dem Heap allokiert. Wer sagt, dass man unbedingt den Heap verwenden muss? Man kann auch C++ Klassen wunderbar auf dem Stack oder global statisch (in .data) allokieren; wir reden hier schließlich nicht von Java. > Ich habe mich dann auf das statische > Programmieren beschränkt, und dazu braucht man kein C++. Aber auch kein C. Maschinencode reicht völlig aus. > Also, lieber > mit C anfangen. Warum? Warum nicht gleich lernen wie es richtig geht, anstatt erst mit was gammeligen Anfangen, sich mit ekligen Makros & Co rumplagen um dann das erst später wieder mühselig alles vergessen zu müssen? > Ausserdem werden bei sauberen Klassen eine Menge Ressourcen bei kleinen > Projekten verschwendet, da alle Members über Get- und Set-Funktionen > angesprochen werden sollten (somit können die Daten auch gleich > überprüft werden). Das verschwendet keinerlei Ressourcen, denn die Getter/Setter macht man natürlich als "inline" Funktionen, falls der Compiler das nicht onehin schon automatisch macht. > Aber auf einem uC weiss ich normalerweise, wie die > Daten vorliegen, also unnötig. Ja, wenn man niemals Kapselung betreibt und Code wieder verwenden will...
Patrick B. schrieb: > Im 3. Semester soll "Hardware-Nahes Programmieren" kommen, doch leider > haber ich hier dinge in erfahrung gebracht, die absolut nichts mit > Hardarenahe zutun haben Ich weiß ja nicht was du für eine Vorstellung von Hardwarenähe hast, aber sehr viel näher als mit Assembler kommst du nicht mehr, es sei denn du gibts die Prozessorbefehle direkt ein. Patrick B. schrieb: > und soll hier dann die UART mit Assemble codieren...?? Für mich komplett > sinfrei, aber ja. Na, dann erklär doch mal warum das sinnfrei sein sollte...
Natürlich wird man wohl erstmal so über die Hälfte der STL knicken können. Wenn man mit templates arbeiten möchte, muss man aufpassen, dass man keine Typenexplosion erzeugt, wo sie nicht nötig ist (halteben code-explosion). Aber C++ ist auch in der halb-prozeduralen Programmierung so viel schöner als C, dass ich nicht nachvollziehen kann, warum man sich mit irgendwelchen C-Limitationen rumschlagen sollte. Ihr müsst auch bedenken, dass viele, die C++ gegenüber Java oder anderem vorziehen eben um die Implikationen der benutzten Konstrukte wissen und an C++ schätzen, dass man Klotzen kann, wo es keine Probleme macht und dennoch feinfühlig sein kann, wo es um die Wurst geht. Da hätte wahrscheinlich jemand, der aus der Java-Ecke kommt, größere Probleme... Btw: Die ersten 25% des C++-Artikels für Mikrocontroller auf dieser Seite (Die Fußangeln) sollten imho ersatzlos gestrichen gewerden, da irgendwie nicht mehr aktuell. Der Rest klingt eigentlich sinnvoll.
Ich habe kein Problem damit C++ zu lernen, wenn es sich lohnt. Aber ich habe bis jetzt kaum Literatur gefunden die sich mit AVR und C++ befasst. Mit C tonnen weise. Und wenn ich im Studium C brauche, muss ich wohl in den sauren Apfel beißen und beides lernen. Wie hart ist der Sprung von C zu C++ oder von C++ zu C oder ist es wurscht, dann lerne ich erst C.
Patrick Sch. schrieb: > Wie hart ist der Sprung von C zu C++ oder von C++ zu C oder ist es > wurscht, dann lerne ich erst C. Von C++ zu C ist recht leicht, du musst nur wissen welche Sachen in C eben nicht gehen. Von C zu C++ ist schwierig, weil du erst alle schlechten C-Angewohnheiten wieder un-lernen musst(solltest) um zu lernen wie es in C++ richtig geht. Patrick Sch. schrieb: > Aber ich habe bis jetzt kaum Literatur gefunden die sich mit AVR und C++ > befasst. Mit C tonnen weise. Der Teil der Literatur, der sich einfach nur mit dem Hardwarezugriff beschäftigt, ist für C++ onehin identisch, Register-Zugriffe, ISR's und so funktionieren da eh genau gleich. Und wenn es um die Strukturierung der Programme geht kannst du dann ja deine richtigen C++ Kenntnisse anwenden.
Dr. Sommer schrieb: > Warum? Warum nicht gleich lernen wie es richtig geht, anstatt erst mit > was gammeligen Anfangen, sich mit ekligen Makros & Co rumplagen um dann > das erst später wieder mühselig alles vergessen zu müssen? Wieso wird dann auf kleinen uC in C oder sogar in Assembler programmiert? Laut deiner Schilderung gibts ja keinen Grund dafür... Interessanterweise habe ich bis jetzt bei jeder Schulung für Programmierung eines uC Assembler und C gehabt. Der einzige Ort wo ich C++ eingesetzt habe ist in einem Projekt für eine Kommunikationsklasse die gleichzeitig auf uC und FPGA im selben Unternehmen eingesetzt wurde. Somit mussten nur wenige Dateien aktualisiert werden, da der Rest über Subversion automatisch in die anderen Projekte einbezogen und aktualisiert wurde. Achja, und für AVR, PIC, MSP und Renesas habe ich bis jetzt nur C gesehen, welches auch anständig unterstütz wurde. Ab Stufe Cortex-M3 wird C++ erst richtig unterstützt. Selbst die grossen Libs von ST für ihre ARMs sind in C geschrieben, können aber ohne weiters in ein C++ Projekt integriert werden (da alle Header über extern C verfügen). > Das verschwendet keinerlei Ressourcen, denn die Getter/Setter macht man > natürlich als "inline" Funktionen, falls der Compiler das nicht onehin > schon automatisch macht. Ja klar, sollange es solche Getter und Setter sind:
1 | void Set_Member(int value){ |
2 | Member1 = value; |
3 | }
|
4 | int Get_Member(void){ |
5 | return Member1; |
6 | }
|
Aber in rund der Hälfte der Fälle möchte man ja auch die Werte prüfen:
1 | int Set_Member(int value){ |
2 | if((value < 3) && (value > 10)){ |
3 | Member1 = value; |
4 | return 1; |
5 | }
|
6 | else{ |
7 | return 0; |
8 | }
|
9 | }
|
Und hier kann man noch so viel inlinen, da wird automatisch mehr Rechenleistung gebraucht. Wenn die Klasse auf dem uC nur einmal vorhanden ist, brauchts auch keine Klasse und dann fallen diese Überprüfungen meistens auch gleich weg. Kaj schrieb: > Ich weiß ja nicht was du für eine Vorstellung von Hardwarenähe hast, > aber sehr viel näher als mit Assembler kommst du nicht mehr, es sei denn > du gibts die Prozessorbefehle direkt ein. Hardwarenahe ist für mich, dass man noch mit dem Datenblatt arbeitet, und verstehen muss, was wie gemacht wird (Interrupts, atomar, wie halt 32-Bit Variablen auf einem 8-Bitter umgesetzt werden, wie eine Float-Zahl auf 8-Bit behandelt wird, Casts...). Zum Vergleich mein Werdegang auf dem Gebiet Programmieren: - ~1 Monat C auf dem PC in kombination mit dem Dos - 2 Jahre AVR und PICs mit C - 6 Monate C++ auf PC - 1 Jahr PHP und JavaScript auf Linux-Server - 2 Jahre C auf ARM Controllern - 3 Monate C++ auf ARM/FPGA Und so sieht der Ablauf bei meiner FH aus: - 6 Monate C auf PC - 6 Monate C als Projekt (Spiele programmieren) - 6 Monate C 32-Bit Controller mit allem Schickimicki und Grafikdisplay - 6 Monate Java - Als Freifächer Embeded programming (aber keine Ahnung welche Sprache) Was nützt einem eine Assembler Routine für einen Controller um die UART zu betreiben (ohne Interrupts und ohne DMA), wenn nebenan ein DMA vorhanden ist (ok, man muss noch wissen, wie die Daten daherkommen und wie man mit dem DMA umgehen muss) Patrick Sch. schrieb: > Aber ich habe bis jetzt kaum Literatur gefunden die sich mit AVR und C++ > befasst. Mit C tonnen weise. > Und wenn ich im Studium C brauche, muss ich wohl in den sauren Apfel > beißen und beides lernen. Was für mich ein weiterer Grund für C ist. Mache dich ersteinmal mit den kleinen uCs vertraut (meistens C), dann kannst du auf die grösseren wechseln, die dann auch DMAs und FPUs und vieles weitere noch haben. Was du in deinem Studium brauchen wirst, kann ich dir nicht sagen. Bei uns ists auf jeden Fall so. Scheinbar ist das Thema C++ auf MCU genau gleich ein Glaubenskrieg wie AVR vs PIC. Aber hei, wieso nicht bei den Basics anfangen, und dann später Freude haben, wenn etwas mit C++ einfacher geht, dafür hat man aber begriffen was man macht. Ich habe auch nicht in der ersten Klasse mit dem First angefangen oder Integralrechnen betrieben...
Patrick B. schrieb: > Wieso wird dann auf kleinen uC in C oder sogar in Assembler > programmiert? Laut deiner Schilderung gibts ja keinen Grund dafür... Wenn es keinen C++ Compiler gibt oder derjenige ein Problem mit Klammern hat... > Interessanterweise habe ich bis jetzt bei jeder Schulung für > Programmierung eines uC Assembler und C gehabt. Das ist halt ein selbst verstärkender Effekt; die Lehrenden können/kennen nur C, und bieten daher auch nur C an. An "meiner" Hochschule gibts aber sogar Embedded C++ Kurse. > Achja, und für AVR, PIC, MSP und Renesas habe ich bis jetzt nur C > gesehen, welches auch anständig unterstütz wurde. Ach, der GCC für AVR kann kein richtiges C++? Dabei sind Clang und GCC doch eigentlich die besten im Bezug auf "vollen" C++ Support... > Ab Stufe Cortex-M3 > wird C++ erst richtig unterstützt. Selbst die grossen Libs von ST für > ihre ARMs sind in C geschrieben Aus der Qualität der ST Libraries kann man auf die Kompetenz der Entwickler schließen, welche wiederum die Verwendung von C erklärt. Und natürlich wollen die die C-Fans (von denen es im Embedded Bereich zu viele gibt) nicht vergraulen > können aber ohne weiters in ein C++ > Projekt integriert werden (da alle Header über extern C verfügen). Wenigstens etwas. Patrick B. schrieb: > Und hier kann man noch so viel inlinen, da wird automatisch mehr > Rechenleistung gebraucht. Wenn die Klasse auf dem uC nur einmal > vorhanden ist, brauchts auch keine Klasse und dann fallen diese > Überprüfungen meistens auch gleich weg. Das macht wieder überhaupt keinen Sinn?! Was hat die Überprüfung mit C++ und Klassen zu tun? Wenn ich die Überprüfung mache, zählt sie sowohl in C als auch in C++ zur Rechenleistung. Wenn ich keine Überprüfung mache, braucht keine der Sprachen dafür Rechenleistung. Außerdem macht man solche Überprüfungen typischerweise mit assert(), s.d. sie nur im Debug-Modus auftreten. Oder wenn es sein muss mit einem template. Die Folgerung "Verwende C++" => "Muss zwangsweise überall Überprüfungen machen" ist jedenfalls verkehrt. In C++ könnte man sogar, wenn man es drauf anlegt, derartige Überprüfungen zur Compile-Zeit machen (s.d. sie gar keine Resourcen zur Laufzeit brauchen), falls dem Compiler die Werte bekannt sind; das geht in C gar nicht.
Ich kann mir irgendwie nicht vorstellen, dass es einem hilft, Jahresweise die Programmiersprachen zu rotieren, zwischen Web/Embedded/Desktop um auch nur auf irgendeiner dieser Plattfrom/Sprach-Kombinationen einen reifen Programmierstil zu entwickeln.
decimad schrieb: > Ich kann mir irgendwie nicht vorstellen Das hilft sehr gut, einen Überblick über verschiedene Betrachtungsweisen zu gewinnen und ein allgemeines Verständnis zu erlangen; viel besser als immer nur eine Technologie innerhalb des eigenen Tellerrands zu verwenden.
Also was ich meinte war folgendes: Wenn ich jemanden vor mir habe, der mir sagt er könne "X, Y, Z, A, B, C, hat 3 Wochen dies, 2 Wochen das, 17 Wochen und blablabla", dann kann ich nur denken, dass er entweder ein Genie ist, oder aber nie etwas produktreifes erledigt hat. Ich kann vor allem also nicht beurteilen, ob er Durchhaltevermögen besitzt. Und offenbar besitzt er auch an keiner Sache ein gesteigertes Interesse. Aber ich seh das vielleicht etwas schwarz/weiß, geb' ich schon zu. Und weiterbringen tut uns diese Diskussion hier wahrscheinlich auch nicht. War nur ein Kommentar aus der Hüfte geschossen.
Interessante Bemerkung... 1) Ich programmiere jetzt seit rund 8 Jahren Mikrocontrollern (das meiste davon in C) und ja, da waren mehrere Projekte die zur Serie gebracht wurden. 2) Als ich anfing, konnte der Lehrer nicht wirklich erklähren, wie man programmiert. Dies lernte ich erst, als ich von meinem Verein für die Homepage-Verwaltung "angagiert" wurde. Daraus kam ein komplettes angepasstes CMS. Und hier habe ich die Bedeutung von Datenbanken erst richtig verstanden (sehr nützlich für C++). Ausserdem habe ich plötzlich auch begriffen, wie ich gewisse Dinge in C angehen muss. 3) Wenn man etwas grösseres macht (nicht nur Hobby-Mässig), dann wird man unweigerlich auf mehrere Sprachen und Platformen stossen, und krass gesagt wenn du das beruflich nicht kannst (über den Tellerrad blicken) dan finden die einen anderen. Als ich in der Entwicklung tätig war (zugegeben, nur etwa 3 Jahre), war für uns C=Mikrocontroller (8Bit), C++ = FGPA/ARM/PC, Java = PC (Linux, Windows). 4) Ich bin noch relativ jung (25 jährig) und habe mich zwischen Lehre, Berufsmatura, Militärdienst (Schweiz), Studium immer wieder für ~1/2 Jahr bei Firmen gemeldet, die mich dann temporär eingestellt haben. Das hatte 2 Folgen: Ich konnte in diversen Firmen arbeiten und wurde somit jeweils mit anderen, neuen Prozessstrukuren konfrontiert. Hier wurde nur PIC verwendet, da waren es nur ARMs, hier gabs keine Windows-PCs... 5) Ich habe bei meiner Liste oben "nur" die Lehrzeiten, nicht aber die effektiven Arbeitszeiten aufgeschrieben und ausserdem habe ich von mehreren Monaten gesprochen, nicht von Tagen/Wochen. Aber ja, das wird langsam OT
Will nur noch kurz meine Meinung zur C/C++-Diskussion abgeben: Anm.: Die Meinung ist aus ca 18 Jahren Erfahrung in der Softwareentwicklung entstanden [inkl. abgeschlossenem Studium], von denen die letzten 10 Jahre primär C/C++ waren wobei - mit Unterbrechungen - auch etwa 10 Jahre uC-Technik dabei ist. Und auf dem Desktop bin ich ausgesprochener C++-Fan... - lernen: ich halte es wohl für sinnvoll, mit C anzufangen und dann erst C++ zu machen. Gründe gibts dafür mMn mehrere, nicht zuletzt der übersichtlichere Sprachumfang und ein gewisses Verständnis für Lowlevel-Geschichten, die zwar unter C++ verpönt sein mögen, aber dennoch sinnvoll sein können, wenn sie richtig eingesetzt werden - beispielsweise die oben so "beschimpften" Präprozessormakros. Nicht zuletzt hat der neue C++11-Standard die Sprache mMn so "schmutzig" gemacht (auto variablen usw.), dass ICH es einem Anfänger nicht empfehlen könnte, direkt C++ zu lernen - und verhindern, dass er C++11 auf seinem "Weg" will ich garnicht erst versuchen (schon schwer genug Anfängern zu erklären was der Unterschied zw. C++ und C++.net ist) - wenn man C++ verwendet, halte ich es für sinnvoll, zumindest auch zum großen Teil Objektorientiert, mit Referenzen und ähnlichen Neuerungen zu programmieren und nicht nur alle "malloc" durch "new" und alle "free" durch "delete" zu ersetzen (ob man Templates verwenden will ist nochmal eine eigene Diskussion). Dadurch handelt man sich jedoch üblicherweise einiges an nicht sichtbaren Speicher- und Ressourcenfressern ein. Vor allem haben Klassen einen auf kleinen 8-bittern doch spürbaren Overhead (als prominentes Beispiel seien v-tables genannt). Aber auch andere "Best practices" für C++ haben Nachteile bei Geschwindigkeit und Ressourcen, beispielsweise die (häufig zumindest abschaltbaren) Overflow-Protections genannt. Es ist zwar durchaus möglich, dass C++ ähnlich (speziell im Hinblick auf uCs) guten Code erzeugt wie C, darauf wetten würde ich aber nicht. Somit macht es für mich durchaus Sinn, für 8-bit Controller C zu verwenden, denn er hat häufig geringe Ressourcen (Flash und RAM) und muss nicht unbedingt immer mit einem 16Mhz-Quarz laufen um kleinere Aufgaben flott durchzuführen. Wenn man natürlich weiß was man tut, kann man auch mit C++ arbeiten, aber ich persönlich finde es einfacher nicht so viel über Performance und Ressourcen Nachdenken zu müssen und nutze deshalb auf uCs lieber C. Btw: Auch verschiedene Benchmarks - die natürlich auch nicht repräsentativ oder vollständig sind - zeigen, dass C und C++ keineswegs gleich sind und C++ bei komplexen Datenverarbeitungstasks Vorteile hat, sonst aber C meist schneller/sparsamer ist. Besagte komplexe Datenverarbeitung spielt aber für 8bit meist eher eine untergeordnete Rolle. Was Arduino vs "Plain-C(++)" angeht, ists meiner Erfahrung nach ähnlich wie mit C vs. C++: Arduino macht vieles einfacher und weniger Fehleranfällig, aber auch langsamer und "fetter". Ebenso sind Lowlevel-Kenntnisse kaum/nicht erforderlich, was für spätere Aufgaben mMn zum großen Nachteil werden kann. Und so besonders komplex/kompliziert find ich die Datenblätter gerade bei Atmel btw. nicht. Grüße Florian
Florian S. schrieb: > aber > dennoch sinnvoll sein können, wenn sie richtig eingesetzt werden - > beispielsweise die oben so "beschimpften" Präprozessormakros. Was hat eine dumme Textersetzung aka Makro mit Low-Level zu tun? In C++ hat man mit templates ein besseres, mindestens genauso effizientes aber sichereres Werkzeug. Florian S. schrieb: > Nicht > zuletzt hat der neue C++11-Standard die Sprache mMn so "schmutzig" > gemacht (auto variablen usw.), Nur weil eine Sprache viel kann ist sie nicht schmutzig. Gerade die Neuerungen mit "constexpr" (und dem was C++14 dazu noch kommen wird) sind ideal für Mikrocontroller und ermöglichen Dinge die mit C gar nicht gehen. Florian S. schrieb: > und verhindern, dass er C++11 > auf seinem "Weg" will ich garnicht erst versuchen Wär auch ziemlich dumm irgendwie. Florian S. schrieb: > wenn man C++ verwendet, halte ich es für sinnvoll, zumindest auch zum > großen Teil Objektorientiert Ja. Florian S. schrieb: > (als prominentes Beispiel seien v-tables genannt). Wenn man sie denn verwendet; das C-Äquivalent mit Funktionszeigern ist genauso "ineffizient". Man muss nicht jede Funktion virtuell machen. Florian S. schrieb: > Aber auch andere > "Best practices" für C++ haben Nachteile bei Geschwindigkeit und > Ressourcen, Ja, genau wie in C muss man auf µC etwas anders programmieren. > beispielsweise die (häufig zumindest abschaltbaren) > Overflow-Protections genannt. Wo kommt die denn her in C++? Meinst du Canary Bytes, die haben doch nichts mit C++ zu tun. Florian S. schrieb: > Es ist zwar durchaus möglich, dass C++ ähnlich (speziell im Hinblick auf > uCs) guten Code erzeugt wie C, darauf wetten würde ich aber nicht. Es ist aber so. Rate mal wie viele Instruktionen folgender Code generiert:
1 | STM32::SDADC0.configure ().contRegular ().on () |
2 | .fastMode ().on () |
3 | .setRegChannel(4) |
4 | .enabled ().on () |
5 | .apply (); |
Richtig, 6 (darunter kein Funktionsaufruf). Ginge in ASM nicht besser. Ja, das ist Code für den STM32, den hatte ich gerade zur Hand, aber Code für AVR ginge es genauso, da er äquivalente Instruktionen hat. Das Frontent interessiert sich schließlich nicht für die Zielplattform. Florian S. schrieb: > tw: Auch verschiedene Benchmarks - die natürlich auch nicht > repräsentativ oder vollständig sind - zeigen, dass C und C++ keineswegs > gleich sind und C++ bei komplexen Datenverarbeitungstasks Vorteile hat, Sowas wie Numerik ist in C und C++ absolut identisch. Die Vorteile von C++ liegen in der Strukturierung; das hat mit Rechenalgorithmen relativ wenig zu tun.
@Dr. Sommer: Ist das nen offener C++-Wrapper für die STM-Bibliothek oder eine Eigenentwicklung? Als ich mir die letzten Tage die Beispiele angeschaut habe, schrien sie eigentlich irgendwie nach einem schmalen Wrapper... Also wenn's keinen fertigen gibt, werde ich auf kurz oder lang selber einen basteln, zumindest nach und nach für was ich davon nutze...
C++ auf kleinen 8-Bittern ist doch der totale Overkill. Nicht weil es einem um die mehr oder weniger zusätzlich mit Overhead belegten Speicherzellen leid tun muß oder die Leistung gleich total einbricht. Nein, ganz einfach der unnötigen Einarbeitungszeit in ein komplexes Sprachkonzept wegen. Steht in keinem Verhältnis zu den mehr oder weniger schlichten Projekten die letztlich drauf realisiert werden. Ok, ich programmier jetzt "nur" AVRs "nur" aus Hobby und "nur" in ASM. Da schaut man ins Datenblatt und sagt dem Controller dann 1:1 was zu tun ist. Mehr als die paar ASM-Befehle und ihre wenigen Eigenheiten gibts da nicht zu lernen. Mir ist selbst das Klammergedöns von C schon zu viel auch wenns manchmal bei Berechnungen schon komfortabler wär oder man die eine oder andere Lib nutzen könnte. Dafür muß man keine Sprach- und Compilereigenheiten beachten und hat auch keine "künstlichen" Probleme a la Typkonvertierung. Die Codezeilen werden plötzlich sehr kurz und einfach. Den Rest zu gutem Verständnis muß dann allerdings die Doku leisten.
Einem Anfänger C++ zu empfehlen ist jetzt auch nicht gerade eine gute Entscheidung. C++ ist eine der komplexesten Programmiersprachen, die es gibt, mit zahlreichen Fallstricken. Da kann man sich nicht nur in den Fuß schießen, nein, man kann sich ausversehen alle Gliedmaßen mit der Motorsäge amputieren. ;) Die Qualität der Sprache ist auch sehr umstritten. Vielen Anfängern ist C schon zu schwierig, und hier wird C++ empfohlen. WTF?
decimad schrieb: > @Dr. Sommer: Ist das nen offener C++-Wrapper für die STM-Bibliothek oder > eine Eigenentwicklung? Das ist kein Wrapper, das ist eine Eigenentwicklung die komplett frei&unabhängig von ST-Code ist indem sie direkt auf Register zugreift. Wird auch irgendwann mal released, wenn es fertig ist... Moby schrieb: > C++ auf kleinen 8-Bittern ist doch der totale Overkill. Es gibt Leute, die implementieren CANopen auf 8-Bittern. CANopen ist definitiv komplex genug dass man eine Sprache, die viel Struktur bietet aka C++, dafür verwenden sollte... greg schrieb: > Einem Anfänger C++ zu empfehlen ist jetzt auch nicht gerade eine gute > Entscheidung. Das geht, ich hab auch mit C++ angefangen. Man muss nicht sofort template Meta-Algorithmen schreiben, man kann mit den einfachen Dingen anfangen. Und z.B. am PC ist C++ für Anfänger noch viel mehr geeignet, da Dinge wie std::vector und std::string dort das leben drastisch vereinfachen. > > Vielen Anfängern ist C schon zu schwierig, und hier wird C++ empfohlen. > WTF? Ja, weil sie es nicht lernen sondern nur Code Copy&Pasta betreiben. Wenn man es richtig nach Buch lernt geht das ganz gut.
Okay, dann werde ich mich ins C einarbeiten. Gibt es auch mehr Informationen für. :) Vielen Dank für eure Hilfe. Als nächstes steht eine kleine DIY Platinenfräse bei mir auf dem Plan. (dauert aber noch) Das Platinen ätzen geht mir so langsam auf die Nerven ;)
Dr. Sommer schrieb: > Das geht, ich hab auch mit C++ angefangen. Man muss nicht sofort > template Meta-Algorithmen schreiben, man kann mit den einfachen Dingen > anfangen. Aber die ganzen komplizierteren Features und Möglichkeiten verwirren und lenken ab. Insbesondere wenn man fremden Code liest, was ja gerade Anfänger hauptsächlich tun. In C++ ist das besonders schlecht, da es viele Features gibt, die man heute lieber nicht mehr verwenden sollte. > Und z.B. am PC ist C++ für Anfänger noch viel mehr geeignet, > da Dinge wie std::vector und std::string dort das leben drastisch > vereinfachen. Da würde ich lieber eine ordentliche High-Level-Sprache wie z.B. Python oder Java/C# empfehlen. Wie auch immer, C ist auf jeden Fall eine gute Wahl.
greg schrieb: > Da würde ich lieber eine ordentliche High-Level-Sprache wie z.B. Python > oder Java/C# empfehlen. Das seh ich etwas anders. Python ist nicht schlecht für Anfänger (wobei die "ungewöhnliche" Syntax nicht gerade vorteilhaft ist, wenn man irgendwann mal noch andere Sprachen anschaun möchte). Aber C# ist spätestens seit Version 4 extremst überladen, dass es für Anfänger mMn völlig ungeeignet ist und Java ist vom Design her einfach Mist - da wurden meiner Meinung nach zu viele "akademische" Entscheidungen getroffen. Das betrifft sowohl die "PC-Standardimplementierung" als Stackmaschine (bei Dvalik schaut das schon wieder ganz anders aus) als auch die Sprache selbst, die derart auf Design Pattern setzt, dass selbst einfachste Aufgaben über hässliche Umwege umgesetzt werden müssen (da ist C# beispielsweise um Welten besser), Stichwort Getter/Setter, Events,... Andererseits gibts auch ein paar wirklich ekelhafte Fallstricke, wie z.B. Generics (bzw. deren Implementierung über Casts), Strings (die "aussehen" wie primitive Typen aber eigentlich keine sind, aber trotzdem einen +-Operator haben obwohl es eigentlich kein Operatorüberladung gibt), die "implizite" Übergabe by-reference bzw. by-value ohne dass für Anfänger darin ein System zu erkennen wäre (im Gegensatz zur Zeiger vs. Kopie bei C z.B.). Daneben ist der rein objektorientierte Ansatz dieser beiden Sprachen nicht ideal für Anfänger, ich finde klassische prozedurale Sprachen für Einsteiger da leichter zu verstehen. Deswegen wäre Python garnicht so schlecht. Aber auch Basic oder PHP (trotz aller Schwächen - vorteilhaft ist die C-like Syntax) sind mMn keine schlechten Einsteigersprachen. Oder eben C, da es viel Literatur, einen übersichtlichen Sprachumfang aber auch "Zukunftssicherheit" bietet, auch wenn man mit der ganzen Zeigergeschichte und Speicherverwaltung am Anfang ohne Zweifel durcheinander kommen kann, wenn mans nicht sauber lernt.
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.