Mikrocontroller - C oder C++

Wed Feb 17, 2010 5:09 pm   

http://et-tutorials.de/632/kostenloser-mikrocontroller-kurs/

Hallo,
wann nimmt man C oder besser C++?


Was gibt es für Kriterien?

Oder
http://de.wikipedia.org/wiki/BASCOM

Michael

Wed Feb 17, 2010 5:09 pm   

Michael Maier <MichMaier_at_discardmail.com> wrote:

C++ Compilate sind i.d.R. größer
C geht mit Einschränkungen schon aber 8051 mit internem RAM.


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_at_rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.

Wed Feb 17, 2010 5:09 pm   

Michael Maier wrote:

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

Wed Feb 17, 2010 5:09 pm   

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

Wed Feb 17, 2010 5:44 pm   

beigestellte industrieübliche HighLevelLanguage
die "95%" verwenden.
Nachteil für Hobby/Gelegenheitsanwender: mühsam
erlernbar.
Die einfacheren "5%" Varianten BASIC / FORTH
sind nur für wenige Controller in brauchbarer
Form vefügbar weil einfach zu wenig Nachfrage
existiert.
Zudem kommt man auf 8 Bit CPU nicht wirklich
dauerhaft an Assembler vorbei. Rein vom
Lerneffekt her ist es wohl auch zweckmässig
erst ein paar Miniprogramme in Assembler zu
schreiben und dann erst auf HLL überzugehen.

MfG JRD

Wed Feb 17, 2010 6:29 pm   

Hergen Lehmann <hlehmann.expires.12-09_at_snafu.de> wrote:


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.

Wed Feb 17, 2010 6:37 pm   

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

Wed Feb 17, 2010 7:18 pm   

Joerg Wunsch wrote:

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

Wed Feb 17, 2010 8:04 pm   

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

--

Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1_at_speranza.aioe.org>

Wed Feb 17, 2010 8:08 pm   

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

--

Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1_at_speranza.aioe.org>

Wed Feb 17, 2010 8:28 pm   

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

Wed Feb 17, 2010 9:00 pm   

Joerg Wunsch schrieb:

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

Wed Feb 17, 2010 9:23 pm   

Stefan Reuther <stefan.news_at_arcor.de> 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.

Wed Feb 17, 2010 9:28 pm   

Klaus Rudolph <lts-rudolph_at_gmx.de> writes:


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

Wed Feb 17, 2010 9:50 pm   

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 <main>:
400590: b8 34 12 00 00 mov $0x1234,%eax
400595: c7 05 8d 0a 20 00 34 movl $0x1234,0x200a8d(%rip) #
60102c <x>
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

--

Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1_at_speranza.aioe.org>