Mikrocontroller - C oder C++

Wed Feb 17, 2010 10:30 pm   

Am 17.02.2010 21:50, schrieb Johannes Bauer:


Schreibst du immer deinen ganzen Quelltext als inline code? Oder soll
das jetzt nur ein konstruierter Fall aus Rechthaberei sein? Probier das
Ganze bitte nochmal mit einer normalen Methodendeklaration aus, und du
wirst sehen, daß ich für den Regelfall recht habe.


Man kann beim Lesen des Quelltextes (ohne ständigen Seitenblick auf die
Funktionsdekarationen) nicht unterscheiden, ob ein Objekt "by value"
oder "by reference" an eine Funktion übergeben wird, was zu hässlichen
Fehlern führen kann.
Es ist schon hässlich genug, daß C++ drei verschiedene Wege (value,
reference, pointer) der Parameterübergabe erlaubt; daß zwei davon auch
noch (trotz stark unterschiedlicher Semantik) syntaktisch identisch
aussehen, ist einfach Mist.


Na, immerhin.


Jeder fängt mal an. Und bei Microcontroller-Programmierung ist es IMO
nicht zielführend, die Abstraktionsebene gleich zu Anfang so hoch zu
schrauben, daß man den Bezug zur Hardware verliert.
Ein bisschen Übung in Assembler oder Assembler-ähnlich benutztem C ist
für das Verständnis ungemein hilfreich.

Hergen

Wed Feb 17, 2010 10:37 pm   

Am 17.02.2010 21:00, schrieb Klaus Rudolph:

Ein kompletter Zwang zur objectorientierten Programmierung mit Vererbung
und etc. und jedlichen Verbot prozedualer Elemente ist auch nicht schön.
(war ja mal modern als OO gerade in war)

Sicher kann man mit Methoden und etc. viel erreichen aber an bestimmten
Punkten sind Prozeduren auch wichtig.
Nach meiner persönlichen Erfahrung sollte beides gemischt werden.
Das rechte Maß macht es und ein hardcore oo-code ist auch nicht besser
zu lesen. Die Programiersprache ist zweitrangig und OO würde ich bei
kleinen Regelschaltungen nicht einsetzen, da sich hier keine großen
Strukturen ergeben.

Alles was komplexer wird, lässt sich wunderbar in OO nach Außen kapseln.
Ich sehe OO eher als Schnitstellen-Konzept zwischen verschieden
Programmteilen, dann als Programierstil. Bei Allem was in mehreren
Projekten verwendet werden soll, kann man mit OO Nichts falsch machen.
Für eine einmalige Nutzung ist der Aufwand der OO-Kapselung nur
gerechtfertigt, wenn mehrere Personen dauerhaft am Projekt arbeiten.

Ich möchte eigentlich nur ausdrücken: Jeder Stil hat seine Berechtigung
und es muss von Projekt zu Projekt entschieden werden, was wirklich
gebraucht wird.

Wed Feb 17, 2010 10:49 pm   

Klaus Rudolph <lts-rudolph_at_gmx.de> wrote:

Dir ist schon klar, daß das eine ganz andere Aussage ist? Die
Frage ist doch eigentlich, ob ein objektorientierter Ansatz
*besser* ist als ein prozeduraler. Selbstverständlich ist die
Antwort auf diese Frage stark von der gewählten Metrik abhängig.
Aber wir können ja mit

- Größe des Quelltexts
- Verständlichkeit (Wartbarkeit) des Quelltexts
- Verfügbarkeit und Güte von Compiler/Bibliotheken
- Größe des Objektcodes
- Ausführungsgeschwindigkeit

anfangen.

Es gibt leider viel zu viele OO-Spezies, die OO als Selbstzweck
ansehen. Und nicht als Mittel, das man bei Bedarf verwendet.
Oder eben auch nicht.

Und gerade bei dem Kleinkruscht, den man typischerweise in einen
8-Bit-Controller (daher kam die Diskussion ja) reinbrutzelt, ist
OO höchst selten ein echter Vorteil.


Und wieder vergleichst du Äpfel mit Birnen. Es geht nicht um die
Größe des C/C++ Quellcodes, sondern um die Größe des Objektcodes
für funktional vergleichbare Lösungen. Also prozedural in C vs.
objektorientiert in C++. OO in C ist Schwachsinn und prozedural
in C++ ist ja bekanntermaßen kein Problem.


s/immer/manchmal/

