Anfänger - Embedded C Programmierung lernen - Welche Hardware -

Schau doch mal was die Chinesen an boards haben, da kommste vermutlich 
etwas günstiger mit weg.

Ich hatte irgendwann das Problem, dass meine Logik-Schaltungen zuviele 
74HCxxx ICs benötigten und habe mich daher an AVR herangewagt. Hab mir 
ein Entwicklungsboard um 50€ gekauft und mit dem AVRStudio begonnen. 
Nach einer Stunde wusste ich, dass die 50€ für das Enwicklungsboard 
rausgeschmissenes Geld waren...ich hätte mir gleich einen ATxx um 2€ 
kaufen sollen und direkt programmieren ... so einfach war alles.

Wer mit 32Bit µCs anfängt, hat halt schon einen ganz anderen Befehlssatz 
und Funktionsumfang vor sich. Wenn man aufwändige Berechnungen machen 
will, dann ist das schon gut, aber für Logik Schaltungen nicht 
notwendig.

Da der Sinn hinter C ja ist die Hardware noch ein Stück weiter zu 
extrahieren, ist es eigentlich egal welche Hardware Du verwendest. Ich 
würde Dir da aber was simples empfehlen bei dem Du einfach Deinen Port 
einschaltest und Du nicht erst mal deinen Takt zum Port hin leiten musst 
bis das Teil was macht.

Um C zu lernen musst Du aber erst mal ansatzweise Assembler können, 
sonst wirst Du viele Sachen nicht verstehen. C ist eine Sprache die zum 
Verständnis Assembler voraussetzt.

Ein STM32F0 Discovery (Cortex-M0) gibt es zur Zeit für 5€ + 2,90€ 
Versand bei eBay:
http://m.ebay.de/itm/Entwicklungsboard-STMicroelectronics-STM32F0308-Falue-line-Discovery-1-Stuck-/311646653104?hash=item488f968ab0%3Ag%3A7NEAAOSw-KFXdQSJ&_trkparms=pageci%253Abf1040fd-6455-11e6-bbad-005056a01e3b%257Cparentrq%253A97a55d171560a78546269786fff16835%257Ciid%253A4
Vom gleichen Versender gibts das F429 Discovery (Cortex-M4) mit LCD und 
SDRAM für 15€. Beide haben nen ST-Link Debugger on board. Für das Geld 
kann man eigentlich nicht viel falsch machen.

PittyJ schrieb:
> Lass den Assembler sein.

Der Sinn hinter der Empfehlung mit Assembler zu arbeiten ist nicht, um 
damit später Geld zu verdienen, sondern als Lehrmethode. Ohne Assembler 
wirst Du C und C++ nicht verstehen und auf ewig verdammt sein, nicht zu 
wissen, was Du eigentlich machst.

Assembler lehrt besonders eine Sache, nämlich seine Probleme möglichst 
einfach zu lösen. Sprich Du überlegst Du zuerst was Du machst, und 
findest dann die einfachste Lösung. Das ist eine Fähigkeit die scheinbar 
nur wenige Leute haben. Das sind dann auch die Leute die in Firmen ihre 
Projekte rechtzeitig und in hoher Qualität ausführen.

Ich habe ein mehr oder minder komplexes Projekt ohne am Kenntnisse 
geschrieben und es tut was es soll. Es geht also auch ohne. Hätte ich 
die zeit, würde ich aber sehr gerne mal in asm reinschauen. Genau aus 
dem Grund den Christian Berger nennt.

Christian B. schrieb:
> Um C zu lernen musst Du aber erst mal ansatzweise Assembler können

Ich bin da anderer meinung. Assembler zu lernen ist nicht notwendig, um 
C zu lernen, eher Kontraproduktiv. Die Idee bei C code zu wissen was der 
Compiler daraus für assembler macht ist zum scheitern verurteilt, weil 
nicht nur jeder Compiler etwas anderes macht, der Compiler kann auch 
ganz andere Implementationen als der C-Code verwenden. z.B. eine sprung 
Tabelle in asm aus vielen if abfragen in c, oder separate Prüfungen und 
Jumps in asm wo man eine Sprungtabelle mittels switch in c wollte. Es 
kann sinn machen ASM und C gemeinsam zu verwenden, aber dann braucht man 
nur die ABI und etwas ASM zu kennen.

