Mikrocontroller - C oder C++

Z.B. Größe des Controller RAM/Flash C++ Compilate sind i.d.R. größer C geht mit Einschränkungen schon aber 8051 mit internem RAM.

Für kleinere und einfachere Sachen ist BASIC sicher geeignet, zumal bei BASCOM schon viele Routinen, z.B. HD44780-LCD-Ansteuerung eingebaut sind. Die Demo-Version ist für viele Sachen ausreichend. Störend ist vielleicht, daß man wenig Einfluß auf die Codegenerierung hat, was z.B. bei zeitkritischen ISRs wichtig ist.

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.

Zahllose:

1. Mit welcher Programmiersprache bist Du besser vertraut?
2. Für welche Programmiersprache gibt es Compiler und Libraries?
3. (Speziell C vs. C++): ist das Problem objekt-basiert?
4. Wie groß ist der resultierende Binärcode? :

Josef

--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef Möllers (Pinguinpfleger bei FTS)
	If failure had no penalty success would not be a prize (T.  Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html

Am 17.02.2010 16:09, schrieb Michael Maier:

Sollte das jetzt eine Frage sein oder Werbung für den Kurs?

Hängt vom Projekt ab. Objektorientierte Programmierung bietet nur dort signifikante Vorteile, wo man es auch mit Objekten zu tun hat, sprich: ähnliche und/oder aufeinander aufbauende Datenstrukturen in mehrfachen Instanzen vorkommen. Gleichzeitig verursacht C++ je nach Controller einen mitunter massiven Overhead.

Einem Anfänger (der nicht abschätzen kann, was der Compiler im Hintergrund an Verrenkungen anstellen muss) würde ich eher zu klassischem C raten, ganz besonders auf einfachen 8Bit-Controllern.

Möglicherweise nützlich zum Experimentieren und für die schnelle Prototypenentwicklung. Für ernsthaften Produktiveinsatz (oder zum Lernen mit dem Ziel, das Wissen später beruflich einzusetzen) ist sowas aber IMO eher nicht geeignet, schon deshalb, weil nur wenige Hardwareplattformen unterstützt werden.

Hergen

Da du nun schon der zweite bist, der das behauptet: nein, das stimmt (so) nicht. Wenn man C++ nur als "C mit strengerer Typkontrolle" benutzt, also ohne jegliche OO-Features, dann gibt es keinen Grund, warum ein C++-Compiler anderen Code als ein C-Compiler erzeugen sollte.

Anders sieht das natürlich bei der Benutzung der OO-Features aus, aber dann wäre auch der entsprechende C-Code deutlich größer und zusätzlich noch viel unübersichtlicher.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Es gäbe sogar noch Controller mit FORTH ...

MfG JRD

Am 17.02.2010 17:29, schrieb Joerg Wunsch:

man "indirekte Adressierung". Bei C merkt man, wenn man sowas macht, bei C++ passiert es implizit, sobald man auf Objekte zugreift - und so werden aus einer simplen Zuweisung an eine Membervariable mal eben (je nach Controller) mehrere dutzend Byte Code. Besonders für einen Anfänger eine ganz böse Falle.

Wenn man keinerlei OO-Features benutzt, macht ein C++-Compiler wenig Sinn. Ausreichende Typsicherheit bietet auch bereits ein Ansi C Compiler, sofern man die Warnungen beachtet und nicht abschaltet...

Hergen

Da muss man aber teilweise sehr aufpassen. Wir haben in unserem Projekt z.B. ein Modul "wlocale.o" aus der C++-Standardbibliothek drin, knapp

50k Code, vermutlich von irgendeinem Teil der iostreams reingezogen.

In C++ ist es halt kniffliger als in C, Bloat zu vermeiden.

Stefan

Hergen Lehmann schrieb:

Man kann sehrwohl eine Klasse statisch instanziieren (auf einem uC will man ohnehin kein new haben), womit dein Einwand natürlich flach fällt.

Template Metaprogramming geht mit einem ANSI C Compiler nicht. Referenzen kennt ein ANSI C Compiler nicht. Zugriffsschutz auf Member von structs ist mit einem ANSI C Compiler nicht zu machen.

C++ ist halt doch mehr als "C mit Klassen". Und man kann Features der Sprache auch auf uC ausgezeichnet einsetzen.

Gruß, Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa

Hergen Lehmann schrieb:

...und das stimmt natürlich auch nicht:

enum foo { A = 1, B = 2, C = 3 };

int main() { enum foo x; x = 2; return x; }

joe [~/tmp]: gcc -ansi -pedantic -Wall -Wextra -O2 x.c joe [~/tmp]: g++ -ansi -pedantic -Wall -Wextra -O2 x.c x.c: In function »int main()«: x.c:5: Fehler: ungültige Umwandlung von »int« in »foo«

Gruß, Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa

Stefan Reuther schrieb:

Für die kleinen Controller erübrigt sich das, weil die Bibliothek sowas gar nicht erst hat. ;-)

Wenn man als normaler C-Programmierer an C++ herangeht, benutzt man all den Kram, der gefährlich werden könnte bezüglich Bloat, gleich gar nicht. Wenn man natürlich als geübter C++-Programmierer aus einer Umgebung kommt, in der C++ für diverse Fensterläden (damit meine ich nicht nur MS-Windows, sondern auch solche Kolosse wie Qt) benutzt wird, und dann versucht, mit ähnlichen Methoden einen Controller zu programmieren, dann gebe ich dir allerdings Recht.