meinetwegen sogar s/immer/oft/ - das kommt darauf an, was für
Projekte man üblicherweise bearbeitet.

Das klassiche Gegenbeispiel ist Java. Da führt das aufgezwungene
"du darfst aber nur OO" zu so furchtbaren Verrenkungen wie daß
main() ein static Member einer Dummy-Klasse sein muß. Allein
dafür gehören Gosling & Co an die oberste Rah!


XL

Wed Feb 17, 2010 10:51 pm   

Am 17.02.2010 21:50, schrieb Johannes Bauer:

irgendwie muss jeder anfangen und da ist ein 8-Bit'er und C durchaus
eine Möglichkeit. Warum nicht?
Wenn es später studiert wird, haben dann die Lehrkräfte weniger zu tun
den schlechten Stil abzugewöhnen (am liebsten habe dies ja, wenn der PC
für die Probanten ein Fremdwort ist)?

C bietet durchaus viele Möglichkeiten sowohl positiv, wie auch negativ.
Und gerade Microcontroller-Projekte schränken da etwas ein und sind
heute noch am ehesten zu begreifen (Multimeter, Oszi).
Eine Sprache, die ich nicht spreche vergesse ich. (Basic ist mir zum
Beispiel mitlerweile vollkommen unbekannt)

Wed Feb 17, 2010 11:41 pm   

Am 17.02.2010 20:23, schrieb Joerg Wunsch:
....

Ich mag C-Code auch gerne einem c++-compiler vorwerfen, weil der nicht
nur warnt, sondern sich weigert, den Müll weiter zu übersetzen.

Die Probleme bei µC entstehen aber vorher, wenn man sich fragt, warum
die LED angeht, wenn man "0" ins Register schreibt, über Timer (N oder
N+/-1 oder 65535-(N-1) oder 65535-N?) bis zu Interrupt-Routinen, deren
Variablem immer gleich bleiben, weil man "volatile" vergessen hat,
Stack-overflows und der Unfug mit Fließkomma-arithmetik.

Ich würde jedem Einsteiger empfehlen, am Anfang ein paar Kleinigkeiten
in Assembler zu schreiben.

Wenn man nicht wissen will, was der Controller macht, kann man auch
BASIC verwenden. Aber dann kann man auch gleich in PHP auf dem PC
programmieren ;-)

Falk

Thu Feb 18, 2010 12:32 am   

Am 17.02.2010 16:09, schrieb Michael Maier:

--> ersteres für die Stadt
--> letzteres für den Umzug


Einfache Controllerschaltung für drei Tastern und vier LEDs oder
Touchscreen TFT mit Benutzeroberfläche und Gedöns drumherum.


Butzo

Thu Feb 18, 2010 1:40 am   

Hi,
welchen Compiler dann für C, C++?
RundumSorglos Paket.
Für den Einstieg, gerne mit C++.

Wo kann ich es bestellen?

Grüße Michael

Thu Feb 18, 2010 3:50 am   

Am 17.02.2010 21:00, schrieb Klaus Rudolph:

Seit ich gegen meinen Willen Java programmieren muss (kommt häufiger vor
in der Uni) kann ich OO auch ab und zu verfluchen. Es hat sicher seine
Berechtigung und ein wunderbarer Mix aus prozuduralem und
objecktorientiertem Code ist sehr gut wartbar.

Abgesehen davon, dass ich Gosling wegen diverser Dinge verfluche [1],
gibt es einfach Dinge, die Funktionen sind und keine Methoden. Aus einem
double[] ein double[] machen, z.B. Koordinatentransformation, und zwar
austauschbar.
Ich weigere mich daraus eine ArrayList<Double> zu machen, denn eine Zahl
ist für mich nur mathematisch ein Objekt, ansonsten hat da kein Pointer
zu sein.

Streng OO-Weg:
Eine statische Klasse mit einer statischen Funktion. Braucht nämlich
keinen Konfigurationwert oder sonstiges und somit auch keine Instanz.
Virtuelle Funktionen fallen damit natürlich weg. Eine Wrapperklasse mit
..toXY fühlt sich nicht nach sauberer Programmierung an, die
Wrapperklasse für die Koordinatenliste müsste dann alle
Zielmöglichkeiten kennen.