Wenn man ASM Verwendet macht das die Dinge auch nicht einfacher, man 
muss selbst Register sichern, hat Prozessorspezifische Befehle mit 
allerhand Seiteneffekten, die man kennen und Ausnutzen muss, nur um ne 
einfache if abfrage mit etwas boolscher logik in asm nachzubauen, z.B. 
durch nuzung des carry flags und nem entschprechenden jmp Befehl. Solche 
Dinge eben, an die man in C nicht denken sollte.

Es ist zwar sicher so, dass ASM gut ist um das Prozedurale denken zu 
üben, also z.B. um X zu bekommen, brauche ich b und muss dannach über 
schritt c d berechnen, um über d X zu bestimmen, etc. Allerdings ist 
diese Schritt für Schritt denkweise auch in reinem C wie jeder Anfännger 
anfängt. Die Schwierigkeiten starten erst, wenn die Anfänger lernen 
müssen, den Code zu Strukturieren, Konzepte wie OOP, Paradigmen wie 
Statemachines, oder Datenstrukturen wie Verlinkte Listen und Stacks zu 
lernen.

Ich denke beste die Vorgehensweise beim Lernen von Programmiersprachen 
wie C ist wiefolgt:
  1) Allgemeine Programmflusskontrollstrukturen für Prozedurale sprachen 
lernen, wie Bedingungen (if, else), Schleifen (while, for), 
Funktionsaufrufe
  2) Variablen + Operator Präzedenzen, eigene Funktionen, Parameter und 
Storage duration, sowie Variable Scope (sichtbarkeit)
  3) Pointerarithmetik
  4) Aufteilen von Code in möglichst viele Funktionen, wobei möglichst 
jede Funktion eine klare Aufgabe erfüllt, und einen eindeutigen 
selbstbeschreibenden nicht zusammengekürzten Namen hat, z.B. 
"list_addItem" statt "lait" (gillt auch für Variablennamen, ausser bei 
i,j,k,l).
  5) Grupieren von zusammengehörenden Daten in Structs
  6) Unterteilen von Programmteile im Module/Compilationsunits, die 
Möglichst unabhängig voneinander sind. Evtl. Schichtenarchitekturen 
studieren. Rekursive Abhändigkeiten vermeiden.
  7) Lernen algemeiner Datenstrukturen und Algorithmen, wie diverse 
Listen, Sortieralgorithmen, etc.
  8) Betrachten anderer Konzepte stat Prozedural, wie Funktional oder 
Objektorientiert, etc. Eventuell andere Sprachen ausprobieren, die 
andere Konzepte aufweisen.

Aber das wichtigste beim Lernen: Fehler machen! Nichts ist 
eindrücklicher, als wenn man das halbe Projekt umschreiben muss, weil 
man z.B. Header übermassig ineinander Inkludiert, ein Designproblem hat, 
oder sich auf eine nicht garantierte Annahme verlassen hat. In dem 
Sinne, zuerst mit Pointern herumschiessen, danach richtig machen ;)

Zwischendurch sollte man eventuell noch einen Blick in den Standard 
werfen, besonders den Abschnitt mit undefined und implementation defined 
behaviour.

Und einige Styleguids lesen. Es ist immer so Lästig wen man Code sieht, 
dessen Einrückung eher nach einem Wollknäul als nach strukturiertem Code 
aussieht...

Und danach kann man C.

PS: Den compiler immer auf maximale Fehlerintoleranz/Warnlevel 
einstellen und den Standard einstellen, mindestens c99 oder neuer. (z.B. 
gcc -Wall -Wextra -pedantic -Werror -std=c99)

Daniel A. schrieb:
> Die Schwierigkeiten starten erst, wenn die Anfänger lernen
> müssen, den Code zu Strukturieren, Konzepte wie OOP, Paradigmen wie
> Statemachines, oder Datenstrukturen wie Verlinkte Listen und Stacks zu
> lernen.
HA! Genau an dem Punkt stehe ich gerade. ACK!