Es gibt eigentlich nur einen Grund, /nicht/ gleich mit C++ anzufangen (wenn man sowieso neu einsteigt): es kursiert sehr viel Sourcecode im Internet, der in so hinreichend schlampigem C geschrieben ist, dass man erstmal viel Mühe hineinstecken müsste, bevor man den durch die Typprüfungen eines C++-Compilers geprügelt bekommt. Gerade als Anfänger freut man sich jedoch über Codebeispiele, die man einfach erstmal nachnutzen kann.

C++ bietet übrigens außer der strengeren Typprüfung noch einen weiteren Vorteil: echte Konstanten. Dafür gibt's auch zumindest ein nettes C99-Feature, das C++ nicht kann: die Initialisierung von Feldern oder Strukturen über benannte Elemente. Dafür kann man das in C++ durch überladene Konstruktoren erledigen, wenn's sein muss.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Am 17.02.2010 20:04, schrieb Johannes Bauer:

Tja, damit wärst du dann voll in die Falle getappt. Wenn du die *Klasse* statisch instanzierst, wird der Compiler trotzdem fleissig Overhead mit indirekter Adressierung und this-Zeiger produzieren, denn beim Compilieren der Methoden kann er nicht wissen, ob es zur Laufzeit bei einer einzigen Instanz bleiben wird.

Wenn du diesen Overhead vermeiden willst, müsstest du schon jede Membervariable einzeln als "static" deklarieren.

Das wenige, was da ohne OO sinnvoll ist, kann man in der Regel auch mit Makros realisieren. Vielleicht etwas unübersichtlicher, aber weniger tückisch in Hinsicht auf das, was hinten aus dem Compiler herausfällt.

Die sind ohnehin gefährlich und umstritten...

Da man zur Vermeidung von OO-Overhead ohnehin alle Member als static deklarieren müsste, kann man genauso gut auch klassiche, modullokale Variablen verwenden. Die haben nebenbei den Vorteil, daß man sie nicht ungewollt (per .h-File) publiziert.

Zweifellos. Man sollte aber genau wissen, welche Konstrukte was hinter sich her ziehen, sonst tappt man in nullkommanix in die Bloat-Falle.

Ich bleibe dabei: Einem Anfänger würde ich abraten, zumindest auf einem

8-Bitter.

Hergen

Ich kenne eigentlich kein Programmierproblem, welches nicht sinnvoll in objektorientierter Programmierung zu lösen wäre. Objekte gibt es immer und überall, vielleicht muß man sie einfach nur sehen.

Und weil das eben so ist, empfinde ich es sehr hilfreich auch objektorientiert zu programmieren. Das geht aber auch in C oder gar in Assembler. Natürlich gibt es da keine netten Sprach-Features aber zumindest die Objekte lassen sich gut auch in "niedrigeren" Programmiersprachen repräsentieren.

Das C++ Code prinzipiell größer wird ist ein Märchen. Und nach meiner Erfahrung wird komplexere Software deutlich kleiner, wenn man objektorientiert programmiert. Zum Beispiel sind dutzende Wiederholungen von wilden Switch/case Bäumen auf "wilde Datenstrukturen" immer viel schlechter als ein einmal oder doppelt zu dereferenzierender Pointer. (Bei Nachbildung der vtable und virtueller Methoden sind es dann ja 2). Insofern ist meine Erfahrung, daß gerade die Nutzung von OO-Features eine deutliche Laufzeitverbesserung und deutliche Codegrößenreduzierung mit sich bringt.

Auch die deutlich bessere Wartbarkeit macht aus meiner Erfahrung heraus einen objektorientierten Ansatz immer lohnenswert. Die Programmiersprache an sich ist da nicht so entscheidend.

Das Schlimmste was aber passieren kann, ist C++ Sprachmittel einzusetzen um eigentlich im Kopf C zu programmieren, das wird dann groß und kompliziert und grausam zu lesen. Und nach meiner Erfahrung ist das schon eher die Regel denn die Ausnahme :-)

Es geht gut in Assembler. Es geht nicht in C++, weil C++ keinen eigenen Control Flow für Objekte hat. Was mithin das wichtigste ist, weswegen Smalltalk als "Object Oriented" bezeichnet wurde.

Ohne ein Sprachkonstrukt, mit dem man Stacks austauschen kann, wie natürlich in Assembler möglich, ist kein Message Passing orientierter Kontrollfluß möglich.

--
David Kastrup

Hergen Lehmann schrieb:

Hast du dir das generierte Assembly schon mal angesehen? Ich nehme dir das ab:

class foo { private: int a; public: void seta(int x) { a = x; } int geta() { return a; } };

foo x;

int main() { x.seta(0x1234); return x.geta(); }

gibt nach g++ -O2:

0000000000400590 : 400590: b8 34 12 00 00 mov $0x1234,%eax 400595: c7 05 8d 0a 20 00 34 movl $0x1234,0x200a8d(%rip) # 60102c 40059c: 12 00 00 40059f: c3

Die Struktur wird völlig reduziert. Keine indirekte Addressierung. Lediglich eine Verallgemeinerung, die *du* getroffen hast.

Unsinn.

Turing-Vollständigkeit sagt dir was? Static Assertions? Möchte ich mal mit Makros sehen.

Ähm, ist das dein Ernst? Gefährlich? Umstritten? Wow! Kannst du das ausführen?

S.o.

Dem stimme ich zu.

Und ich erweitere: Einem Anfänger würde ich auch von C abraten. Und von Mikrocontroller-Programmierung allgemein. Von Programmierung allgemein sogar.

Gruß, Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa

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

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.

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

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)

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