Mein Lieblingsweg, den ich unter D (sic, D, nicht C) auch so benutze:
Funktionspointer. Schön statisch, keine anonyme Klasse oder ähnlicher
Schmarrn. Nur ein einziger Pointer, keine Instanz, nix. Und wenns doch
mal in eine Instanz gehen soll, kein Problem, D kann auch
Methodenpointer mit implizitem this. Herrlich simpel.

So simpel ist OO-technisch nur eine nicht-vererbte Klasse, von der ich
einen Instanz erzeuge und sie weitergebe. Notfalls anonym. Bloat.

Grüße,
Gian Perrone

P.S.: Falls sich jemand für D interessieren sollte, ich hab noch
irgendwo Folien von mir von nem Vortrag darüber. Leider noch nicht
μC-tauglich, das gcc-Frontend ist relativ veraltet. Aber für Desktops
hochinteressante Programmiersprache.

[1] Es gibt kein unsigned, weil die meisten das eh nicht verstehen. Den
Code den ich fabriziere um doch unsigned zu rechnen, versteht mit
Sicherheit keiner, der das nicht auch mal machen musste. Operator
Overloading ist nicht drin, weil man das missbrauchen kann. Zitat
Gosling: "as a fairly personal choice" Ich finde 1) op1.equals(op2) sehr
schlecht lesbar (op1 und op2 sind nicht gleichberechtigt), 2) vergisst
man das auch gerne mal und vergleicht die Pointer (was dann bei kleinen
Zahlen auch noch klappt...), 3) kann man auch in .equals genau so viel
Mist machen wie in op==

Thu Feb 18, 2010 10:06 am   

buchty_at_atbode100.lrr.in.tum.de (Rainer Buchty) writes:


Kann ich nicht bestätigen. Wenn man C in Assembler übersetzt, ist man
vom resultierenden Code normalerweise in keinster Weise überrascht (wenn
wir nicht gerade makrointensiv geschrieben haben oder die 5000
Operatorpräzedenzen dafür genutzt haben, Klammern zu sparen). Das sieht
bei C++ wieder ganz anders aus.


Das Hauptproblem von C als "Hochsprache" ist die Abwesenheit eines
echten Arraytyps. Das führt zum einen dazu, daß der Compiler sich oft
nicht zu optimieren trauen kann, weil Pointer überallhin zeigen könnten
(wenn man nicht mit ganz modernen keywords wie "restrict" hantiert, die
keiner verstehen und anwenden kann). Zum anderen sind Funktionen auf
mehrdimensionalen Arrays nur mit expliziter Indexarithmetik, oder aber
grauenvoll ineffizient zu schreiben. C99 und Konsorten haben da noch
Nachträge geliefert, aber das interessiert eine Menge alter Compiler
nicht, und auch eine Menge alter Hasen. Die genialen Mathematiker, die
Numerikbibliotheken schreiben, sind schon alle tot und ihr Vermächtnis
ist nur in Fortran sinnvoll zu gebrauchen.

Man sehe sich mal an, was "Numerical Recipes in C" für Katastrophen bei
den Arraykonventionen veranstaltet. Grau-en-haft. Und natürlich mit
nichts anderem kompatibel.


Naja, C ist eigentlich recht übersichtlich. Aber es ist halt keine
Sprache zur Massenverarbeitung von Daten, sondern zur Umsetzung von
Kontrollflüssen.

--
David Kastrup

Thu Feb 18, 2010 10:33 am   

Am 18.02.2010 00:40, schrieb Michael Maier:

In deinem Browser.

Wähle die Atmel AVR Microcontroller, gehe auf atmel.com, ziehe Dir das
AVRStudio, gehe dann nach winavr.sourceforge.net und ziehe Dir die
neueste WinAVR Version. Wenn Du einen Rechner mit echter serieller
Schnittstelle hast, kauf Dir bei www.reichelt.de das STK500, das ist
Programmer und Experimentierboard in einem (und es kann im Gegensatz zu
den anderen Lösungen auch High-Voltage Programming, was DU dann
brauchst, wenn Du Dich bei den Fuses vertan hast und der Chip nicht mehr
anläuft), ansonsten einen AVRISP mkii. Damit wärst Du dann komplett.

Notiere Dir dann noch www.mikrocontroller.net und www.avrfreaks.net, wo
Du dann mit weiteren Fragen gut aufgehoben bist.

--
Mit freundlichen Grüßen

Frank-Christian Krügel

Thu Feb 18, 2010 10:46 am   