Moby A. schrieb im Beitrag #4687252:
> wo es (unnötig) schwierig wird muß man glaub ich nicht unbedingt
> gelangen.
Naja, wenn man nicht nur, sehr übertrieben gesagt, "eine LED zum 
blinken" bringen möchte, tut man sich mit OOP einfacher. Wenn man mal so 
ein paar Sachen geblickt hat, wird das um längen einfacher als mit 
plain-C.

Es ist wie du sagst:
Moby A. schrieb im Beitrag #4687252:
> Nach C und anderen höheren Sprachen mit
> ihren vielen Ausdrücken und komplizierten Konstruktionen hat es mich auf
> einfacher Hardware wie dem AVR noch nie gedürstet
Es kommt auf den Einsatzzweck an.

axe schrieb:
> Wenn du also gut Programmieren lernen willst dann beginne nicht mit
> Assembler sondern mit SML.

Das wird ja immer besser :D als ob C++ nicht schon übel genug wäre kommt 
jetzt auch noch so richtig abgefahrener Kram. Warum nicht gleich ABAP? 
In Giessen an der FH ist das der "Programmiergrundkurs" für die 
Wirtschaftsinformatiker. Die können nachher nur weder Wirtschaft noch 
Informatik (und programmieren schon gar nicht). Die können dann 
eigentlich nur SAP.

