mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Anfänger - Embedded C Programmierung lernen - Welche Hardware -


Autor: DonKanaille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen,

kurz zu mir, ich bin Informatik Student, habe einfache Kenntnisse, eben 
das was man in der ersten Semestern so lernt.

Ich Interessiere mich für die Embedded Programmierung und bin auf der 
Suche nach einer Möglichkeit mir in diesem Bereich Grundkenntnisse 
anzueignen.

Die Überlegung war das Olimex das SAM7-P256 mit Olimex ARM-USB-OCD-H 
JTAG Debug Interface anzuschaffen (zusammen ca. 100€).

Wäre solch ein Board für einen Anfänger passend oder gibt es evtl. 
bessere ?

Erste Lernziele sind Interruptsteuerung, Speicherverwaltung und I/O. 
Denkbares erstes Projekt: Ansteuerung von einem LED Cube der 
verschiedene Muster ausgeben kann und diese über Schalter verändert.

Wie gesagt, über eine Empfehlung für bestimmte Hardware / Adapter würde 
ich mich sehr freuen, vielleicht hat der ein oder andere auch einen 
guten Rat.

Vielen Dank im Voraus !

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DonKanaille schrieb:
> Olimex das SAM7-P256 mit Olimex ARM-USB-OCD-H JTAG

Habe früher selbst Olimex genutzt aber inzwischen spricht folgendes 
dagegen:

Die Hersteller bieten inzwischen ihre Boards genauso günstig und ein 
professioneller Debugger ist schon dabei. Daher bietet Olimex auch keine 
neuen uC Boards mehr an. Auf dem genannten SAM7-P256 ist ein ARM7 der 
inzwischen durch Cortex M3/M4 abgelöst wurde.

Ich würde ein Cortex M3/M4 Board mit professionellem J-Link Debugger 
empfehlen z.B.

http://www.embeddedartists.com/products/lpcxpresso...

Oder mit CMSIS-DAP Debugger (Open-Source)

http://www.embeddedartists.com/products/lpcxpresso...

DonKanaille schrieb:
> Ansteuerung von einem LED Cube

Für sowas kleines wäre eventuell auch ein Cortex M0 zu empfehlen, den es 
dann auch als DIP fürs Steckbrett gibt:

http://www.embeddedartists.com/products/lpcxpresso...

Noch was ganz anderes: auch das Raspberry Pi 2 mit Cortex A7 kann ohne 
Betriebssystem programmiert und als günstiger uC verwendet werden:

http://www.valvers.com/open-software/raspberry-pi/...