In article <4b7c64e9$0$6583$9b4e6d93_at_newsspool3.arcor-online.net>,
Stefan Engler <Lehrerfreund_at_web.de> writes:
|>
|> irgendwie muss jeder anfangen und da ist ein 8-Bit'er und C durchaus
|> eine Möglichkeit. Warum nicht?

Weil es den Anfänger verwirrt.

Zu meiner Anfangszeit war BASIC noch das Maß der Einsteiger-Dinge. Für jeden
Rechner verfügbar und rein humansprachlich verständlich. Ein paar Listings
abgetippt, etwas selbst experimentiert und man hatte raus, wie der Hase läuft.

Irgendwann wagte man sich (notgedrungen) an Assembler und wurde so mit seiner
Mühle vertraut -- und lernte, was man tut und was nicht.

Dann kam der C-Hype in den 80ern. Und einer der größten Fehler, den man damals
tun konnte, war, C als Hochsprache zu verkaufen, denn die meiste Zeit verbringt
man in C eben doch damit, Pointer durch die Gegend zu schubsen sowie System-
bzw. Bibliotheksaufrufe zu verinnerlichen.

Einsteiger sind daher mit dem *Gesamt*feld, das C aufmacht, gerne überfordert.

|> Eine Sprache, die ich nicht spreche vergesse ich. (Basic ist mir zum
|> Beispiel mitlerweile vollkommen unbekannt)

*Das* BASIC gab's eh nie, von daher kannst Du ohnehin nur im jeweiligen
Hausdialekt eingerostet sein. Und der ist, sofern's nicht VisualBASIC war,
vermutlich hinreichend ausgestorben.

Rainer

Thu Feb 18, 2010 2:55 pm   

In article <87d4026hha.fsf_at_lola.goethe.zz>,
David Kastrup <dak_at_gnu.org> writes:
|>
|> Kann ich nicht bestätigen. Wenn man C in Assembler übersetzt, ist man
|> vom resultierenden Code normalerweise in keinster Weise überrascht (wenn
|> wir nicht gerade makrointensiv geschrieben haben oder die 5000
|> Operatorpräzedenzen dafür genutzt haben, Klammern zu sparen).

Da stimme ich Dir ja unumwunden zu, aber wir reden hier ja gerade vom
Einsteiger.

Der, der erst mal ein schnelles Erfolgserlebnis haben will, so wie das
früher mit BASIC auf den diversen Homecomputern durchaus machbar war.

Da haben die von anderen angeführten Interpretersprachen wie z.B. PHP
oder Python m.E. einen echten Vorteil.

|> > Einsteiger sind daher mit dem *Gesamt*feld, das C aufmacht, gerne
|> > überfordert.
|>
|> Naja, C ist eigentlich recht übersichtlich. Aber es ist halt keine
|> Sprache zur Massenverarbeitung von Daten, sondern zur Umsetzung von
|> Kontrollflüssen.

Drum schrieb ich: das Gesamtfeld.

C als Sprache ist sicher nicht schwerer oder leichter als jede andere
prozedurale Sprache auch. In meinen Augen sogar angenehmer als z.B.
Pascal, weil sie der natürlichen Faulheit des Menschen nachkommt.

Rainer

Thu Feb 18, 2010 5:11 pm   

Hallo,
ok
Danke.
http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=A38;GROUPID=2969;ARTICLE=34093;START=0;SORT=artnr;OFFSET=16;SID=31Vj9Lj6wQAR8AAHg5RcIfd33090b545b3613a49bc97344b89378

Brauche ich noch etwas? Spannungsversorgung etc....?

Danke.

Grüße Michael

Thu Feb 18, 2010 5:16 pm   

On Thu, 18 Feb 2010 07:11:43 -0800, Michael Maier wrote:


Ja. Die Hohlsteckerbuchse auf dem Board will gefüttert werden.
Reichelt schlägt vor:
MW 9112-GS, Tisch-Netzgerät, stabilisiert, 1200mA, 9,95 EUR.

---<(kaimartin)>---
--
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53

Thu Feb 18, 2010 5:30 pm   

Johannes Bauer <dfnsonfsduifb_at_gmx.de> schrieb:


Welchen Mikrocontroller setzt Du denn da ein?


Wenn ich Dich recht verstanden habe, soll Deiner Meinung nach ein
Anfänger morgens gleich im Bett bleiben, da er bereits das Zähneputzen
ohne entsprechenden Lehrgang nicht bewältigen könnte.