*./* schrieb:
> Um gute C++ Programme zu schreiben brauchst du kein ASM sondern musst
> wissen wie man objektorientiert programmiert und keinen Spaghetti Code
> produzieren.

Auch wenn ich selber nicht so den riesengroßen Nutzen in Assembler sehe 
und zum Einstieg eher C nehmen würde, meine ich das Assembler einem (im 
Embedded Bereich) auf jeden Fall deutlich mehr bringt als C++. Ich weiß 
ehrlich gesagt nicht wie besoffen man sein muss um einen Mikrocontroller 
in C++ zu programmieren. Warum dann nicht gleich Java?

Christopher J. schrieb:
> Ich weiß ehrlich gesagt nicht wie besoffen man sein muss um einen
> Mikrocontroller in C++ zu programmieren
Und ich frag mich wie bekifft man sein kann um mit plain-c ein gui zu 
programmieren :)

Edit: warum nicht gleich mit asm? Oder gleich maschinencode.

Christopher J. schrieb:
> Warum nicht gleich ABAP?
> ... wie besoffen man sein muss um einen Mikrocontroller
> in C++ zu programmieren

Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache.
Für betriebswirtschaftliche Software ABAP (was wohl besonders Ei denen 
unbeliebt ist, die zusehen müssen, wie andere damit Geld verdienen)
und für μC gerne C++ (denn auch da gilt, wenn man's kann, dann geht's 
sehr gut). C++ geht gut auf allem was ein GCC-Backend hat.

Carl D. schrieb:
> Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache.
"Nein?!" - "Doch!" -  "Ohh!"

Reginald L. schrieb:
> Carl D. schrieb:
>> Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache.
> "Nein?!" - "Doch!" -  "Ohh!"

Frag das doch mal den, der vorher anderes in den Raum gestellt hat.

Carl D. schrieb:
> Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache.
"Nein?!" - "Doch!" -  "Ohh!"

Carl D. schrieb:
> Frag das doch mal den, der vorher anderes in den Raum gestellt hat.

Du kennst dich wohl Louis de fines oder ;)

https://youtu.be/w4aLThuU008

Reginald L. schrieb:
> Und ich frag mich wie bekifft man sein kann um mit plain-c ein gui zu
> programmieren :)

Ja ich weiß das C nicht das Allheilmittel ist und das die richtigen 
Druffies (besoffen und bekifft) den Mikrocontroller in C++ und die GUI 
in C programmieren :D
Auch ABAP, SML und was auch immer mag alles seine Daseinsberechtigung 
haben aber meiner Meinung nach eben nicht im Bereich Mikrocontroller.


Carl D. schrieb:
> Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache. Für
> betriebswirtschaftliche Software ABAP (was wohl besonders Ei denen
> unbeliebt ist, die zusehen müssen, wie andere damit Geld verdienen) und
> für μC gerne C++ (denn auch da gilt, wenn man's kann, dann geht's sehr
> gut). C++ geht gut auf allem was ein GCC-Backend hat.

Ja, auch mit COBOL kann man heute noch gut Geld verdienen und ich gönne 
es den Leuten die es machen. Ich würde nur keinem empfehlen damit 
programmieren zu lernen.

Was C++ angeht sind die Geschmäcker ja bekanntlich verschieden und 
natürlich kann man einen uC damit befeuern. Ich persönlich halte es 
jedoch nicht für sinnvoll, weil C++ nur unnötige Komplexität rein bringt 
und zusätzliche Ressourcen frisst, die ohnehin schon sehr knapp sind. 
Aber jeder wie er will... Der TO wollte aber glaube ich C :D

Reginald L. schrieb:
> Carl D. schrieb:
>> Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache.
> "Nein?!" - "Doch!" -  "Ohh!"
>
> Carl D. schrieb:
>> Frag das doch mal den, der vorher anderes in den Raum gestellt hat.
>
> Du kennst dich wohl Louis de fines oder ;)
>
> https://youtu.be/w4aLThuU008

Ich kenn mich was?
In welcher Sprache soll ich antworten? Es scheinen deutsche Worte zu 
sein, aber viele "Syntax Error"'s drin.

BTW, den kleinen Franzosen kenn ich aus der Zeit, als er noch Filme 
gedreht hat, brauch also keine Details zu dem Spruch.

Noch mal am Stück: ich habe einem geantwortet, der Programmiersprachen 
ungeachtet ihrer Geeignetheit für das jeweils zu lösende Problem 
bewertet hat. Bzw. ablehnt, weil sie ihm nicht gefallen. Oder wohl eher, 
weil er sie nicht versteht. Deshalb der von dir aus dem Zusammenhang 
zitierte Satz.

Moby A. schrieb im Beitrag #4688028:
> Ein GUI lässt sich allerdings durchaus auch in Asm erstellen.
Hab nie was anderes behauptet.

Carl D. schrieb:
> Ich kenn mich was?
> In welcher Sprache soll ich antworten? Es scheinen deutsche Worte zu
> sein, aber viele "Syntax Error"'s drin.
Gnagnagna. Geil dich dran auf.

Christopher J. schrieb:
> Was C++ angeht sind die Geschmäcker ja bekanntlich verschieden und
> natürlich kann man einen uC damit befeuern. Ich persönlich halte es
> jedoch nicht für sinnvoll, weil C++ nur unnötige Komplexität rein bringt
> und zusätzliche Ressourcen frisst, die ohnehin schon sehr knapp sind.

Entschuldige bitte, aber so pauschal gesagt ist das schlicht falsch.

Es gibt C++-Features, auf die man in eng begrenzten Umgebungen wie einem 
Mikrocontroller besser verzichtet. Beispiele dafür sind die dynamische 
Speicherverwaltung und alles, was daran hängt: Exceptions, STL, etc. 
Aber auf kleinen Mikrocontrollern benutzt sowas ja auch niemand.

Viele andere C++-Features, wie Klassen, Templates, Polymorphie und 
Vererbung lassen sich auch auf einem Mikrocontroller sinnvoll nutzen, 
und bringen dann dieselben Vorteile wie sonst auch: besser 
strukturierten, modularen, besser lesbaren und wiederverwendbaren, oft 
kompakteren Code. Und diese Features kosten, richtig angewendet, 
überhaupt keine zusätzlichen Ressourcen.

Insofern muß man gar nicht "besoffen" sein, um C++ auf Mikrocontrollern 
zu nutzen. Ganz im Gegenteil muß man dazu nüchtern und fähig sein, und 
wenn man das ist, dann macht das sogar richtig Spaß.

DoctorKnowItAll schrieb:
> GUIs macht man in python als webinterface damit die Leute ihre
> Smart-Devices über Handy steuern können.

Flask rult! ;-)

Das Bild passt einfach perfekt.
Aber bitte nicht falsch verstehen.

Christian B. schrieb:
> Um C zu lernen musst Du aber erst mal ansatzweise Assembler können,
> sonst wirst Du viele Sachen nicht verstehen. C ist eine Sprache die zum
> Verständnis Assembler voraussetzt.

Du musst auch erstmal zumindest eine Lehre als KFZ Mechaniker 
abgeschlossen haben, um Autofahren zu verstehen.
Sicher ist es hilfreich, vor allem um zu verstehen wie der uC arbeitet, 
aber man kann sich auch später noch dafür interessieren.
Wenn man anfängt, dann braucht man erst einmal schnelle Erfolge, damit 
man den Spaß nicht verliert.

Nop schrieb:
> Nicht zwangsläufig. Das Problem dabei ist aber, daß man dann nicht nur
> wissen muß, wie man in C++ programmiert, sondern auch, was welche
> Ressourcen kosten. Der höhere Abstraktionsgrad von C++ wird da schnell
> zum Ärgernis, weil er vernebelt, statt zu helfen.
>
> Und dann muß man natürlich noch Programmierer haben, die auch dann noch
> gut mit C++ sind, wenn sie die Hälfte der Features nicht nutzen können
> und auch noch wissen müssen, welche.

Das meinte ich auch unter anderem mit der Komplexität. Es reicht eben 
nicht einfach nur ein guter C++ Programmierer für Desktop-Software zu 
sein. Beschränkt man sich auf C hat man es etwas übersichtlicher.

Sheeva P. schrieb:
> Christopher J. schrieb:
>> Was C++ angeht sind die Geschmäcker ja bekanntlich verschieden und
>> natürlich kann man einen uC damit befeuern. Ich persönlich halte es
>> jedoch nicht für sinnvoll, weil C++ nur unnötige Komplexität rein bringt
>> und zusätzliche Ressourcen frisst, die ohnehin schon sehr knapp sind.
>
> Entschuldige bitte, aber so pauschal gesagt ist das schlicht falsch.
>
> Es gibt C++-Features, auf die man in eng begrenzten Umgebungen wie einem
> Mikrocontroller besser verzichtet. Beispiele dafür sind die dynamische
> Speicherverwaltung und alles, was daran hängt: Exceptions, STL, etc.

Entschuldigung angenommen :D
Natürlich war das etwas pauschalisiert.

Sheeva P. schrieb:
> Aber auf kleinen Mikrocontrollern benutzt sowas ja auch niemand.

Wenn es doch nur so wäre. Natürlich macht es keinen Sinn diese Features 
zu nutzen aber als Anfänger durchzublicken welches Feature den Code 
aufbläht und welches nicht macht die Sache meiner Meinung nach einfach 
komplizierter.

Sheeva P. schrieb:
> Viele andere C++-Features, wie Klassen, Templates, Polymorphie und
> Vererbung lassen sich auch auf einem Mikrocontroller sinnvoll nutzen,
> und bringen dann dieselben Vorteile wie sonst auch: besser
> strukturierten, modularen, besser lesbaren und wiederverwendbaren, oft
> kompakteren Code. Und diese Features kosten, richtig angewendet,
> überhaupt keine zusätzlichen Ressourcen.

Genau da bin ich anderer Meinung, zumindest was Lesbarkeit und 
Wiederverwendbarkeit angeht. Vererbung halte ich (bis auf wenige 
Ausnahmen,z.B. GUI) für eine ganz schlechte Idee aber das ist wie gesagt 
Geschmackssache.

Nop schrieb:
> Allerdings kann man auch in C objektorientiert programmieren, ich sag
> nur structs mit Funktionszeigern.

Dito. Auch Interfaces sind in C kein Problem und spätestens seit 1973 
mit open/read/write/close im Einsatz. Man muss natürlich wissen was 
"unter der Haube" eigentlich abgeht.

Jetzt aber mal zurück zum Thema:
TheDarkNightRises schrieb:
> Technisches Datenblatt:
> https://cdn-shop.adafruit.com/datasheets/EdisonDatasheet.pdf

Da der TO wirklich tief in die Materie einsteigen will (Timer, 
Interrupts, etc.) kann ich persönlich (obwohl ich Linux mag) nur davon 
abraten so ein Intel Ding für erste Gehversuche zu nehmen. Auf der einen 
Seite ist der Overhead des OS mMn unnötig kompliziert und auf der 
anderen Seite darf sich dieses zweiseitige Etwas eigentlich niemals 
Datenblatt schimpfen. "Broschüre" wäre schon fast eine Übertreibung.

Moby A. schrieb im Beitrag #4689527:
> Was Dir völlig abgeht

...kannst Du sicher nicht beurteilen. :-)

> In der Medizin sagt man: Wer heilt hat recht, und genauso hier: Wer Spaß
> an einer Sache hat der hat auch Recht damit, denn um Spaß gehts
> letztendlich (oder sollte es gehen).

Das gilt für Hobbyisten. Profis werden nicht dafür bezahlt, Spaß zu 
haben, sondern dafür, mit möglichst geringem Aufwand Produkte zu 
entwickeln, die sich gewinnbringend verkaufen lassen.

Daß mir meine Arbeit obendrein Spaß macht, ist zwar sehr angenehm und 
erfreulich, am Ende aber doch nur eine Nebensache.

> Tatsache ist nach wie vor, daß bei Embedded auf
> MCs selbst anno 2016 die große Mehrheit auf prozedurale Programmierung
> setzt- und da darf auch ein SheevaP davon ausgehen, daß dies seine (ganz
> menschlichen) Gründe hat ;-)

Das halte ich für ein Gerücht. Der Trend geht klar zu objektorientierten 
Techniken, nicht nur auf größeren Mikrocontrollern, sondern mittlerweile 
auch bei den kleinen. Häufig werden OO-Techniken sogar mit Sprachen wie 
C genutzt, die eigentlich keine direkte Unterstützung für OO mitbringen. 
Das kann nicht verwundern, ist die Objektorientierung letztlich nichts 
anderes als die Fortentwicklung und Erweiterung von Techniken und 
Entwurfsmustern, die sich seit Jahrzehnten bewährt haben. In der 
modernen Fachliteratur wie "Making Embedded Systems" und "21st Century 
C" wird das sehr ausführlich erläutert und begründet.

Die Diskussion um OO ist heute letztlich dieselbe wie seit dreißig 
Jahren, hat sich aber verlagert: während früher in allen Umfeldern der 
Entwicklung über den Sinn, Zweck und Nutzen der OO diskutiert wurde, hat 
sie sich in der Breite nahezu überall durchgesetzt und die Diskussion 
beschränkt sich heute nurmehr auf kleine Nischen wie den 
Embedded-Bereich. Aber auch im professionellen Embedded-Umfeld sind 
objektorientierte Techniken längst zum Standard avanciert -- 
Grundsatzdiskussionen wie diese sehe ich heute im Wesentlichen nur noch 
mit Hobbyisten und Alteingesessenen, die (und da hast Du ausnahmsweise 
Recht, das sind tatsächlich zutiefst menschliche Gründe) nichts Neues 
mehr lernen wollen oder können.

Allerdings ist es durchaus interessant, daß Du zur Begründung von primär 
technischen Entscheidungen auf menschliche Gründe zurückgreifen mußt. In 
technischer Hinsicht haben sich die Vorteile der OO offensichtlich 
längst erfolgreich durchgesetzt, ob es Dir gefällt oder nicht. :-)

Christopher J. schrieb:
> Sheeva P. schrieb:
>> Es gibt C++-Features, auf die man in eng begrenzten Umgebungen wie einem
>> Mikrocontroller besser verzichtet. Beispiele dafür sind die dynamische
>> Speicherverwaltung und alles, was daran hängt: Exceptions, STL, etc.
>
> Entschuldigung angenommen :D
> Natürlich war das etwas pauschalisiert.
>
> Sheeva P. schrieb:
>> Aber auf kleinen Mikrocontrollern benutzt sowas ja auch niemand.
>
> Wenn es doch nur so wäre. Natürlich macht es keinen Sinn diese Features
> zu nutzen aber als Anfänger durchzublicken welches Feature den Code
> aufbläht und welches nicht macht die Sache meiner Meinung nach einfach
> komplizierter.

Das gilt aber nicht nur für die OO, sondern überall, wo Abstraktion ins 
Spiel kommt. Auch in C gibt es Features, die den Code aufblähen, wie zum 
Beispiel die Funktionen der printf()-Familie oder Fließkommaarithmetik, 
letztere sogar in Abhängigkeit von der Zielplattform. OO heißt ja nicht, 
daß man sein Werkzeug nicht kennen muß.

> Sheeva P. schrieb:
>> Viele andere C++-Features, wie Klassen, Templates, Polymorphie und
>> Vererbung lassen sich auch auf einem Mikrocontroller sinnvoll nutzen,
>> und bringen dann dieselben Vorteile wie sonst auch: besser
>> strukturierten, modularen, besser lesbaren und wiederverwendbaren, oft
>> kompakteren Code. Und diese Features kosten, richtig angewendet,
>> überhaupt keine zusätzlichen Ressourcen.
>
> Genau da bin ich anderer Meinung, zumindest was Lesbarkeit und
> Wiederverwendbarkeit angeht. Vererbung halte ich (bis auf wenige
> Ausnahmen,z.B. GUI) für eine ganz schlechte Idee aber das ist wie gesagt
> Geschmackssache.

Aus einer anderen Diskussion habe ich ein kleines Beispiel mitgenommen, 
wie OO mit wenig Aufwand besser les- und wartbaren Code ermöglicht:

https://www.mikrocontroller.net/attachment/246051/main.cpp

Dort wird die Vererbung benutzt, um die abstrakten, allgemeinen Namen 
der Parent-Methoden wie setHigh() und isHigh() in sprechende, zum 
betreffenden Objekt passende Namen wie gedrucket() und eingelegt() zu 
überführen, beim Instanziieren werden zudem die Objekte mit sprechenden 
Namen versehen. Durch diese extrem leichtgewichtige Abstraktion, die der 
Compiler restlos wegoptimiert, erkennt sogar ein Laie, der nicht 
programmieren kann und keine Ahnung von C hat, was in der 
main()-Funktion passiert.

Klar: mit Makros und Funktionen kann man Ähnliches erreichen, aber 
dadurch wird es nicht lesbarer -- im Gegenteil: der Vorteil der OO ist 
an dieser Stelle, daß sie das menschliche Denken nahezu perfekt 
abbildet.

Das ist natürlich nur ein einfaches Beispiel. Aber von grundsätzlichen 
Aussagen wie "XY halte ich für eine schlechte Idee" halte wiederum ich 
ziemlich wenig, auch und gerade in Bezug auf die Vererbung, welche durch 
vielfach unnötige, falsche Anwendung in Verruf geraten ist. Letztlich 
ist es damit ja wie mit jedem anderen Werkzeug: man muß immer wissen, 
welches für das konkrete Problem angemessen ist, und wie man es am 
Besten benutzt. (Soviel zum Thema Binsen.) ;-)

Moby A. schrieb im Beitrag #4692906:
> Sheeva P. schrieb:
> Alles dort wo es Sinn macht!

Genau das sage ich doch. Schön, daß Du mir zustimmst. :-)

>> und gerade in Bezug auf die Vererbung, welche durch
>> vielfach unnötige, falsche Anwendung in Verruf geraten ist.
>
> Um Himmels Willen, wie konnte das bloß passieren???

Niemand hat behauptet, daß OO einfach wäre. Daß es zudem einen Hype 
gegeben hat, in dem jeder Marketing- und Management-Mensch seine 
Produkte mit dem modernen Nimbus der OO schmücken wollte, natürlich ohne 
dabei Zeit und Geld in ein sauberes OO-Refactoring investieren zu 
wollen, hat dazu geführt, daß oft lediglich alter, vorhandener Code 
sinn-, lieb-, plan- und konzeptlos in einen oberflächlichen OO-Rahmen 
gepreßt wurde, ohne jedoch die Konzepte der OO korrekt anzuwenden und 
ohne ihre Stärken wirklich zu nutzen. Das war der Technik und ihrem Ruf 
natürlich nicht gerade zuträglich. :-)

Moby A. schrieb im Beitrag #4693439:
> Diese Schwierigkeiten sind der OOP selbst immanent.

Nö.

> Begreif das endlich.

Nö.

> Nix da mit "perfekter Abbildung" ! Statt dessen neue Bürokratie über
> Bürokratie

Nö. Daß Du es nicht verstehen willst und darum nicht mitreden kannst, 
ist erfreulicherweise nicht mein Problem. :-)