Autor: Hosenmatz (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hast Du denn schon einen Kurs in C erfolgreich abgeschlossen? Das würde 
ich Dir als erstes empfehlen. Und eine gewisse Erfahrung in der 
Implementierung von Programmen auf PCs. Insbesondere ein paar 
Basisalgorithmen. Sortieren, Suchen, ein paar komplexere Berechnungen. 
Da gibt es genügend Fallstricke die nicht mit uCs zu tun haben.

Letztlich ist der konkrete Mikrocontroller eigentlich egal. Das wirst Du 
an den Flamewars sehen, die hier um die "richtige" Wahl kreisen. 
Vielleicht ist der AVR oder PIC für den Anfang etwas einfacher, da die 
Peripherie weniger komplex ist. Das ist alles.
Kauf Dir so etwas oder halt was, was Dir interessant erscheint.

Autor: Noch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja....

der alte Flamewar zwischen den Anhängern der 8bit-Mikrokontroller.

Lohnt es sich überhaupt noch die Einarbeitung in die 8bit Tricksereien? 
Oder besser gleich mit C++ auf  Cortex M7 anfangen?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 8bit Tricksereien?

Wie bitte? Was ist das?

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
>> 8bit Tricksereien?
>
> Wie bitte? Was ist das?

Da 8bit-MCUs nur 25% des magischen Rauches von 32bit-MCUs beinhalten, 
andererseits aber dieselben Berechnungen machen sollen, muß man die 
übrigen 75% des magischen Rauches in Software emulieren, und das sind 
dann die 8bit-Tricksereien.

Autor: Dennis R. (dennis_ec) Flattr this
Datum:

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

Autor: grundschüler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
atmega328-board + programmer für deutlich unter 10€ ist für jeden 
Anfänger völlig ausreichend. Drunter -atmega8- sollte man nicht weil 
hoffnungslos veraltet. Drüber -ARM- bringt am Anfang keinen zusätzlichen 
Erkenntnisgewinn. Einfachste Programmierumgebung ist winAVR.

Autor: maik (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Das Discovery Board von ST hat einen Debugger schon dabei.

http://www.exp-tech.de/mainboards/arm?p=2

Als Entwicklungsumgebung eignet sich CooCox und GCC.

Die Olimex Bards sind auch nicht schlecht, man braucht aber zusätzlich 
einen Debugger der mit ca 60 Euro dann für heutige Verhältnisse recht 
teuer ist.

Wichtige ist auch welche Software, Betriebssystem unterstützen das Board 
bereits.

Autor: Oppa (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
http://www.cypress.com/documentation/development-k...

$4 Cortex M0 sollte zum Reinschnuppern reichen. Hat allerdings keinen 
Debugger...

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Da 8bit-MCUs ... muß man die übrigen 75% des magischen Rauches in
> Software emulieren, und das sind dann die 8bit-Tricksereien.

Das ist doch quatsch. Ich benötige nur selten 32bit Operationen. Und die 
kann ein 8bit Mikrocontroller genau so gut ausführen, wie ein 32bitter - 
nur etwas langsamer.

Außerdem empfinde ich das Zerlegen von Operationen in Teilschritte 
keinesfalls als Trickserei. Auch 32 bit Geräte zerlegen viele 
Operationen in kleinere. Das ist ganz normale Computertechnik.

Wenn wir Menschen schon in der Grundschule mit 32bit Binärzahlen rechnen 
würden und unser Zeichensatz 32bit Unicode wären, dann könnte ich das 
vielleicht noch nachvollziehen.

Ich bin allerdings mit Computern groß geworden, die ca 1 Millionen 8bit 
Operationen pro Sekunde ausführen konnten. Verglichen damit ist ein 
Atmega168 schon ratten-schnell - selbst bei 32bit Operationen. Am 
Beispiel Intel habe ich gelernt, dass man mehr Mhz und cleverem Cache 
mehr anfangen kann, mit mehr Busbreite. Der Wechsel von 32bit auf 64bit 
hat im PC Bereich ungefähr gar nichts gebracht. Eine Verdoppelung der 
Taktfrequenz mit entsprechend schnellem Speicher war hingegen schon 
spürbar.

Für mich ist der einzig spürbare Vorteil von 64bit Linux, dass die 
Programme mehr Speicher nutzen können. Aber das ist eine ganz andere 
Baustelle, da geht es primär um die Größe der Adresssen, nicht um die 
Breite der Rechenregister.

: Bearbeitet durch User
Autor: Fire H. (fireheart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian B. (casandro) Flattr this
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: visitor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist sicherlich hilfreich, wenn man Assemlber kann bzw. kennt bevor 
man mit C beginnt. Es ist aber nicht zwingend notwendig! Mit 
Assembler-Kenntnissen ist es leichter zu verstehen wie die HW arbeitet 
und somit geht man bei der C Programmierung etwas anders vor als wenn 
man auf einem PC in C programmiert.

Autor: Lothar (Gast)
Datum:

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

Dem ist keineswegs so. Aber wenn Interesse an Assembler besteht spricht 
nichts gegen einen Einstieg mit ARM bei dem 90% der Programme mit 25 
Befehlen auskommen, das kann man problemlos lernen z.B.

http://www.peter-cockerell.net/aalp/html/frames.html

Hosenmatz schrieb:
> AVR oder PIC für den Anfang

Es spricht gar nichts gegen 32-Bit ARM für den Anfang, aber wenn doch 
8-Bit dann wohl eher ein Industrie-Standard 8051 Board mit 
professionellem J-Link Debugger z.B.

http://de.rs-online.com/web/p/entwicklungskits-pro...

Autor: PittyJ (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Lass den Assembler sein. Vor 25 Jahren habe ich mein Geld damit 
verdient. Doch heute brauche ich den gar nicht mehr. Geht auch alles mit 
C++, selbst Interrupt Routinen.
Mein Projekt ist portabel, das läuft auf ARM und Mips Prozessoren. Das 
würde mit Assembler gar nicht gehen. Ich weiss nicht mal mehr, wie die 
Assembler-Befehle auf dem Mips-Prozessor lauten.

Meine Empfehlung (mal was anderes):
Ein NXP Xpresso Board (ARM M0). Kann einfach über USB programmiert und 
auch debugt wergen. Die IDE in Eclipse geht gut. Die Beispiele sind 
ordentlich. Ein I2C-Sensor ging innerhalb von 2 Stunden. Und das Board 
kostet auch nur 20 Euro.

Autor: hugo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ASM brauchst du um die C Umgebung zu initialisieren oder um 
Multitasking zu realisieren. Ich gehe davon aus das du als Informatik 
Student etwas über RISC-, CISC-CPUs, Programmierung in C, C++, SML, Java 
usw. weist.
Am einfachsten ist ein Arduino, da hast du in 1 Minute eine Led 
geschaltet, wenn du allerdings dann was sinnvolles machen willst musst 
dich durch den ganzen Arduino Scheiß arbeiten.
Wenn du in ASM programmieren willst nimm einen AVR.
Wenn du aber auch ein Multitasking System wie FreeRTOS, ChibiOS oder 
ähnliche und eventuell auch einen LwIP Stack brauchst, dann nimm C und 
eigentlich sollte C durch C++ abgelöst werden. Vorhandene Software ist 
aber meistens in C geschrieben.
Wenn du viel machen willst und viel selber machen willst(kein Linux) 
dann nimm eine Cortex M4, viel RAM und Flash, besser mehr als zu wenig.

Autor: DonKanaille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal vielen Dank für die ganzen Beiträge, das hat mir sehr geholfen !

Am meisten Interesse habe ich derzeit an folgendem Board/Bundle:
http://www.embeddedartists.com/products/boards/lpc...

Da das LPC4088 jedoch etwas außerhalb meines Budgets liegt tendiere ich 
aktuell zu dem LPC1549 (auch Cortex-M4) wie es empfohlen wurde:
http://www.embeddedartists.com/products/lpcxpresso...

Ich werde mich noch weiter Informieren und in den kommenden Tagen 
entscheiden.

Da Fragen zu meinem aktuellen Kenntnisstand aufgekommen sind, kurze 
Infos. Derzeit bin ich auf dem Stand vom 3. Semester und habe unter 
anderem Vorlesung absolviert in denen die Basics vermittelt wurden, 
welche auf die Embedded Programmierung abzielen...  Programmieren 
(C,C++,Assembler), Algorithmen, Datenstrukturen, Mikroprozessorsysteme, 
Rechnerarchitektur, Betriebssysteme, usw.

Nochmals danke an alle, echt super nett von euch !

Autor: ./. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du mit NXP anfangen willst, solltest Du Dir vielleicht
auch mal:

Ebay-Artikel Nr. 182181945201

ansehen. Ein passendes Display (3.5") gibt/gab es dort auch.

Der 1768 ist der Superset-M3 von NXP. D.h. alles was an
Peripheriemodulen innerhalb der Serie vorhanden ist, ist
auch beim 1768 dabei.

Sehr zu empfehlen dazu waere ein J-Link. Enweder als
Edu-Version oder in schwarz vom Chinesen :-).

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein STM32F0 Discovery (Cortex-M0) gibt es zur Zeit für 5€ + 2,90€ 
Versand bei eBay:
Ebay-Artikel Nr. 311646653104
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.

Autor: Christian B. (casandro) Flattr this
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: *./* (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Wenn du in ASM mal reinschauen willst dann lass deinen c-code einfach 
mal in ASM source übersetzen.
Du wirst dann sehr schnell drauf kommen das du nicht in ASM 
programmieren willst.
ASM hilft dir dabei zu verstehen wie die CPU funktioniert. Wenn du C 
programmierst ist es schon gut wenn du verstehst wie die CPU 
funktioniert.
Du solltest schon wissen ob eine Variable am Stack oder im RAM ist. Was 
ein Register ist. Was eine Adresse und der Inhalt ist. Es ist aber nicht 
notwendig die ganzen AMS Befehle zu kennen.
Um gute C++ Programme zu schreiben brauchst du kein ASM sondern musst 
wissen wie man objektorientiert programmiert und keinen Spaghetti Code 
produziert.

Autor: Daniel A. (daniel-a)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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)

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich habe zuerst Assembler gelernt, dann Pascal, dann C und danach noch 
einige weitere Sprachen.

Ich denke nicht, dass man zuerst Assembler lernen soll. Das schreckt nur 
ab. Bei mir hat es sich aufgrund der Rahmenbedingungen (C64) so ergeben. 
Da hatte man zu meiner Zeit nur die Wahl, ein unbrauchbares Basic zu 
verwenden oder manuell zu assemblieren.

Aber wir haben heute keine C64er mehr auf dem Tisch stehen. Selbst ein 
Arduino Modul ist wesentlich fortgeschrittener, was die Programmierung 
angeht. Und das darf man auch gerne nutzen, finde ich.

Erst nachdem man ein bisschen Programmiererfahrung gesammelt hat, halte 
ich es für empfehlenswert, ein kleines bisschen Assembler zu lernen.

: Bearbeitet durch User
Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kauf dir das XMC2GO für 7 € hat alles drauf was du brauchst: 
(ARM-Cortex-M0, Debugschnittstelle stronversorgung)

http://shop.myavr.de/Hardware/XMC%202Go%20(KIT_XMC...

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: axe (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
An der Uni fangen die im ersten Semester nicht umsonst mit SML an.
Diese Denkweise der funktionalen Programmierung ist wirklich eines der 
wichtigsten Dinge die ein Programmierer lernen soll. Wenn du also gut 
Programmieren lernen willst dann beginne nicht mit Assembler sondern mit 
SML.

Autor: DoctorKnowItAll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uni iss ja auch praxisfremder Akademikerscheiß

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
axe schrieb:
> An der Uni fangen die im ersten Semester nicht umsonst mit SML an.
> Diese Denkweise der funktionalen Programmierung ist wirklich eines der
> wichtigsten Dinge die ein Programmierer lernen soll. Wenn du also gut
> Programmieren lernen willst dann beginne nicht mit Assembler sondern mit
> SML.

DoctorKnowItAll schrieb:
> Uni iss ja auch praxisfremder Akademikerscheiß

Genau, an der Uni lernt wird ja auch nicht "Programmierung" gelehrt 
sondern "Informatick". Programmieren muss man sich selber beibringen, 
bspw. durch embedded Hobbyprojekte auf mikrocontroller.net.

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
axe schrieb:
> An der Uni fangen die im ersten Semester nicht umsonst mit SML an.
> Diese Denkweise der funktionalen Programmierung ist wirklich eines der
> wichtigsten Dinge die ein Programmierer lernen soll. Wenn du also gut
> Programmieren lernen willst dann beginne nicht mit Assembler sondern mit
> SML.

Ein Schwachsinn, echt... :-D Der Prof gehört gefeuert!

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

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

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Youtube-Video "Nein! - Doch! - Ohh!"

: Bearbeitet durch User
Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Christopher J. schrieb:
> weil C++ nur unnötige Komplexität rein bringt
> und zusätzliche Ressourcen frisst

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.

Fazit: Ein sehr guter C++-Entwickler bekommt Lösungen hin, die weder 
langsamer noch größer sind als gleichwertige Lösungen eines guten 
C-Entwicklers. Ein sehr guter C++-Entwickler kostet aber mehr als ein 
guter C-Entwickler, weil sehr gute Entwickler immer teurer sind als 
gute.

Und zum Thema GUIs: Die hat man auf Mikrocontrollern normalerweise 
nicht. Kein einziges der Projekte, die ich beruflich je macht habe, 
hatte überhaupt ein Display. Die wurden gemacht, um irgendwo eingebaut 
zu werden und dann autonom ihren Dienst zu tun.

Wenn man embedded programmieren lernen will, ist C++ jedenfalls IMO 
definitiv falsch, gerade weil es mehr abstrahiert - und damit gerade die 
Themenbereiche wegabstrahiert, über die man etwas lernen will.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)
>
> Youtube-Video "Nein! - Doch! - Ohh!"

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.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: DoctorKnowItAll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GUIs macht man in python als webinterface damit die Leute ihre 
Smart-Devices über Handy steuern können.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß.

Autor: Sheeva P. (sheevaplug)
Datum:

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

Flask rult! ;-)

Autor: Danish B. (danishbelal)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Das Bild passt einfach perfekt.
Aber bitte nicht falsch verstehen.

Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Und dann sollte man sich auch noch überlegen, daß OOP kein Allheilmittel 
ist und erst recht nicht "besser" als prozedural ist.

Allerdings kann man auch in C objektorientiert programmieren, ich sag 
nur structs mit Funktionszeigern. Einen wirklichen Schub bringt es einem 
aber erst, egal ob C oder C++, wenn man OOP mal loslöst von der Syntax. 
Object.Function() ist schließlich nur syntaktischer Zucker für 
Function(&Object), das reißt keinen vom Hocker.

Beispielsweise in einem RTOS mit verschiedenen Tasks, die kann man 
jeweils für sich als abstrakte Objekte sehen - und die sollten dann 
miteinander über klar definierte Interfaces reden, etwa mit Messages. 
Dann kann man die Arbeit auch gut parallelisieren, weil jeder seinen 
Task gegen die Spec seines Interfaces entwickelt. Zudem ist 
sichergestellt, daß interne Änderungen eines Moduls solange keine 
ungewollten Seiteneffekte haben, wie es seine Außenschnittstelle 
konstant hält. Das ist dann "private/public" in wesentlich größerem 
Maßstab, wo es auch was bringt.

Das geht dann aber in C genausogut.

Man sollte hierbei aber auch grundsätzlich mal sehen, wieso sich neuere 
Methoden als prozedurale Programmierung überhaupt erst entwickelt haben. 
Das war, wie zuvor ja auch die strukturierte Programmierung, eine 
Antwort auf zunehmende Komplexität. Nun ist auf Mikrocontrollern die 
Speichergröße normalerweise so übersichtlich wie auf Rechnern aus der 
Zeit, als prozedurale Programmierung aktuell war. Man wird nunmal keinen 
Clusterservice aus 200 Datenbankservern auf einem Mikrocontrollern 
laufen lassen und braucht daher auch nicht die Ansätze, die dort 
vernünftig sind.

Umgedreht, wenn man mit Ansätzen für solche Anwendungen auf 
Mikrocontroller geht, schießt man mit Kanonen auf Spatzen, und während 
man den Aufwand dann immer noch hat, ist der Nutzen längst nicht so hoch 
wie bei den "großen" Anwendungen.

Autor: F. F. (foldi)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: TheDarkNightRises (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich kann dir ein Entwicklungsboard für den Einstieg empfehlen.
Ich persönlich finde den Intel Edison (mit Arduino Board) genial.

Der Edison ist für Einsteiger und für den Einsatz in End-Produkten in 
kleiner Serie entwickelt und kompatibel zum Arduino.

Die meisten (nicht alle) Arduino Shields können auch beim Edison 
verwendet werden und der Edison lässt sich auch mit der Arduino IDE 
programmieren.

Und trotzdessen läuft auf dem Edison keine geflashte Firmware sondern 
ein komplettes 32-bit (x86) Betriebssystem (Yocto Linux), weshalb er dir 
viel mehr (!) Möglichkeiten und Komfort eröffnet als >nur< der Arduino.

Technisches Datenblatt:
https://cdn-shop.adafruit.com/datasheets/EdisonDatasheet.pdf

(Der eigentliche Intel Edison ist nur das kleine Board unten links 
welches auf das Entwicklungsboard aufgesteckt wird. Das 
Entwicklungsboard ist Open Source. Der Edison ist per irgendwas 
Hirosestecke mit dem Board verbunden und kann auch mit einer eigenen 
Platine verbunden werden)

Als Entwicklungsumgebgung kann eine modifizierte Eclipse IDE oder die 
Arduino IDE dienen.

FAQ (Deutsch - aber mangelhaft übersetzt)
http://www.intel.de/content/www/de/de/support/boar...

Getting started:
https://software.intel.com/en-us/node/544867

https://software.intel.com/en-us/iot/hardware/edis...

Autor: .- (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> Um C zu lernen musst Du aber erst mal ansatzweise Assembler können
Selten So einen Bullshit gehört.

Autor: The DarkNightRises (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> TheDarkNightRises schrieb:
PS: Da du Informatik studiert hast statt Elektrotechnik liegt
Embedded Programmierung auf Betriebssystem Ebene eigentlich auch
näher als auf Hardware Ebene.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DonKanaille schrieb:
> tendiere ich aktuell zu dem LPC1549

Da der Frager sich schon lange für einen ARM entschieden hat ergibt die 
Diskussion nicht mehr viel Sinn ...

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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. :-)

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.) ;-)

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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. :-)

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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. :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.