mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welchen Controller für C++ Programmierung?


Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen, ich beschäftige mich seit einiger Zeit mit C++ 
Programierung am PC, habe nun auch Interesse an der Programmierung von 
Mikrocontrollern bekommen. Ich möchte vorerst mit einem Controller alles 
machen können was im AVR Assembler Tutorial auch gemacht wird, also 
Taster, LEDs, Displays usw. usf. Später will ich auch Motoren damit 
ansteuern können, ist ja mit Controllern alles kein Problem. Allerdings 
möchte ich bei C++ bleiben, auch wenn das bedeutet, dass es 
komplizierter wird einen Controller zu programmieren (weil die 
Architektur komplizierter ist?).

Welchen Controller + IDE + Compiler könnt ihr mir empfehlen? Der 
Controller sollte Steckbretttauglich sein. Es wäre auch noch gut so 
etwas wie C++ Lessons dafür zu haben mit Beispielen, gibts ja bei zB PIC 
nur halt in C.

: Gesperrt durch Moderator
Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven schrieb:
> Allerdings
> möchte ich bei C++ bleiben, auch wenn das bedeutet, dass es
> komplizierter wird einen Controller zu programmieren (weil die
> Architektur komplizierter ist?).

nein, du kannst auch einfach einen AVR in C++ Programmieren.

Autor: Atomix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR Studio + Atmel (8bit/32bit)

Cocox + STM32

Codecomposer (Eclipse) + MSP430xxxx

Autor: Timmo H. (masterfx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
C++ hat aber nur einen begrenzten Funktionsumfang auf dem avr (und das 
ist auch gut so)

Autor: Hannes J. (pnuebergang)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Keinen. Programmiere µCs in C und fertig.

Es gibt eine Minderheitengruppe von C++-Programmierern, die unbedingt 
auf C++ besteht - meist weil sie C nicht können oder die Möglichkeiten 
von C++ auf Mikrocontrollern überschätzen. (Die werden gleich hier 
aufschlagen und einen Riesenwind machen).

Bei diesen C++-Programmierern auf µCs stellt sich schnell raus, dass sie 
keine der wirklich wichtigen Features von C++ im Vergleich zu C nutzen. 
Es wird typischerweise in C++ programmiert als ob es C ist. Genutzt 
werden C++-Features die man bestenfalls als Syntaktischen-Zucker 
bezeichnen kann. Ganz nett, aber in keinster Weise missionsentscheidend. 
(Das wirst du an den unwichtigen Codeausschnitten sehen, mit denen die 
C++-Fraktion ihre Überlegenheit demonstrieren möchte. Trivialer Scheiß).

: Bearbeitet durch User
Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven schrieb:

> Welchen Controller + IDE + Compiler könnt ihr mir empfehlen? Der
> Controller sollte Steckbretttauglich sein. Es wäre auch noch gut so
> etwas wie C++ Lessons dafür zu haben mit Beispielen, gibts ja bei zB PIC
> nur halt in C.

Für PIC32 unterstützt Microchip auch C++. Und die PIC32MX1xx/2xx gibts 
auch im SDIP28.

fchk

Autor: Peter II (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hannes Jaeger schrieb:
> Bei diesen C++-Programmierern auf µCs stellt sich schnell raus, dass sie
> keine der wirklich wichtigen Features von C++ im Vergleich zu C nutzen.

Defaultparameter und überladenen Funktion finde ich ganz praktisch. 
Warum sollte man darauf verzichten wenn es keine Nachteile hat? Auch die 
Möglichkeit etwas per Referenz zu übergeben ist oft lesbarer als per 
Zeiger zu arbeiten.

Ja es ist am ende nur "Syntaktischen-Zucker" aber sehr angenehm.

Autor: A. H. (ah8)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hannes Jaeger schrieb:
> Keinen. Programmiere µCs in C und fertig.
>
> Es gibt eine Minderheitengruppe von C++-Programmierern, die unbedingt
> auf C++ besteht - meist weil sie C nicht können oder die Möglichkeiten
> von C++ auf Mikrocontrollern überschätzen. (Die werden gleich hier
> aufschlagen und einen Riesenwind machen).

Und dann gibt es da noch eine (Minderheiten-?) Gruppe, die unbedingt auf 
C besteht. Grundsätzlich gilt: Für jeden Zweck das richtige Messer! C++ 
bietet sehr wohl Features, die C nicht hat. Wenn Du die nutzt, nimm C++, 
wenn nicht, nimm C.

Übrigens bin ich davon überzeugt, dass mehr Programmierer für C sind, 
weil sie C++ nicht beherrschen als umgekehrt, denn wer C++ beherrscht 
sollte trivialerweise auch C beherrschen, schließlich ist C eine 
Untermenge von C++. :-)

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

Bewertung
0 lesenswert
nicht lesenswert
Hannes Jaeger schrieb:
> Es wird typischerweise in C++ programmiert als ob es C ist. Genutzt
> werden C++-Features die man bestenfalls als Syntaktischen-Zucker
> bezeichnen kann.

Tjs, was der Bauer nicht kennt, ...  :-(((

A. H. schrieb:
> mehr Programmiere für C sind,
> weil sie C++ nicht beherrschen

So sieht es leider aus und es gibt viele unnötige Fehler in Programmen 
und schreckliche Designs.

@Sven
C++ beinhaltet viele unterschiedliche Features, welche möchtest du davon 
überhaupt nutzen?

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hannes Jaeger schrieb:
> Bei diesen C++-Programmierern auf µCs stellt sich schnell raus, dass sie
> keine der wirklich wichtigen Features von C++ im Vergleich zu C nutzen.
> Es wird typischerweise in C++ programmiert als ob es C ist. Genutzt
> werden C++-Features die man bestenfalls als Syntaktischen-Zucker
> bezeichnen kann. Ganz nett, aber in keinster Weise missionsentscheidend.

Nun mußt du nur noch erklären, welchen Vorteil es hat, wenn man sich 
dazu zwingt, auf diesen syntaktischen Zucker zu verzichten.

Autor: Ulrich F. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hannes Jaeger schrieb:
> (Die werden gleich hier
> aufschlagen und einen Riesenwind machen).

Anwesend!

Riesen Wirbel: Nimm einen Arduino!

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die bisherigen Beiträge.

Bei C++ will ich eigentlich nur bleiben, weil ich gerade dabei bin C++ 
zu lernen, ich schätze mich als minimal fortgeschrittenen Anfänger ein. 
Ich nutze das Buch "Einführung in die Programierung mit C++ - Bjarne 
Stroustrup".

Stroustrup schreibt, dass das lernen von C als erste Sprache zu einem 
schlechten Programmierstil führt, keine Ahnung was er im Detail damit 
meint, aber er wird es wissen müssen.

Er zeigt in einem sepparaten Kapitel die Features auf die in C im 
Gegensatz zu C++ fehlen und wie man diese (so denke ich) kompensiert, 
also statt zB Klassen und Memberfunktionen soll man "struct" und globale 
Funktionen nutzen.

Ups jetzt ist mein Kommentar doch etwas länger geworden.

Autor: Ulrich F. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich denke C++ wurde aus 2 Gründen erfunden:
1. damals eine Modeerscheinung
2. um größere Projekte in den Griff zu bekommen.

Und ja, ich stimme dem zu!
Der Wechsel von der funktionalen Sichtweise auf die OOP ist nicht 
leicht.
Man muss sich erst das falsch gelernte wieder aus dem Schädel kloppen.
Gelingt das nicht, pervertiert das OOP Vorhaben.

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sven,
ich würde als Compiler den GCC nehmen. Der läuft auf jedem 
Betriebssystem und unterstützt die neusten C++ Standards.

Bei einem Controller würde ich mich an einem ARM orientieren, da es dort 
von fast allen Herstellern startup code für den GCC gibt (CMSIS). 
Lesbare Dokumentation für den Microcontroller ist auch ein Kriterium, 
nach dem man zum Einstieg den Controller auswählen kann und das 
Vorhandensein von Eval Boards. Vielleicht ein STM32 auf keinen Fall ein 
XMC.

Ich bin ja ein Fan von make/gcc plus Editor. Von daher keine 
IDE-Empfehlung von mir ;-)

mfg Torsten

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten, ich habe mir den STM32 Artikel angesehen, das sieht sehr 
interessant aus, sagt mir sehr zu. Ich werde mich da gründlich einlesen 
müssen, ist ein großer Artikel mit Unterartikeln.

Hallo Frank, danke auch für deinen Hinweis mit den PIC32.

Ich werde mir jetzt mal in Ruhe beide Typen ansehen müssen und dann eine 
Entscheidung treffen. Und an alle Anderen auch vielen Dank für die 
vielen Infos.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mich noch auf die schnelle interessieren würde bevor ich anfange 
mich tief einzulesen, was ist denn der Hauptunterschied zwischen den 
STM32 und PIC32? Leistungstechnisch scheinen sie ähnlich, beide können 
mit C++ programmiert werden, Starterkits sind ähnlich (Touch, TFT, USB 
...)

Autor: Sebastian V. (sebi_s)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Sven schrieb:
> Stroustrup schreibt, dass das lernen von C als erste Sprache zu einem
> schlechten Programmierstil führt, keine Ahnung was er im Detail damit
> meint, aber er wird es wissen müssen.

Ich finde seine Meinung zwar etwas extrem, kann ihm aber in Teilen 
zustimmen. Als Beispiel seien mal Operationen mit Strings genannt. In C 
hat man dort toll strcpy, strcat, sprintf und Konsorten welche 
sicherlich für einen Großteil von Buffer Overflows und Sicherheitslücken 
in C Programmen zuständig sind. In C++ nimmt man einfach std::string (ja 
ist für µC vielleicht nicht unbedingt zu empfehlen) und damit kann man 
eigentlich keinen Buffer Overflow erzeugen. Eingefleischte C 
Programmierer werden aber kaum von sowas wie std::string zu überzeugen 
sein weil strcat hat man ja schon immer benutzt. Genauso Speicher 
reservieren. Wozu braucht man dieses neumodische std::vector wenn man 
malloc hat?

Mir persönlich gefällt C++ sehr aber ich muss auch nicht jedes Feature 
auf einem µC nutzen. Außerdem halte ich es für sinnvoll ein 
Grundverständnis von C zu haben, um zu wissen wie die Klassen intern 
arbeiten oder wie man selbst sowas implementiert.

Autor: A. H. (ah8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven schrieb:
> Stroustrup schreibt, dass das lernen von C als erste Sprache zu einem
> schlechten Programmierstil führt, keine Ahnung was er im Detail damit
> meint, aber er wird es wissen müssen.

Er dürfte damit wohl meinen, dass der Mensch ein Gewohnheitstier ist und 
dazu neigt, bekannten Wege zu gehen, selbst wenn es inzwischen bessere 
Alternativen gibt. Mein erstes Pascal-Programm sah auch aus wie Basic 
ohne Zeilennummern. :-) Neue Konzepte zu verstehen kostet eben seine 
Zeit und meistens auch Mühe, die der Mensch gerne vermeidet, wenn er 
kann. Man braucht nicht unbedingt Klassen und Templates, um Probleme zu 
lösen und die Vorteile zeigen sich oft erst auf lange Sicht, manchmal 
gar nicht. Also ist es bequem, sie zu vermeiden und das ist wohl das, 
was er als schlechten Stil beschreibt.

Es gibt allerdings auch das umgekehrte Phänomen: Leute, denen als erstes 
das Programmieren mit Klassen beigebracht wurde neigen nicht selten 
dazu, alles mit Klassen zu lösen, selbst da, wo es gar keinen Sinn 
macht. Das Lernen von C++ ist also noch längst keine Garantie für guten 
Stil! („There never has been nor ever will be a programming language 
were it is at least a bit difficult to write bad code!“)

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven schrieb:
> Was mich noch auf die schnelle interessieren würde bevor ich anfange
> mich tief einzulesen, was ist denn der Hauptunterschied zwischen den
> STM32 und PIC32? Leistungstechnisch scheinen sie ähnlich, beide können
> mit C++ programmiert werden, Starterkits sind ähnlich (Touch, TFT, USB
> ...)

Man korrigiere mich, wenn ich flashc liege, aber ich glaube, der GCC 
unterstützt den PIC32 nicht (ich habe zumindest auf die Schnelle nix in 
der Dokumentation https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/ 
gefunden).

Autor: klausr (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
PIC32 ist MIPS M4K.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klausr schrieb:
> PIC32 ist MIPS M4K

Trotz des Wikipedia Artikels bin ich nicht schlauer geworden. Was 
bedeutet das für mich in der Praxis?

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe es einigermaßen verstanden, DMIPS = MIPS, DMIPS hat die Bezeichnung 
aufgrund eines bestimmten Benchmarkverfahrens. Bleibt nur die Frage was 
schneller ist und ob das überhaupt eine Rolle spielt.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, MIPS ist hier eine Prozessorarchitektur, es geht nicht um 
Performancevergleiche.

https://de.wikipedia.org/wiki/MIPS-Architektur

Autor: Moby A. (moby-project) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. H. schrieb:
> Neue Konzepte zu verstehen kostet eben seine
> Zeit und meistens auch Mühe

Ob ein grösseres Maß an Zeit und Mühe eine Aussage darüber erlaubt, wie 
gut ein Konzept überhaupt ist?

Ulrich F. schrieb:
> Der Wechsel von der funktionalen Sichtweise auf die OOP ist nicht
> leicht.

Muß das denn überhaupt sinnvoll sein?

> Man muss sich erst das falsch gelernte wieder aus dem Schädel kloppen.

Wenn es so gut da drin sitzt, so intuitiv zu erfassen, daß man es sich 
regelrecht aus dem Schädel kloppen muß, wie kann es dann so schrecklich 
falsch sein?

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei dem Titel war es ja nur eine Frage der Zeit bis dieser Spinner 
wieder mal auftaucht...

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby AVR schrieb im Beitrag #4172946:
> Muß das denn überhaupt sinnvoll sein?

Ab einer bestimmten Projektgröße ist es das, sogar sehr.

> ... wie kann es dann so schrecklich falsch sein?

"Falsch" ist vielleicht der falsche Ausdruck. Aber eine rein prozedurale 
Herangehensweise ist schlichtweg nicht der richtige Weg, wenn man ein 
Problem objektorientiert angehen möchte.

Weder das eine, noch das andere ist der Königsweg, aber die Denkweise 
wird stark von beidem beeinflusst und behindert sich oftmals 
gegenseitig.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven schrieb:
> Was mich noch auf die schnelle interessieren würde bevor ich anfange
> mich tief einzulesen, was ist denn der Hauptunterschied zwischen den
> STM32 und PIC32? Leistungstechnisch scheinen sie ähnlich, beide können
> mit C++ programmiert werden, Starterkits sind ähnlich (Touch, TFT, USB
> ...)

Im Prinzip der Prozessorkern. Microchip verwendet hier einen MIPS-Kern, 
weil MIPS (jetzt Imagination Technologies, die mit den PowerVR GPUs, die 
in iPhones etc verwendet werden) geringere Lizenzgebühren verlangt. Auch 
in DSL-Routern und anderen Geräten, wo es nicht auf Binärkompatibilität 
ankommt, steckt MIPS drin.

Für Dich ist es egal. Der Compiler verdeckt die Unterschiede.

Was bei Microchip schön ist: Du bekommst dort alles aus einer Hand: IDE, 
Compiler, Debugger, Bibliotheken, und alles sauber aufeinander 
abgestimmt. Nachteil: Es gibt auch kaum Alternativen, denn anderer 
Hersteller stürzen sich eher auf andere Architekturen, mit denen mehr 
Geld zu verdienen ist. Aber Du bist bei Microchip gut aufgehoben.

Als Bastler hast Du natürlich den Vorteil, dass Du Dir zwar ein Board 
kaufen kannst, es aber nicht musst. Um einen PIC32MX250F128B auf einer 
Lochrasterplatine in Betrieb zu nehmen, brauchst Du im Wesentlichen 10u 
Keramik oder Tantal, zwei 100n Abblockkondensatoren, und 10k an MCLR. 
Das wars, der Rest ist optional. Ist in einer Viertelstunde aufgebaut.

fchk

Autor: Moby A. (moby-project) Benutzerseite
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Hans schrieb:
> dieser Spinner

Nun, Hochsprachenkonzepte sind allesamt ersponnen.
Wenn man dabei die Entsprechung der menschlichen Intuition zum 
Sprachziel macht und nicht etwa irgendeine Eleganz, verpackt in 
phantasievollen, sprachgewaltigen, gedanklichen Winkelzügen, dann 
bedeutet jedes Mehr an aufzubringender Mühe und Zeit eine ganz 
unmittelbare Kontraindikation für die konkrete Sprachauswahl. Dem 
klaren, übersichtlichen unkomplizierte Hardwarekonzept zumindest der 
kleineren 8-Bitter sollte ohne Not keine intransparente, indirekte, 
konzeptüberladene Programmiermethodik aufoktroyiert werden. Außer die 
große Liebe gehört ihr- und nicht der eigentlichen Problemlösung ;-)

Autor: ffff (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Um etwas spass zu haben:

http://www.tux.org/lkml/#ss15

und ich muss ihm zustimmen. Es ist wesentlich leichter in c++ scheiss 
uneffizienten code zu schreiben als in C. einfach weil vieles versteckt 
wird.

@ersteller:
aber es ist überhaupt kein Problem in C++ das ganze zu programmieren, 
musst nur beim programmieren besser aufpasssen

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven schrieb:

> Welchen Controller + IDE + Compiler könnt ihr mir empfehlen? Der
> Controller sollte Steckbretttauglich sein. Es wäre auch noch gut so
> etwas wie C++ Lessons dafür zu haben mit Beispielen, gibts ja bei zB PIC
> nur halt in C.

Mir ist mal gesagt worden das C++ erst durch die eigene dynamische 
Speicherverwaltung (new,delete) Vorteile ausspielen kann. Ebenso würden 
Exceptions die Programmierrei erleichtern.

Kann den das jedes C++ µC System? oder ist nicht erst bei Systeme  mit 
mindestens 16k (??) RAM anfangen dynamische Speicherverwaltung möglich?
Sind die C++ standardbibliotheken für jeden uC ausreichend vollständig 
implementiert um damit wirklich C++ mit seinen Möglichkeiten 
kennenzulernen?

MfG,

Autor: Plus Plus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mobby hat von uC keine Ahnung, er versteht nichts von C un C++ kann er 
überhaupt nicht einordnen. So kennt man ihn zumindest aus dem Forum. :'(

Warum störst du den Thread? Da warten noch ein paar verfusede avr auf 
dich. Du kannst wohl nur trollen. :-(

Autor: cody (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normalerweile braucht/will man kein new/delete auf Mikrocontrollern.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cody schrieb:
> Normalerweile braucht/will man kein new/delete auf Mikrocontrollern.

und auch keine Exceptions

Autor: cody (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Gibt aber auch Features von C++ die gut sind und keinen Overhead haben:
- Templates
- Klassen
- Namespaces

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cody schrieb:
> Gibt aber auch Features von C++ die gut sind und keinen Overhead haben:
> - Templates

Templates können ganz schön overhread erzeugen.

Autor: A. H. (ah8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Mir ist mal gesagt worden das C++ erst durch die eigene dynamische
> Speicherverwaltung (new,delete) Vorteile ausspielen kann. Ebenso würden
> Exceptions die Programmierrei erleichtern.

Das ist sicherlich etwas verkürzt dargestellt. Klassen und Templates 
kann man sicher auch auf einem uC sehr sinnvoll einsetzten. Exceptions 
leider nicht, da das Stack-unwinding für ein uC in der Regel zu komplex 
ist.(Auch stellt sich die Frage, was man auf einem uC mit nicht 
abgefangenen Exceptions macht.)

Die Speicherverwaltung ist nicht Teil der Sprache und new/delete 
lediglich Schnittstellen in die entsprechenden Bibliotheken. Die 
Standard-Speicherverwaltung ist für einen uC in der Tat nur bedingt 
geeignet, man kann aber durchaus eine eigene  Speicherverwaltung bauen, 
die den jeweiligen Anforderungen besser angepasst ist.

Autor: A. H. (ah8)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Peter II schrieb:
> cody schrieb:
>> Gibt aber auch Features von C++ die gut sind und keinen Overhead haben:
>> - Templates
>
> Templates können ganz schön overhread erzeugen.

Templates werden vollständig zur Compile-Zeit ausgewertet, sie können 
also auf dem uC gar keinen Overhead erzeugen, allenfalls der durch sie 
generierte Code. Der hängt aber davon ab, wie ich die Templates 
einsetzte und wofür.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. H. schrieb:
> Templates werden vollständig zur Compile-Zeit ausgewertet, sie können
> also auf dem uC gar keinen Overhead erzeugen, allenfalls der durch sie
> generierte Code. Der hängt aber davon ab, wie ich die Templates
> einsetzte und wofür.

ok, ich meinte damit können den code recht stark vergrößern. Die 
Container werden für jeden Datentype umgesetzt. Das erzeugt recht viel 
Code. Klar hat man dafür auch viele Vorteile.

es war bei mir sogar so, das jedes Template in jeder übersetzungseinheit 
auch mit dem gleichen Datentypen den code mehrfach erzeugt hat.

Autor: cody (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zumindest die erste Begründung ist seltsam.
In C hättest du genau so viel Code wenn du ihn für jeden Datentyp extra 
schreibst.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cody schrieb:
> Zumindest die erste Begründung ist seltsam.
> In C hättest du genau so viel Code wenn du ihn für jeden Datentyp extra
> schreibst.

richtig, aber dort würde man es vermutlich gar nicht machen. Da würde 
man das für einen void* Datentype machen und dann mit cast arbeiten. Ja 
schöner ist das damit nicht, aber sparsamer was die codegröße angeht.

Das meinte ich mit overhread.

Autor: A. H. (ah8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> ok, ich meinte damit können den code recht stark vergrößern. Die
> Container werden für jeden Datentype umgesetzt. Das erzeugt recht viel
> Code. Klar hat man dafür auch viele Vorteile.

Ja, das kann passieren. (Scharfe Messer können eben beißen :-) In solch 
einem Fall kann ich aber versuchen, eine generische Lösung z.B. mit 
void* zu implementieren und nur die Typprüfung ins Template zu 
verlagern. In C ohne Templates kann ein solches Vorgehen schnell im 
Hara-Kiri enden, in C++ habe ich dank der Kapselung durch das Templates 
immer noch eine typsichere Lösung.

> es war bei mir sogar so, das jedes Template in jeder übersetzungseinheit
> auch mit dem gleichen Datentypen den code mehrfach erzeugt hat.

Stimmt auch. Was in einem Template implementiert wird ist in der Regel 
inline mit den entsprechenden Auswirkungen auf den Code. Deshalb ist es 
(im Allgemeinen wenigstens) auch nicht sehr klug, komplexe Funktionen im 
Template zu implementieren; besser ist in eine generische Funktion mit 
dem Template als Wrapper, der dann die entsprechenden 
Compile-Time-Checks macht. Die meiste Funktionen gerade auch der 
Standard-Container sind aber glücklicherweise so kurz, dass das keine 
Rolle spielen dürfte.

Autor: cody (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> es war bei mir sogar so, das jedes Template in jeder übersetzungseinheit
> auch mit dem gleichen Datentypen den code mehrfach erzeugt hat.

Der Code wird zwar in jeder Übersetzungseinheit drin sein, aber nach dem 
Linken sollte der nur noch einmal da sein. Und darauf kommts ja an.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cody schrieb:
> Der Code wird zwar in jeder Übersetzungseinheit drin sein, aber nach dem
> Linken sollte der nur noch einmal da sein. Und darauf kommts ja an.

war bei mir aber nicht der fall. Eventuell geht es ja mit LTO.

Autor: MitLeserin (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
"C++ auf einem MC, wie geht das?"
 ******************************
 hat mich motiviert mich einzulesen.

[Beitrag "C++ auf einem MC, wie geht das?"]

 Beispielcode zeigt, wie ein c++ Programm für uC aussehen kann.

 text     data      bss      dec      hex  filename
 1086       34       16     1136      470  LCDTest_.elf

 aequivalent in C
 ****************
 text     data      bss      dec      hex  filename
  962       32       18     1012      3f4  ValueOut_.elf

 ******************************
 Ich bin kein Informatik Profi,
 viel trial & error und
"hat und gibt sich Mühe"
 *************************
 Alexandra

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> cody schrieb:
>> Normalerweile braucht/will man kein new/delete auf Mikrocontrollern.
>
> und auch keine Exceptions

Und auch kein C++, also das ++ vom C.

Autor: Dumdi D. (dumdidum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian V. O. schrieb:
> In C++ nimmt man einfach std::string

Dazu mal ne Frage: was passiert genau wenn nicht genug Speicher 
(heap/stack) zum durchfuehren einer Stringoperation verfuegbar ist? Kann 
man das vorher ueberpruefen?

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich würde von C++ auf Mikrocontrollern abraten. Seine ganzen 
Vorteile spielt C++ bei dynamischen Sachen aus und gerade das hat man 
bei Mikrocontrollern nicht. Die Hardware ist fest und Speicher begrenzt. 
Finger weg von new und delete und std Containern. Gerade bei nur paar kB 
Speicher ist der schnell fragmentiert.

Und auf PCs würde ich heutzutage, wenn es nicht auf jede Millisekunde 
ankommt, zu C# mit .Net Framework raten. ;-) Die ganzen C++ Fallstricke 
gibt es nicht mehr und die Klassenbibliothek ist sehr umfangreich.

Autor: Ulrich F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dumdi Dum schrieb:
> Dazu mal ne Frage: was passiert genau wenn nicht genug Speicher
> (heap/stack) zum durchfuehren einer Stringoperation verfuegbar ist? Kann
> man das vorher ueberpruefen?

Nein, dass kann man vorher nicht herausfinden!

Auf einem großen Kessel würde sicherlich eine Exception geworfen. Der 
Fehler wäre also behandelbar.

Auf einem µC kollidieren Heap und Stack. (gut dass es meistens einen WDT 
gibt)

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

Bewertung
0 lesenswert
nicht lesenswert
MitLeserin schrieb:
>  aequivalent in C

Hier wäre der c code zu den angaben noch wichtig.
Ausserdem feht die Angabe des compilers und die Optionen.

Der C++ code ist gut, aber kann sicher noch soweit optimiert werden, bis 
das Resultat exakt gleich wie das c equivalent ist.

Dumdi Dum schrieb:
> Sebastian V. O. schrieb:
>> In C++ nimmt man einfach std::string
>
> Dazu mal ne Frage: was passiert genau wenn nicht genug Speicher
> (heap/stack) zum durchfuehren einer Stringoperation verfuegbar ist?

Vermutlich ne bad_alloc exception. Irgendwie kann man den Allocator 
ändern, um auf das implizite new zu verzichten.

Autor: A. H. (ah8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dumdi Dum schrieb:
> Dazu mal ne Frage: was passiert genau wenn nicht genug Speicher
> (heap/stack) zum durchfuehren einer Stringoperation verfuegbar ist? Kann
> man das vorher ueberpruefen?

Das sind eigentlich zwei Fragen in einer: 1.) Wie fordert ein Programm 
Speicher vom darunter liegenden Betriebssystem an? und 2.) Wie reagiert 
die Speicherverwaltung, wenn die Anforderung nicht erfüllt werden kann? 
Beide Fragen haben aber nichts mit der Sprache zu tun. Die 
Standard-Implementierung der Speicherverwaltung wir eine bad_alloc 
Exception werfen, Du kannst aber auch Deine eigene Speicherverwaltung 
implementieren für die der Standard dann auch einen Null-Pointer 
zulässt. In die kannst Du dann natürlich auch Abfragen einbauen, wie 
viel Speicher noch zur Verfügung steht. Mit der Standard-Implementierung 
geht das nicht. Das würde sich auch nur auf den Speicher beziehen 
können, der schon vom Betriebssystem angefordert wurde. Wie das geht, 
hängt vom Betriebssystem ab und natürlich davon, ob es überhaupt ein 
Betriebssystem gibt. Unter Unix/Linux gibt es dazu den brk/sbrk System 
Call. Eine Vorabfrage ist auf einem echten Multi-Task Betriebssystem 
schon deshalb nicht zuverlässig möglich, weil sich zwischen Abfrage und 
Anforderungen die Situation durch andere Prozesse schon wieder geändert 
haben kann.

Autor: MitLeserin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Daniel A.
*****************
aequivalent in C: valout.zip

Original:
********
valout.zip: Beitrag "Formatierte Zahlenausgabe in C"
(Peter Dannegger )

überarbeitet von Uwe S.
**********************
valout.zip Beitrag "Variablenwert auf LCD ausgeben"
(Uwe S|12-09-2011)

Compiler C:
**********
Atmel Studio 6,2 Atmel Toolchain\ : standard Makefile C

Atmel Toolchain\AVR8 
GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-gcc.exe$(QUOTE)  -x c 
-funsigned-char -funsigned-bitfields -DDEBUG  -O1 -ffunction-sections 
-fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=atmega644p 
-c -std=gnu99 -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" 
-MT"$(@:%.o=%.o)"   -o "$@" "$<"


Compiler: C++
********
Atmel Studio 6,2 Atmel Toolchain\ : standard Makefile C++

AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-g++.exe$(QUOTE) 
-o$(OUTPUT_FILE_PATH_AS_ARGS) $(OBJS_AS_ARGS) $(USER_OBJS) $(LIBS) 
-Wl,-Map="LCDTest_.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group 
-Wl,--gc-sections -mmcu=atmega644p  Toolchain


optimieren:
**********
kann ich derzeit noch nicht leisten.

Konzept von Mcucpp finde ich interessant und ich versuche die 
verschiedenen Komponenten der Library im Detail zu verstehen und 
anzuwenden.

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MitLeserin schrieb:
> optimieren:
> **********
> kann ich derzeit noch nicht leisten.

Du könntest aber mal die Optimierung des Compilers für die C++ Variante 
einschalten (z.B. -Os)

Autor: MitLeserin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Torsten Robitzki

Danke für den Hinweis, wieder was gelernt...

LCD_Test C++
*****************************************************
optimize -O1  (default)
*****************************************************
text     data      bss      dec      hex  filename
1086       34       16     1136      470  LCDTest_.elf

optimize most -O3                   //  Debug
*****************************************************
text     data      bss      dec      hex  filename
1000       34       16     1050      41a  LCDTest_.elf

optimize for size  -Os
*****************************************************
text     data      bss      dec      hex  filename
1118       34       16     1168      490  LCDTest_.elf


ValueOut C
*****************************************************
optimize -O1  (default)
*****************************************************
text     data      bss      dec      hex  filename
962       32       18     1012      3f4  ValueOut_.elf

optimize most -O3
*****************************************************
text     data      bss      dec      hex  filename
1162       32       18     1212      4bc  ValueOut_.elf

optimize for size  -Os
*****************************************************
text     data      bss      dec      hex  filename
866       32       18      916      394  ValueOut_.elf

(Werte für Release sind identisch zu Werten für Debug)

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MitLeserin schrieb:

> LCD_Test C++
> *****************************************************
> 1086       34       16     1136      470  LCDTest_.elf

> optimize most -O3                   //  Debug
> 1000       34       16     1050      41a  LCDTest_.elf

> optimize for size  -Os
> 1118       34       16     1168      490  LCDTest_.elf


Kein Tippfehler??!!
-> ? Also bei diesem C++ Compiler ist bei Optimierung auf Größe
das Ergebniss am Größten? Das ist unerwartet.

Das das Ergebniss für C++ größer ist als bei C dagegen nicht.

MfG,

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

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Was bei Microchip schön ist: Du bekommst dort alles aus einer Hand: IDE,
> Compiler, Debugger, Bibliotheken, und alles sauber aufeinander
> abgestimmt.
>
> ...Um einen PIC32MX250F128B auf einer
> Lochrasterplatine in Betrieb zu nehmen, brauchst Du im Wesentlichen 10u
> Keramik oder Tantal, zwei 100n Abblockkondensatoren, und 10k an MCLR.
> Das wars, der Rest ist optional.

Das sind natürlich starke Argumente.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich hab sowohl auf einem ARM7 als auch auf einem AVR schon in C++ 
programmiert.

Aber ganz ehrlich ... Ich seh den Hauptvorteil von C++ gegenüber C 
eigentlich nur in der Kapselung des Codes in Klassen ... Vererbung wird 
interessant, wenn man v.m.a. eine SD-Card-Library baut, die auf 
Flat-Files zugreifen kann und man dann zB per Vererbung eine FAT32-Lib 
bauen möchte oder soetwas ...

Ansonsten tendiert man in C++ eher recht einfache Sachen überkompliziert 
zu lösen ...

Mittlerweile hat für mich C++ die Relevanz komplett verloren. Bin jetzt 
nur noch mit C, Python und Java (wenn es sein MUSS) unterwegs :-)

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut ich hätte kein Problem damit C zu lernen, parallel lerne ich ja 
sowieso C++, schaden tuts sicher nicht beides parallel zu lernen.
Welches Buch könnt ihr mir empfehlen? Darf auch englisch sein. K&R ist 
ja sehr bekannt, soll aber nicht für Anfänger geeignet sein, eher für 
Fortgeschrittene und ich bin Anfänger.

Autor: Ulrich F. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ach die alte Frage... welches ist die beste Sprache?
Glaubenskriege....
Frage 3 Leute und du bekommst 5 Meinungen, und alle haben recht.

Die beste Sprache ist Forth!
Zumindest habe ich durch die Beschäftigung mit Forth intensiv gelernt. 
Mein Tor zu den Hochsprachen.
(wobei man sich da bei Forth nicht sicher sein darf, ob Hochsprache, 
oder nicht)

OOP gabs damals noch nicht (vielleicht in Ansätzen)
Forth hatte da seine Komponenten orientierte Sicht auf die Dinge.

Die Forth Vocabularies entsprechen, in etwa, den modernen Namespaces

Nichts gegen C, ich fand es früher fürchterlich. Nicht viel mehr als ein 
MacroAssembler.
Da konnte man 2 Buchstaben addieren, die Wurzel draus ziehen, und das 
Ergebnis als Pointer auffassen. Ein Gürteltier auf der Tastatur wälzen, 
und der Compiler hat 2 Warnings geworfen.

Nach so ein paar Umwegen, über Pascal (auch OO) , Java, und lange PHP, 
bin ich jetzt bei Arduino und C++.

Mampf F. schrieb:
> Kapselung
Das dürfte das Hauptargument für OO sein. Egal welche Sprache.
Wartbarkeit, Wiederverwendung und weniger Möglichkeiten für unerwünschte 
Seiteneffekte.

Autor: A. H. (ah8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven schrieb:
> Gut ich hätte kein Problem damit C zu lernen, parallel lerne ich ja
> sowieso C++, schaden tuts sicher nicht beides parallel zu lernen.
> Welches Buch könnt ihr mir empfehlen? Darf auch englisch sein. K&R ist
> ja sehr bekannt, soll aber nicht für Anfänger geeignet sein, eher für
> Fortgeschrittene und ich bin Anfänger.

Noch einmal zum Mitschreiben: C ist eine Untermenge von C++. Wenn Du C++ 
beherrscht beherrschst Du auch C. Beherrschen heißt in diesem 
Zusammenhang aber nicht nur die Syntax zu kennen, sondern auch zu 
wissen, wann Du welches Sprachmittel wie einsetzt. Das schließt auch ein 
zu wissen, wann Du auf welches Sprachmittel lieber verzichtest. Wenn Du 
bei der Analyse Deines Problems zu dem Schluss kommst, dass Du Dich 
besser auf die Untermenge von C++ beschränkst, die sich C nennt, dann 
nimm C. Es kann auch Gründe außerhalb der Sprache für diese Entscheidung 
geben, etwa Portabilität. In jedem Fall aber hängt die Entscheidung von 
Deinem Problem ab, nicht von der Sprache.

Ich halte K&R übrigens keinesfalls für zu schwer und auch für den 
Anfänger für die beste Wahl, schon weil sie auch nicht wenig darüber 
erzählen, warum bestimmte Entscheidungen beim Entwurf der Sprache so und 
nicht anders gefallen sind. Das ist auch für den eingefleischten C++ 
Programmiere keine überflüssige Lektüre.

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich F. schrieb:
> Das dürfte das Hauptargument für OO sein. Egal welche Sprache.
> Wartbarkeit, Wiederverwendung und weniger Möglichkeiten für unerwünschte
> Seiteneffekte.

Ich weiß nicht wie oft diese Weisheiten in den letzten 25 Jahren so 
verbreitet wurden. Wahrer werden sie deshalb nicht. Eine vernünftig 
strukturierte C-Lib kann genauso wartbar und wiederverwendbar sein. 
Genau so gut sind viele C++ Libs nur sehr schlecht wartbar und 
wesentlich schwerer zu durchschauen als traditioneller C-Code.

Wenn man versucht, das was in den Lehrbüchern zu C++ steht auf einen 
kleinen µC zu implementieren, dann wir man schnell das Fluchen lernen. 
Hier ist es schon angebracht einen kritischen Blick auf große Teile der 
STL zu werfen. Insbesondere auch bei Strings. So was wie 
Speicherfragmentierung interessiert auf dem PC kaum noch jemanden. Bei 
16kb RAM kann das aber ganz anders aussehen. Wie immer, man muss wissen 
was man tut.

Autor: A. H. (ah8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich F. schrieb:
> Die beste Sprache ist Forth!
> Zumindest habe ich durch die Beschäftigung mit Forth intensiv gelernt.
> Mein Tor zu den Hochsprachen.
> (wobei man sich da bei Forth nicht sicher sein darf, ob Hochsprache,
> oder nicht)

Ich würde so weit mitgehen zu sagen, das Forth die beste Sprache zum 
Lernen ist, schon deshalb, weil schon zwei Zeilen zusammenhängenden 
Forth-Codes so unlesbar sind, dass sie den Anfänger von der ersten Zeile 
an zum radikalen Strukturieren zwingen. Und natürlich gewährt Forth 
Einblicke, wie ein moderner Compiler hinter den Kulissen arbeitet, 
eigentlich ein Muss für jeden ernst zu nehmen Programmierer. Freiwillig 
anwenden würde ich die Sprache aber allenfals noch als Zielcode in 
selbst gebauten Compileren. So gesehen ist Forth quasi das Latein der 
Programmiersprachen.

Autor: Ulrich F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  Speicherfragmentierung
Dafür braucht man kein ++, da reicht schon C.

Und ja, nicht alle Features der OOP Welt machen auf einem µC Sinn.
Aber was man "mitnehmen kann" kann man ja auch nutzen, wenn man möchte 
und Platz und Kenntnis dafür reichen.

Abseits von allen Glaubenskriegen: Es ist wichtig, was hinten raus 
kommt...
Sind die Anforderungen erfüllt?
Tuts das, was man will?

Autor: Karl Käfer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hallo Daniel,

Daniel A. schrieb:
> MitLeserin schrieb:
>>  aequivalent in C
>
> Hier wäre der c code zu den angaben noch wichtig.
> Ausserdem feht die Angabe des compilers und die Optionen.
>
> Der C++ code ist gut, aber kann sicher noch soweit optimiert werden, bis
> das Resultat exakt gleich wie das c equivalent ist.

Im von der MitLeserin verlinkten Thread habe ich das mehrmals gemacht. 
Bei äquivalentem Code sind die von g++ generierten Binaries nur selten 
größer als die vom gcc mit denselben Compilereinstellungen. Und wenn sie 
einmal größer sind, dann in der Regel nur ein paar Bytes. Allermeistens 
optimiert der Compiler die Klassen und Methoden dabei einfach weg. In 
einem Fall war das von g++ erzeugte Binary sogar minimal kleiner als das 
von gcc.

Die große Ausnahme, für die ich bislang noch keine Lösung gefunden habe, 
betrifft globale Variablen, die in einer ISR() und anderen Funktionen 
wie main() verwendet werden. Da scheint der GCC nicht gut zu optimieren.

Liebe Grüße,
Karl

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich F. schrieb:
>>  Speicherfragmentierung
> Dafür braucht man kein ++, da reicht schon C.

Das ist nicht ganz richtig. Um in C dynamischen Speicher zu allocieren 
muss man das explizit hinschreiben. Der unbedarfte Umgang mit der STL 
insbesondere bei Strings und Listen verbirgt das komplett vor dem 
Anwender. Und wer weiß dann wirklich was genau ab geht.

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

Bewertung
0 lesenswert
nicht lesenswert
A. H. schrieb:
> Noch einmal zum Mitschreiben: C ist eine Untermenge von C++. Wenn Du C++
> beherrscht beherrschst Du auch C

Das stimmt so nicht. Wenn C++ ein Superset von C wäre, und C ein Subset 
von C++, würde ich in C++ Compound Literale nicht vermissen, und dürfte 
mich in C nicht an Designated Initializers erfreuen.

Ausserdem kann man anhand eines Supersets kein Subset erkennen.

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:

> Das ist nicht ganz richtig. Um in C dynamischen Speicher zu allocieren
> muss man das explizit hinschreiben.

Das ist in C++ genau so. Weder in C, noch in C++ sehe ich es einer 
Libray sofort an, ob sie dynamischen Speicher verwendet. Man kann es 
sich aber in der Regel ganz gut denken; eine Library für verkettet 
Listen in C wird sehr wahrscheinlich auch malloc/free intern verwenden.

Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> A. H. schrieb:
>> Noch einmal zum Mitschreiben: C ist eine Untermenge von C++. Wenn Du C++
>> beherrscht beherrschst Du auch C
>
> Das stimmt so nicht.

Praktisch gesehen stimmt das schon, doch. In diesem Thread 
http://stackoverflow.com/questions/3879636/what-can-be-done-in-c-but-not-c 
wird besprochen, was es in C, aber nicht in C++ gibt. Sämtliche dieser 
wenigen Features lernt man zusammen in 15 Minuten, und bis auf "variable 
length arrays" handelt es sich wirklich nur um ein bisschen 
syntaktischen Zucker und/oder Workarounds für Probleme, die man in C++ 
gar nicht hat.

Oder sag mir ein einziges Feature, wo man mit C++ wirklich im Regen 
steht.

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten Robitzki schrieb:
> Das ist in C++ genau so.

Im Prinzip hast du recht. Aber nur im Prinzip. Leute die heute C++ neu 
lernen ohne schon mal C programmiert zu haben, lernen die grundlegende 
Syntax und dann erst mal massenhaft STL. Mit anderen Worten C++ und STL 
sind für die untrennbar miteinander verbunden. Keiner käme auf die Idee 
für einen String einen Buffer zu verwenden, weil ja die Pointer so böse 
sind und es std::string gibt. Plötzlich werden aus Konstrukten bei denen 
strstr, strtok u.s.w. reichen würden Konstrukte die jedesmal wieder für 
5 Zeichen lange Strings 20Byte dynamischen Speicher haben wollen.

Klar muss ich mir eine Lib genau ansehen wenn ich sie verwenden will. Es 
ging mir aber um die Libs die jemand lernt wenn er heute mit C oder C++ 
anfängt. Vor allem auf den kleinen Controllern um die es hier ging. 
Sobald ein richtiges Betriebssystem vorhanden ist, sind diese 
Betrachtungen oft nicht mehr nötig.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ja genau ... Oder arbeiten von hausaus mit Boost, weil das ja alles 
kann, was man jemals benötigen wird.

Dass die Header-Files alleine schon 130MB Source-Code haben und der Kram 
ja nicht vorkompiliert wird, da alles Templates ... und dass dann viel 
reinkompiliert wird, was man garnicht braucht ...

Genauso wird dann jemand, der C++ gelernt hat evtl versuchen mittels 
std::cout etwas ausgeben zu wollen usw ...

C++ kann man verwenden, wenn man weiß, was sinnvoll ist und jede Menge 
Erfahrung mit C hat - quasi den Unterbau kennt. Noch besser, wenn man C 
und Assembler kann

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

Bewertung
2 lesenswert
nicht lesenswert
P. M. schrieb:
> Daniel A. schrieb:
>> A. H. schrieb:
>>> Noch einmal zum Mitschreiben: C ist eine Untermenge von C++. Wenn Du C++
>>> beherrscht beherrschst Du auch C
>>
>> Das stimmt so nicht.
>
> Praktisch gesehen stimmt das schon, doch.

Eine Untermenge ist immer volstendig in der Obermenge Enthalten. Mit C 
und C++ trifft das nicht zu. Weder theoretisch noch praktisch.

> In diesem Thread
> http://stackoverflow.com/questions/3879636/what-can-be-done-in-c-but-not-c
> wird besprochen, was es in C, aber nicht in C++ gibt. Sämtliche dieser
> wenigen Features lernt man zusammen in 15 Minuten, und bis auf "variable
> length arrays" handelt es sich wirklich nur um ein bisschen
> syntaktischen Zucker und/oder Workarounds für Probleme, die man in C++
> gar nicht hat.

Die Leute aus dem verlinkten Thread schauen wohl durch die Rosa 
C++-Brille. Diese "Workarounds" sind nicht mit ihrem C++ Lösungsansatz 
zu vergleichen.

> Oder sag mir ein einziges Feature, wo man mit C++ wirklich im Regen
> steht.


Compound Literale:
Stelle dir eine einfache Menustruktur vor, in c z.B. so:
// ungetestet
struct menu;
struct menu {
  char* name;
  struct menu* submenu;
};
struct menu menu = {
  .name = "test",
  .menu = (struct menu[]){
    {
      .name = "a"
    },{
      .name = "b"
    }
  }
};

Soetwas ist nur in C derart einfach möglich. Um das selbe in C++ zu 
erreichen benötigt man entweder dynamische Speicherreservirung, oder 
mehrere Declarationen, oder mehrere templatetypen, oder mehrere 
CopyConstructor aufrufe zur runtime. Wie kann das besser sein?

Designated Initializers:
Nun der Code oben ist schonmal einfacher zu lesen als ohne. Ausserdem 
kann man damit named arguments Emulieren. Dies ist in C++ unmöglich.
 // ungetestet
struct x {
  int *a,*b,*c;
};
void func(struct x x){
}
#define func(...) func((struct x){VA_ARGS})

///////////

func(.b=(int[]){2});



Versteht mich nicht falsch, ich finde C++ eine wunderbare Sprache, aber 
sie ist nicht perfekt, und nur wenige können tatsächlich damit umgehen.

: Bearbeitet durch User
Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Im Prinzip hast du recht. Aber nur im Prinzip. Leute die heute C++ neu
> lernen ohne schon mal C programmiert zu haben, lernen die grundlegende
> Syntax und dann erst mal massenhaft STL. Mit anderen Worten C++ und STL
> sind für die untrennbar miteinander verbunden. Keiner käme auf die Idee
> für einen String einen Buffer zu verwenden, weil ja die Pointer so böse
> sind und es std::string gibt.

Das ist nicht ein Problem des C++-Lernens, sondern ein Problem von 
Programmiereinführungen, die nicht genügend auf die technischen Aspekte 
eingehen. Wer nicht lernt, wie ein Programm und diverse 
Bibliothekskonstrukte intern funktionieren, der wird sich mit C, C++ 
oder Java genau gleich verfranzen.

Ich bin sogar der Meinung, C++ eigne sich sehr gut zur 
Programmiereinführung. Weil kaum eine andere Sprache abstrakte Aspekte 
des Software-Engineering so direkt mit technischen 
Implementationsdetails verknüpft. Beispielsweise wenn man eigene 
Operatoren für Vergleich und Zuweisung definiert, am besten noch unter 
Verwendung von rvalues. Da sieht man so richtig, was der Compiler intern 
macht und muss sich gleichzeitig Gedanken dazu machen, was aus Sicht des 
benutzenden Programmierers Sinn ergibt.

: Bearbeitet durch User
Autor: Bodo G. (Firma: gsi) (bodogravert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Re: Welchen Controller für C++ Programmierung?

Einen Controller der dynamische Speicherverwaltung unterstützt,
den viele C++ Eigenschaften basieren darauf gewisse Speicherbereiche
dynamisch zu erweitern. Insbesondere in multi-threaded Applikationen.

Also ein Controller mit MMU, und das ist wiederum kein kleiner 
Controller.

Wer einen Controller mit flat-memory, also einfachen linearen Speicher
verwendet, sollte stets Speicherfragmentierung vermeiden.

Das geht durchaus, indem man mit entsprechenden Memory Schematas, bzw. 
Allokatoren arbeitet, also z.B. guarded Memory-Pools fester Grösse.

D.h. man macht sich sinnvoller weise Gedanken um das Geschehen in den
unteren Schichten und schon bröselt C++ implizite Eleganz, da es da 
unten
im Keller in C einfacher geht.

Oder seh ich da was falsch?

Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bodo Gravert schrieb:
> Einen Controller der dynamische Speicherverwaltung unterstützt,
> den viele C++ Eigenschaften basieren darauf gewisse Speicherbereiche
> dynamisch zu erweitern.
> ...
> Oder seh ich da was falsch?

Ich würde sagen, ja, falsch. Ich arbeite sehr hardwarenah (nicht 
Mikrocontroller) mit C++ und man muss hier wirklich mit KEINERLEI 
Overhead gegenüber einer C-Lösung auskommen. Aber man muss wissen, wie 
die Sprache und ihre Bibliothek funktionieren. Das gehört aber 
eigentlich zu einem anständigen Programmierer dazu :-)

Autor: Marian  . (phiarc) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Soetwas ist nur in C derart einfach möglich. Um das selbe in C++ zu
> erreichen benötigt man entweder dynamische Speicherreservirung, oder
> mehrere Declarationen, oder mehrere templatetypen, oder mehrere
> CopyConstructor aufrufe zur runtime.

Das ist falsch. Seit C++11 gibt es für solcherlei Dinge formal 
constexpr, allerdings haben die Compiler (MSVC, GCC) das auch vorher 
wegoptimiert (statische Initialisierungen wegoptimieren ist sehr 
einfach) und optimieren das auch ohne explizites constexpr.

Touche für designated Initializer, das ist eine elegante und sehr 
"zeichenarme" Syntax, die C++ - vom Standard her - nicht hat. Man kann 
sich allerdings (wie üblich ohne Runtime-Overhead) ähnliche Dinge bauen. 
Zugegebenermaßen ist diese Menü-DSL dann nicht so schön wie DIs.

Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Soetwas ist nur in C derart einfach möglich.

Ganz böse Zungen könnten jetzt natürlich auch fragen, warum es in C++ 
keine Designated Initializer gibt. Ich frage mich z.B., wie man sowas 
kopieren würde. Oder könnte man überhaupt eine Funktion schreiben, die 
einen Pointer auf das Wurzel-Struct als Parameter nimmt und dann das 
Menu ausgibt? Wohl nicht, ohne Zusatzinformationen mitzuliefern.

Autor: Bodo G. (Firma: gsi) (bodogravert)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Welchen Controller für C++ Programmierung?

war die Frage!

.. und keine Auforderung zu Selbstdarstellung ..

Autor: Karl Käfer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

Daniel A. schrieb:
> Soetwas ist nur in C derart einfach möglich.

Die drei Dateien im Anhang habe ich mit g++/4.9.1 und clang++/3.5.0 
übersetzt. Warnungen gibt es meistens nur mit -Wpedantic und die 
C++11-Features in o.cpp kompilieren nur mit -std=c++11 (bzw. 
-std=gnu++11).

Liebe Grüße,
Karl

PS: Ja, ich weiß, daß das nicht standardkonform ist. Allerbesten Dank 
für die freundlichen Hinweise. ;-)

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

Bewertung
0 lesenswert
nicht lesenswert
P. M. schrieb:
> Daniel A. schrieb:
>> Soetwas ist nur in C derart einfach möglich.
>
> Ganz böse Zungen könnten jetzt natürlich auch fragen, warum es in C++
> keine Designated Initializer gibt. Ich frage mich z.B., wie man sowas
> kopieren würde.

Was meinst du mit "sowas"?
Einen Initialiser kann man nicht Kopieren, Werte und Objekte kann man 
kopieren, aber das hat nichtsmehr mit einer Initialisierung zu tun. 
Falls du dich auf die Datenstruktur im Beispiel Beziehst, diese zu 
kopieren wird dadurch auf Designated Initializer zu verzichten nich 
einfacher.

> Oder könnte man überhaupt eine Funktion schreiben, die
> einen Pointer auf das Wurzel-Struct als Parameter nimmt und dann das
> Menu ausgibt? Wohl nicht, ohne Zusatzinformationen mitzuliefern.

Spielst du auf die fehlende Mengenangabe der Menueinträge im Strukt aus 
dem Beispielmenu an? Die hab ich der Einfachheit weggelassen, damit 
nimand auf die Idee kommt den Designated Initializer für das Fehlen der 
möglichkeit in C wärend des Initialisierens des Objects auf dessen 
member zuzugreifen verantwortlich macht. C++ mag dort einen vorteil 
haben, aber mit c makros ist das kein Problem:
// ungetestet
#define MENU_ITEMS(x) \
  .items = x, \
  .count = sizeof x

struct menu;
struct menu {
  char* name;
  struct menu* items;
  unsigned count;
};

struct menu menu = {
  .name = "test",
  MENU_ITEMS(((struct menu[]){
    {
      .name = "a"
    },{
      .name = "b"
    }
  }))
};

Bodo Gravert schrieb:
> Welchen Controller für C++ Programmierung?
>
> war die Frage!

Den gleichen wie zur C Programmierung.
Es gibt 2 Faktoren:
  * Minimal benötigte IO, Ram, Flash
  * Erfahrung (zwischen 0 und 1)

Rechne dann minimalen IO, Ram und Flashbedarf mal (2-erfahrung) mal 1.2.

Alternative: Schreibe zuerst dass Programm, Compilire und Teste es, und 
kaufe dann den Billigsten der Anwendung ausreichenden UC.

Da es hier aber eher um den Einstieg geht empfehle ich einen kleinen 
ATiny für Hello World und nen grossen ATmega für interessantere Dinge. 
Das ist aber erst die halbe miete, die wahl des richtigen Programmers 
kann entscheidend sein. Zusetzlich ist ein Steckbrett und vorkentnisse 
in Elektrotechnik nützlich. Als IDE kommt von Eclipse über AvrStudio bis 
zu meinem Favorit: kate + shell + makefile alles in frage.

PS: Ich bin ein Arduino Gegner.
PPS: Man sollte immer einige ersatz-UCs haben.

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

Bewertung
0 lesenswert
nicht lesenswert
Es gibt jede Menge Meinungen zu C und C++ wie ich sehe, daher eine 
andere Frage:

Ist der "C Primer Plus" vom Inhalt her überdimensioniert für die 
Programmierung von Mikrocontrollern? Wie siehts bei Mikroprozessoren aus 
(wenn das Projekt mal komplizierter wird zB eine kleine Werkzeugmaschine 
mit 3 Achsen)? Oder reicht der K&R hierfür immer noch aus?

Autor: Ulrich F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Oder reicht der K&R hierfür immer noch aus?
Zumindest bietet er eine ordentliche Startmenge.
Zusätzlich sind die Datenblätter von allen beteiligten Komponenten 
sicherlich sehr hilfreich und teilweise auch notwendig.

Sven schrieb:
> C Primer Plus
Ist mir nicht bekannt


Wie schon in den Vorpostings deutlich wurde, sind im Bereich C/C++ auf 
µC etliche Randbedingungen zu beachten. Es gibt Bücher, welche sich auf 
diesen Bereich eingeschossen haben. Vielleicht wäre das eine gute 
Zusatzliteratur zum K&R.

Autor: Karl H. (kbuchegg) (Moderator)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Sven schrieb:
> Es gibt jede Menge Meinungen zu C und C++ wie ich sehe, daher eine
> andere Frage:
>
> Ist der "C Primer Plus" vom Inhalt her überdimensioniert für die
> Programmierung von Mikrocontrollern?


'überdimensioniert' gibt es nicht.
Denn die kleinen Feinheiten in C (genauso wie in C++), die du am Anfang 
lernst, belegen schon mal gut und gerne die Hälfte jeder Literatur. Und 
die muss man beherrschen.

Was auf der Mikrocontrollerebene ein wenig zurück tritt:
* Arbeiten mit Dateien
* dynamische Speicherallokierung

Allerdings zeigt die Praxis, das man über kurz oder lang sich auch 
irgendwelche Hilfsprogramme auf dem PC machen wird bzw. muss. Und dann 
werden auch diese Themen relevant.

> Wie siehts bei Mikroprozessoren aus
> (wenn das Projekt mal komplizierter wird zB eine kleine Werkzeugmaschine
> mit 3 Achsen)? Oder reicht der K&R hierfür immer noch aus?

Grundsätzlich  musst du unterscheiden zwischen der standardisierten 
Sprache und systemspezifischen Erweiterungen. Die standardisierte 
Sprache ist (mit allen Ausnahmen) überall die gleiche, die Regeln wie 
Datentypen in Ausdrücken die Auswertung beeinflussen sind zb überall 
dieselben, auch wenn unterschiedliche Systeme eine unterschiedliche 
Ansicht darüber haben, wie gross ein int ist.
Kennt man die standardisierte Sprache erst mal, dann sind die 
systemspezifischen Erweiterungen (zb wie greift man auf ein Portbit zu) 
relativ einfach zu lernen. Oft wird das auch so gemacht, dass das ganze 
wie Standard-C aussieht und der Compiler erkennt das und setzt es 
entsprechend um (zb beim GCC).
In der µC-Programmierung arbeitet man oft mehr auf Bitlevel als in der 
Desktopprogrammierung. D.h. mit den Bitoperationen muss man umgehen 
können. Das kann man allerdings auch auf einem reinen Desktopsystem 
lernen, auch wenn diese Dinge in der Literatur eher stiefmütterlich 
behandelt werden. Aber so um die 90% der Sprache funktionieren da wie 
dort identisch. Wer von einem Desktop System ein ordentliches Fundament 
an Sprach-Kentnissen mitbringt, tut sich in der µC-Welt relativ leicht.

: Bearbeitet durch Moderator
Autor: Bodo G. (Firma: gsi) (bodogravert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Such dir irgend eine MCU Architektur die breit vertreten ist und eine 
agile
Community hat, z.b. Arduino. Sieh zu das du eine freie Tool-Chain nutzen
kannst. Wie z.B. Arduino, hier wird implizit der avr-gcc genutzt.
Ein wirklich gutes Werkzeug. Den Weg vom Arduino kannst du über den 
Teensy
nehmen, dann bist du in der ARM Cortex-Mx Welt und hast eine moderne
32 Bit Risc Architekur vor dir und arbeitest mit relativ ähnlichen 
Werkzeugen, arm-none-eabi-* gcc toolchain. Wieder ein Hauch C++, aber 
halt genug um einen Microcontroller der 80-100 Mips (Performance 
diesmal) Klasse zu bewegen. Wenn dir die Arduino IDE (Integrated 
Development Environment) auf den Geist geht, was bei den meisten wohl 
irgendwann der Fall ist, dann kannst du immer noch weiterhin mit der 
gcc-tool-chain arbeiten, lernst ein Makefile zu erzeugen, und nutzt z.B. 
die unix-tool-box oder was GUI basiertes wie Eclipse.

Du kannst aber auch direkt von oben in die 32-Bit RISC Welt einsteigen.
Kaufst dir für kleines Geld (15 Euro) ein STM32F4-Discovery Board und 
ziehst dir von https://launchpad.net/gcc-arm-embedded die
Pre-built GNU toolchain from ARM Cortex-M & Cortex-R processors 
(Cortex-M0/M0+/M3/M4/M7, Cortex-R4/R5/R7).

Aber unterschätz das nicht, das sind moderne Full-Size 32 Bit RISC SoCs
(System on Chip). Ein STM32F405 macht aus dem Stand 220 DMIPS und hat 
eine
32 Bit (single float) FPU und ISA (Instruction Set Architecture) 
Erweiterungen die in zu einem ganz passablen DSP machen.

Also ein generischer RISC Mikrocontroller mit DSP Fähigkeiten.
Damit lassen sich gut und gerne 90% aller embedded Industrie 
Applikationen
erschlagen.

Und noch was, lass dich nicht täuschen. Einen 32-Bitter nach POR 
(Power-On-Reset) main() ausführen zu lassen, benötigt detailliertes 
Verständniss der MCU Architektur. Da muss man die Augen spitzen und in 
die Hardware Dokumentation des betreffenden Chip eintauchen, die fast 
immer in Englisch.

Aber wenn man sowas wie die Arduino oder Teensy IDEs nutzt, hat man 
erstmal
das Vergnügen direkt mit den Pads der MCU zu wackeln.

Einen Steppermotor kann man gut und effizient mit einem AVR bewegen, 
sollte
es ein SVPWM geregelter PMSM* oder BLDC* Motor werden braucht man einen
Cortex-Mx.

*PMSM - Permanent Magnet Synchronous Motor
*BLDC - Brushless Direct Current Motor

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

Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal den folgenden Thread an:

Beitrag "Keil free für STM32F0"

mit Keil kannst du sehr gut in c++ entwickeln und debuggen.

Vorteil ist noch der eingebaute Simulator, damit lassen
sich auch sehr gut Unittests ohne Hardware (z.B. simulierte 
Uart-Ausgabe) durchführen.

Das gleiche geht auch mit dem Debugger auf dem STM32F0-Discoveryboard
(Uart Ausgabe).

Auf jeden Fall läßt es sich damit erstmal einfach und kostenlos
in die STM32F0 Welt einsteigen.

Später kannst du dann auch auf die GCC-Toolchain wechseln.

Autor: Andreas R. (daybyter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin wohl gerade in einer ähnlichen Situation, und arbeite mich in 
stm32duino ein. Benutze dazu die Arduino IDE und eines der Stm32c8t6 
minimum dev boards von eBay (knapp 4,-). Ist nicht ganz so einfach wie 
Arduino, aber zumindest compiliert mal was.

Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Persönlich würde ich für den Anfang raten, auf einer möglichst einfachen 
Architektur und direkt mit C oder C++* zu starten, ohne irgendwelche 
Libraries oder Plattformen dazwischen. Es ist sehr lehrreich, wenn man 
mal wirklich das gesamte System durchschauen kann.

* So lange man keine virtuelle Vererbung und keine STL verwendet. 
Später, wenn man weiss was man tut, kann man diese Features dann dazu 
nehmen - nicht alle, nicht immer und nicht zu exzessiv.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bodo Gravert schrieb:
> MCU agile Community Tool-Chain Mips IDE GUI SoCs DMIPS FPU ISA
> POR SVPWM PMSM BLDC

Inhaltlich d'accor, aber ich habe selten so eine Ansammlung von 
absichtlichen Fachsprech-Abkürzungen gelesen "soll wohl den 
Eindruckerwecken: ich Firma, ich Ahnung, ich kann Fachchinesisch", aber 
immerhin erklärt er die meisten.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
deshalb schreibt er auch:
>Aber unterschätz das nicht, das sind moderne Full-Size 32 Bit RISC SoCs
>(System on Chip). Ein STM32F405 macht aus dem Stand 220 DMIPS ....

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe alles verstanden, er hat immerhin alle Fachausdrücke 
erklärt. Viele hier im Forum benutzen Fachausdrücke nur erklären diese 
dann nicht, ganz anders Bodo Gravert.

Autor: Bodo G. (Firma: gsi) (bodogravert)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Danke,
ich such mir das nicht aus. Wir bewegen uns halt im
amerikanischen Sprachraum.

Keiluser:

Stimmt du könntest auch mit Keil durchstarten.
Je nachdem auf welcher Hostplatform du dich bewegst.

Aber ich würde einen Cortex-M4F (zb. STM32F4- oder STM32F429-Discovery)
nehmen. Der M4 hat einige interessante Debug Features, die auf dem
kleinen M0 nicht vorhanden sind.

Nimmt man ein STM32F429-Discovery, dann bekommst du für wenig Geld
ein QVGA Display und 8MByte SDRAM, das für ca. 25 Euro.
Single-Wire-Debug Interface (SWD) ist On-board.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mich noch interessieren würde:

Gibt es für den Cortex-M4F und PIC32 auch sowas wie "Lessons" zB direkt 
vom Hersteller? Oder etwas in der Art wo mal demonstriert wird wie man 
die Peripherie nutzt.
Bei den 8 Bit PICs gibts das PICKit3 Debug/Express Kit, dort sind 
C-Lessons dabei, zugeschnitten auf den PIC18F45K22. Wäre für mich 
eigentlich das Entscheidungskriterium schlechthin, denn ohne sowas wäre 
ich aufgeschmissen.

Autor: Andreas R. (daybyter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für Arduino gibt es hält massig Tutorials. Deshalb nahm ich das ja. 
Wobei  halt noch nicht alles auf den stm32 portiert ist. Die Details 
gibt es im Forum www.stm32duino.com .

Autor: Bodo G. (Firma: gsi) (bodogravert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Bodo G. (Firma: gsi) (bodogravert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
www.stm32duino.com, richtig, hat ich noch nicht
wahrgenommen.

Hier werden auch die sogenannten Nucleo-Boards,
also STM32xyz mit Arduino Uno Footprint verwendet.

Ich denke bei der Wahl hat man viel Qual.

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Cortex-M0/3/4 gibt es noch mbed: https://developer.mbed.org/
Eine Online IDE mit Compiler und Versionsverwaltung, dazu eine Basislib 
für Digitale/Analoge IO, SPI/I2C, Timer und einiges mehr. Weiterhin eine 
ganze Menge Libs für externe Komponenten wie Displays, Sensoren, Aktoren 
usw. Alles in C++ und durch die offenen Quellen gut zu verwenden. Damit 
wird der Einstieg in die Cortex Welt sehr einfach, ähnlich wie Arduino 
aber um einiges offener/besser. Hardware war ursprünglich nur ein 
LPC1768 von NXP, jetzt sind aber auch STM und eine Menge Exoten dabei. 
Man muss nicht unbedingt die offiziel unterstützte HW benutzen, ich 
arbeite gerne mit einem LPC1347 Breakoutboard, einem Projekt was auf 
Github zu finden ist: https://github.com/sebseb7/pentarm13uxx

Autor: newbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die ganzen zusammengetragenen Infos.

jetzt noch eine abschließende Frage, etwas off-topic, aber ich würde 
gerne noch ein englischsprachiges Buch über C empfohlen bekommen. Es 
sollte ein gutes Buch sein, am besten das beste :-)

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven schrieb:
> Was mich noch interessieren würde:
>
> Gibt es für den Cortex-M4F und PIC32 auch sowas wie "Lessons" zB direkt
> vom Hersteller? Oder etwas in der Art wo mal demonstriert wird wie man
> die Peripherie nutzt.
> Bei den 8 Bit PICs gibts das PICKit3 Debug/Express Kit, dort sind
> C-Lessons dabei, zugeschnitten auf den PIC18F45K22. Wäre für mich
> eigentlich das Entscheidungskriterium schlechthin, denn ohne sowas wäre
> ich aufgeschmissen.

Bei den Compilern sind die Peripheriebibliotheken gleich dabei, für 
komplexere Sachen wie USB und TCP/IP gibts die Microchip Application 
Libraries. Und AppNotes gibts so viele, da kommt Du mit dem Lesen nicht 
hinterher.

fchk

Autor: Bodo G. (Firma: gsi) (bodogravert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C Programming Language (2nd Edition)
Kernighan and Ritchie, was sonst ?

Autor: newbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das K&R wird allseits empfohlen, aber nicht für Anfänger, es soll ein 
Nachschlagewerk sein jedoch kein Anfängerlehrbuch. Ich suche ja ein 
Lehrbuch. Was ist vom C Primer Plus zu halten oder von Nitty Gritty C? 
wird hier im uC Forum ja auch erwähnt.

Autor: db8fs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
newbie schrieb:
> Ja das K&R wird allseits empfohlen, aber nicht für Anfänger, es
> soll ein
> Nachschlagewerk sein jedoch kein Anfängerlehrbuch. Ich suche ja ein
> Lehrbuch. Was ist vom C Primer Plus zu halten oder von Nitty Gritty C?
> wird hier im uC Forum ja auch erwähnt.

K&R ist genau das: ein Lehrbuch und didaktisch auch so aufgebaut - es 
lehrt die Sprachkonstrukte samt Risiken und Nebenwirkungen.
Ansonsten ist sicher Wolf: C von A bis Z ganz brauchbar. Als Referenz 
nehm ich gerne O'Reilly's "C kurz gut", gerade für irgendwelche IEEE749 
Sachen oder C99-spezifisches imho ganz ok.

Als blutiger Einsteiger hatte ich damals, bitte nicht lachen, mit "C für 
Linux in 21 Tagen" angefangen - hatte aber gehalten, was es versprochen 
hatte. :)

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier http://accu.org/index.php/book_reviews_redirect gibt es gute Buch 
Rezensionen. Allerdings überwiegend C++, aber auch einige C Bücher. 
Vielleicht findest Du da etwas zu Deinen C-Büchern.

Autor: A. H. (ah8)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
newbie schrieb:
> Ja das K&R wird allseits empfohlen, aber nicht für Anfänger, es soll ein
> Nachschlagewerk sein jedoch kein Anfängerlehrbuch. Ich suche ja ein
> Lehrbuch. Was ist vom C Primer Plus zu halten oder von Nitty Gritty C?
> wird hier im uC Forum ja auch erwähnt.

Das würde ich aus eigener Erfahrung nicht bestätigen. K&R war eines der 
ersten Bücher, die ich damals gelesen habe (da noch in der deutschen 
Übersetzung), und ich bin damit besser klar gekommen als mit jedem 
anderen.

Autor: Bodo G. (Firma: gsi) (bodogravert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.. stimme ich zu, der K&R ist ein didaktisch durchdachtes buch,
und halt das C Lehrbuch. Nach dem K&R liest man dann die Quellen
Anderer, zum Beispiel den Linux Kernel.
Ausgesprochen sauberer Code, stilistisch und inhaltlich prägnant.

Nicht erschrecken, es geht nur darum die Tricks und den Style erfahrener
Programmierer zu absorbieren und daraus seinen persönlichen Stil
zu entwicklen.

Um das ganze zu praktizieren, reicht ein Raspberry PI sammt Linux,
Zugang via TCP/IP SSH, einen kompententen Editor, zb. emacs oder vi
und die auf dem rasp ohnehin vorhanden gcc toolchain.

Ist aber nichts für Fingerbehinderte, schreiben und lesen muss man 
schon.
Die Lernkurve ist flach, aber das was bleibt ist von Dauer.

Autor: newbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann muss es wohl der K&R sein. Es kommt aber noch die Frage auf 
warum der Primer zB über 1000 Seiten hat, wohingegen der K&R knapp 300 
hat. Wenn der K&R alles beinhaltet um Controller zu programmieren dann 
ist das für mich ausreichend. Der Seitenunterschied ist halt gewaltig.

Autor: Bodo G. (Firma: gsi) (bodogravert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..der K&R lehrt C.
Da steht nicht drin wie man ein crt0 schreibt um einen Controller
aus dem nichts zu holen.

Via K&R lernt man C zu programmieren. Dann schaut man wie eigene
einfache C Programme von einem Compiler (zb.gcc) in Assembler
übersetzt werden. Man lernt dabei die Maschine kennen und studiert
deren Architektur. Man bettet eigenen Assembler Code in C ein
und lernt Schritt für Schritt die Maschine (CPU) kennen.
Hat man die Architektur der Maschine verstanden, dann kann man den
ersten initialen Code Schreiben, der ins main() führt.
usw..

Autor: A. H. (ah8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
newbie schrieb:
> Es kommt aber noch die Frage auf
> warum der Primer zB über 1000 Seiten hat, wohingegen der K&R knapp 300
> hat.

:-)

In eine Abi-Zeitung stand einmal: „Wer mit zwanzig Worten das sagt, was 
man auch mit zehn sagen kann, der ist auch zu anderen Missetaten fähig!“ 
Ob das auf den Primer zutrifft kann ich nicht sagen, ich kann mich nicht 
erinnern, ihn gelesen zu haben. Sollte ich aber einmal in die Situation 
kommen, mich ganz schnell zwischen zwei Büchern entscheiden zu müssen 
und dabei nichts als die Seitenzahl zur Verfügung zu haben, ich würde 
das dünnere nehmen. Gute Autoren können das Wesentliche mit wenigen 
Worten beschreiben und nur wenige Themen sind so komplex, dass die 
vielen Worte gerechtfertigt sind. Hole Dir doch beide Bücher – und gerne 
noch ein paar mehr – aus der Bibliothek Deines Vertrauens und welches 
Dir am meisten zusagt, dass stellst Du Dir dann in den eigenen Schrank. 
So habe ich es immer gehalten und in meinen Schrank haben es bisher nur 
wenige dicke Bücher geschafft – zu den Ausnahmen gehören der Stroustrup 
und der C++-Standard – das Meiste was da steht aber ist nicht viel 
dicker als der K&R.

: Bearbeitet durch User
Autor: Asm und gut ist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. H. schrieb:
> So habe ich es immer gehalten und in meinen Schrank haben es bisher nur
> wenige dicke Bücher geschafft

Da liegen bei mir nur ein paar Blättchen mit den AVR Asm-Instruktionen.
Für >90% typischer Bastle-Apps absolut ausreichend.
Aber warum einfach wenns auch kompliziert geht?

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Asm und gut ist schrieb:
> Da liegen bei mir nur ein paar Blättchen mit den AVR Asm-Instruktionen.
> Für >90% typischer Bastle-Apps absolut ausreichend.
> Aber warum einfach wenns auch kompliziert geht?

Guten Morgen Moby. Willst du deinen Avr-ASM-Semf in einen C++ Thread 
auch wieder dazu geben?

Autor: C(++) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Asm und gut ist schrieb:
> Da liegen bei mir nur ein paar Blättchen mit den AVR Asm-Instruktionen.
Bei mir ganz nichts, das C(++) Wissen in Kopf und auf geht's.
> Aber warum einfach wenns auch kompliziert geht?
Warum sich ASM antun, wenn es auch schöne Hochsparen wie C(++) gibt?
ASM nur, wenn ich auf den Taktzyklus genau wissen muss wie lange etwas 
dauert.

Autor: Asm und gut ist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C(++) schrieb:
> Warum sich ASM antun, wenn es auch schöne Hochsparen wie C(++) gibt?

Nö. So wird ein Schuh draus:

Mampf F. schrieb:
> Ansonsten tendiert man in C++ eher recht einfache Sachen überkompliziert
> zu lösen ...

***

newbie schrieb:
> der Primer zB über 1000 Seiten

Das nenn ich dann

C(++) schrieb:
> antun

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

Bewertung
0 lesenswert
nicht lesenswert
@Asm und gut ist

Ich behaupte, jeder gute C Programierer kennt den vollständigen Syntax 
und jedes Sprachkonstrukt auswendig und muss nicht erst nachlesen.

Kennst du die definition jeder ASM-Instruktion deiner Lieblings CPU 
auswendig, ohne jemals nachsehen zu müssen?
Falls ja: Wie lange hat das gedauert?

Autor: C(++) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
newbie schrieb:
> wohingegen der K&R knapp 300 hat.
300 Seiten für K&R sind nicht mal doppelt so viel wie der 8-bit ARV 
Instruction Set: http://www.atmel.com/images/doc0856.pdf
Nur mit dem feinen Unterschied, dass man C einmal lernt. ASM hingegen, 
muss man für jeden neue CPU noch mal lernen.

Autor: Moby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C(++) schrieb:
> Asm ... muss man für jeden neue CPU noch mal lernen.

Muss man nicht.
Denn in aller Regel kann der Bastler ja bei seiner CPU bleiben.
Portabilität ist für ihn meist ein eher theoretischer Vorteil.
Zumal es mit dieser bei hardwarenaher Programmierung und mit neuen 
Hardware-Architekturen eh nicht weit her ist.

Autor: C(++) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby schrieb:
> C(++) schrieb:
>> Asm ... muss man für jeden neue CPU noch mal lernen.
>
> Muss man nicht.
Aber nur wenn man in seiner kleinen, engstirnigen Welt bleit.

> Portabilität ist für ihn meist ein eher theoretischer Vorteil.
> Zumal es mit dieser bei hardwarenaher Programmierung und mit neuen
> Hardware-Architekturen eh nicht weit her ist.
Wenn der Code gut ist, muss man nur die Abstrahierungsebenen anpassen.
Wenn nicht, muss man nur die hardwarespezifischen Dinge nachlerne und 
ändern und nicht einen kompletten Befehlssatz...

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Denn in aller Regel kann der Bastler ja bei seiner CPU bleiben.
Das entscheidet der Bastler aber selbst. Und auch ob er ein Tool zum 
Register allokieren benutzen will.
Mensch (Fisch?) Moby, warum biste nicht im Urlaub geblieben?

Autor: Moby (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
C(++) schrieb:
> muss man nur
> muss man nur

Natürlich.
Man muss ja nur...
Theoretisches Geplänkel.
Ich sag Dir mal was man wirklich nur muss:
Die paar Asm-Instructions und seinen Controller richtig kennen- das 
reicht für ewig. Nicht zuletzt, weil Asm alles aus den kleinen 
Wunderchips herausholt ;-)

Autor: AuchMal (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Das schöne an Moby's Argumenten ist ja gerade,

das man nur das Gegenteil davon nehmen muss um richtig zu liegen

;-)

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby schrieb:
> Ich sag Dir mal was man wirklich nur muss:
> Die paar Asm-Instructions und seinen Controller richtig kennen- das
> reicht für ewig. Nicht zuletzt, weil Asm alles aus den kleinen
> Wunderchips herausholt ;-)

Na, hast du dich durch gerungen ohne dein Synonym wieder Unruhe in einem 
Thread zu stiften von dem du keine Ahnung hast?

Im übrigen scheint deine Interpretation von Ewigkeit genauso abwegig wie 
deine sonstigen Erkenntnisse zu sein. Glaubst du ernsthaft dir verkauft 
in 20 Jahren noch irgendwer einen AVR zu ähnlichen Preisen wie heute? 
Auch noch in DIP? Entweder kramen da noch irgendwelche Nostalgiker ihren 
Müll zu Mondpreisen aus der Schublade oder es wird schwer noch einen 
8bit AVR neu zu bekommen.

Ich denke zu der Zeit wirst du dann hier predigen, dass der 
arm-Assembler das einzig wahre ist...

Autor: C(++) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby schrieb:
> C(++) schrieb:
>> muss man nur
>> muss man nur
>
> Natürlich.
> Man muss ja nur...
> Theoretisches Geplänkel.
Wenn man nur ASM programmiert, hat man das in der Praxis natürlich noch 
nie gesehen.

Autor: C(++) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch was zum Thema "Theoretisches Geplänkel":
Ich habs extra für die ausprobiert: Meinen One Wire DS18B20 C-Code hab 
ich in nich mal 1/4 Stunde von PIC24 (16bit CPU) nach PIC18 (8bit CPU) 
portiert.

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist doch kein Problem, da PIC's ja ALLE EXAKT den selben Befehlssatz 
haben ;-)
Moby kann man nicht helfen, denn er kennt nur seine Nußschale und fühlt 
sich daran als Herscher eines unendlichen Gebiets. (frei nach William 
S.)

Autor: Evelyn Eysenaug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> (frei nach William S.)

Sehr frei ... ;)

"O Gott, ich könnte in eine Nussschale eingesperrt sein und mich für 
einen König von unermesslichem Gebiete halten, wenn nur meine bösen 
Träume nicht wären."
Hamlet, 2. Akt, 2. Szene

Autor: C(++) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> Das ist doch kein Problem, da PIC's ja ALLE EXAKT den selben Befehlssatz
> haben ;-)
Blödsinn²
Vergleich mal:
Seite 318: http://ww1.microchip.com/downloads/en/DeviceDoc/39632e.pdf
Seite 257: http://ww1.microchip.com/downloads/en/DeviceDoc/39995_b.pdf

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@C++:
Du solltest mal Deinen Ironie-Detektor neu kalibrieren ...

Gruß, Stefan

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Moby ist schon ein Phänomen. Obwohl ihn C++ offenbar überhaupt nicht 
interessiert und er keine Lust hat, sich damit auseinanderzusetzen, 
scheinen ihn Threads zu dem Thema geradezu magisch anzuziehen. Da er 
keine Ahnung davon hat, kann er aber nicht mitreden, also versucht er 
den Thread in Richtung des einzigen Themas zu ziehen, das er kennt.
Ich weiß ja nicht, was so der Normalfall ist, aber wenn ich am Titel 
eines Threads erkenne, daß es um ein Thema geht, das mich nicht 
interessiert, dann öffne ich ihn erst gar nicht.

Autor: C(++) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> @C++:
> Du solltest mal Deinen Ironie-Detektor neu kalibrieren ...
>
> Gruß, Stefan

Auch so kann man sich rausreden.

Autor: Marian b (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deja VU...

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@C++: Stefan hat mich aber richtig interpretiert!

Autor: C(++) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt, auch so kann man sich rausreden...

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
humorloses Teil ...

Autor: Moby (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Moby ist schon ein Phänomen.

Stimmt. Die Übersichlichkeit der 8-Bitter, kombiniert mit der 
Einfachheit ihrer Asm-Programmierung ist ein Phänomen. Da langt doch 
die Kenntnis von ein paar primitiven Asm-Codes und der Innereien eines 
AVR tatsächlich schon aus, die Mehrzahl der Bastlerprojekte hier ohne 
großes Studium der OOP-Wissenschaften zu realisieren. Ganz ohne 
Kenntnis, Abhängigkeit und falscher Anwendung von irgendwelchen dieser 
hunderttausend normierten Sprachelemente und Libraries. Ganz ohne 
Kenntnis der Besonderheiten irgendwelcher Compiler. Ganz ohne die 
Notwendigkeit von ressourcenfressenden Abstraktion-Layern und ähnlicher 
Hilfskonstruktionen. Einfach, transparent, effektiv, flexibel, sparsam, 
direkt, die Hardware allumfassend wird mit Asm das zum Ausdruck gebracht 
was Sache- und allein notwendig ist. Und die Zeit für das Studium 
tausendseitiger Handbücher und beständiges Nachlernen fließt in die 
eigentliche Projektentwicklung ;-)

Was tut man nun bei dieser unangenehm eindeutigen Sachlage?
Richtig. Persönlich werden...

Autor: Moby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Glaubst du ernsthaft dir verkauft
> in 20 Jahren noch irgendwer einen AVR zu ähnlichen Preisen wie heute?
> Auch noch in DIP?

Auch in 20 Jahren sind die 8-Bitter samt AVRs noch aktuell.
Glaubst Du ernsthaft es könnte nicht so sein?

temp schrieb:
> Ich denke zu der Zeit wirst du dann hier predigen, dass der
> arm-Assembler das einzig wahre ist...

Gewiss nicht!
Das würde ja voraussetzen, die komplexe 32-Bit ARM Technik sei für alle 
Problemstellungen das einzig wahre ...

Autor: Moby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven schrieb:
> Welchen Controller + IDE + Compiler könnt ihr mir empfehlen?

Du nimmst natürlich einen 32-Bit ARM!
Dann hast Du Spielraum genug für ineffizientes Programmieren ;-)

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby schrieb:
> Was tut man nun bei dieser unangenehm eindeutigen Sachlage?
> Richtig. Persönlich werden...

Ja wenn jemand so penetrant alles mögliche behauptet ohne zu Wissen 
wovon er überhaupt redet, dann wirds nun mal persönlich. Du forderst es 
ja auch immer heraus, indem du immer versuchst Threads zu kapern und ins 
Off-Topic zu treiben. Also was machst du in einem C++ Thread?

Autor: C(++) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby schrieb:
> Mehrzahl der Bastlerprojekte hier ohne
> großes Studium der OOP-Wissenschaften zu realisieren.
Kann ich in C auch.

> falscher Anwendung von irgendwelchen dieser
Ich glaube ASM Mnemonics kann man auch falsch anwenden.

> hunderttausend normierten Sprachelemente und Libraries.
C hat vllt. 50 Schlüsselwörter und die meisten Bibliotheken verwendet 
man auf einem µC eh kaum und wenn sie einem nicht gefallen kann man die 
Funktionen auch selbst implementieren.

> Kenntnis der Besonderheiten irgendwelcher Compiler.
Ist bei Assemblern das gleich, wenn man aber nie aus seiner kleinen, 
engstirnigen rauskommt fällt einem das natürlich nicht auf.

> ressourcenfressenden Abstraktion-Layern
Ressourcenfressenden muss er aber nicht sein, der im oben genannten One 
Wire C-Code braucht genau 1 ASM Befehl pro IO Zugriff.

> Einfach
Geht schon, implementier mal eine 32bit Division in ASM. In C dauert das 
keine 5 Sekunden.

> effektiv, flexibel, sparsam
In welcher Beziehung?

> Hardware allumfassend wird mit Asm das zum Ausdruck gebracht
> was Sache- und allein notwendig
und unter Umständen zu wenig um effektiv zu Arbeiten
> ist

> Und die Zeit für das Studium tausendseitiger Handbücher
Knapp 300 Seiten K&R...
> und beständiges Nachlernen
Wenn sich eine Sprache nicht weiterentwickelt wird man immer auf dem 
Stand von dem Tag als sie erfunden wurde bleiben. Nicht mit der Zeit zu 
gehen geht in C und ASM gleich einfach.

Autor: TriHexagon (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Achso, wenn du glaubst das Prinzip "sie hassen dich, weil du die 
Wahrheit sagst" gilt hier, dann liegst du falsch.

Viele hier kennen nämlich, im Gegensatz zu dir, beide Seiten der 
Medaille, also ASM- und C-Programmierung.

Autor: Moby (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
TriHexagon schrieb:
> Achso, wenn du glaubst das Prinzip "sie hassen dich, weil du die
> Wahrheit sagst" gilt hier, dann liegst du falsch.

Ach was. Soo schlimm ist es auch wieder nicht.

> Viele hier kennen nämlich, im Gegensatz zu dir, beide Seiten der
> Medaille, also ASM- und C-Programmierung.

Dann bin ich ja beruhigt wenn damit nun erwiesen ist, daß wenigstens 
Du alle Seiten kennst ;-)

> Also was machst du in einem C++ Thread?

Feststellen, daß OOP auf einem kleinen Controller nix verloren hat.
Entschuldigung, das Salz werde ich in diese Wunde weiter streuen ;-)

Autor: Marian  . (phiarc) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Moby schrieb:
>> Also was machst du in einem C++ Thread?
>
> Feststellen, daß OOP auf einem kleinen Controller nix verloren hat.
> Entschuldigung, das Salz werde ich in diese Wunde weiter streuen ;-)

Du streust hier gar nix nirgendwo rein, du nervst einfach nur.

Autor: Ulrich F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby schrieb:
> das Salz werde ich in diese Wunde weiter streuen
Was hast du falsch gemacht, dass du wie Sisyphos diesen großen Stein 
bergauf rollen musst?

Und nein, das ist kein Salz in Wunden...
Zumindest nicht in meine
In deine vielleicht....
Eine Form der Selbstkasteiung?

Autor: Moby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TriHexagon schrieb:
> Ja wenn jemand so penetrant

Mein Gott, ich verstehs ja. Da hat sich jemand eine großartige 
Entwicklungsumgebung aufgebaut, jahrelang mit 1000 Seiten Schmökern 
gepaukt, womöglich studiert und muss sich nun von einem dahergelaufenen 
Bastler sagen lassen, daß sich eine große Abzahl an typischen 
Programmieraufgaben mit ein paar Asm-Wortfetzen erschlagen lassen. Das 
ist wirklich penetrant...

C(++) schrieb:
> Wenn sich eine Sprache nicht weiterentwickelt wird man immer auf dem
> Stand von dem Tag als sie erfunden wurde bleiben.

Ja sicher. Sich nicht weiterentwickeln, das hat was Anrüchiges. Ich bin 
jedoch der Überzeugung, daß sich viele Problemlösungen nicht durch 
immerfort verfeinernde= verkomplizierende Hochsprachen, sondern nur 
durch intelligentere, simpler programmierbarere Hardware vereinfachen 
lassen.
Das läuft mit aktueller 32 Bit Technik leider in die andere Richtung... 
Also bleibt AVR & ASM weiter der einfachste Zugang.

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby schrieb:
>> Also was machst du in einem C++ Thread?
>
> Feststellen, daß OOP auf einem kleinen Controller nix verloren hat.
> Entschuldigung, das Salz werde ich in diese Wunde weiter streuen ;-)

Du solltest lieber Feststellen, dass C++ nicht gleich OOP ist, denn C++ 
beherrscht mehrere Paradigma unter anderem prozedurale Programmierung. 
Also genau das was du da mit ASM machst.

Außerdem bietet C++ auch OOP Elemente an, die keinen zusätzlichen 
Overhead im Vergleich zu einer reinen prozeduralen Implementierung 
bieten.

Aber warum versuche ich dir das zu erklären, mit C/C++/OOP willst du 
dich gar nicht auseinandersetzen, sondern nur drüber reden. Bei dir ist 
die Welt schwarz und weiß. Arme Seele...

Autor: asdf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lieber Moby,

"Die Grenzen meiner Sprache sind die Grenzen meiner Welt" (Wittgenstein)

Autor: Moby (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
TriHexagon schrieb:
> Bei dir ist
> die Welt schwarz und weiß.

Richtig. Weiß ist die Lösung mit dem geringsten Aufwand...

Ich bin ja begeistert davon was C++ alles anbietet...
Nur hast Du mit Deinen redlich bemühten Ausführungen meinen eigentlichen 
Kritikpunkt immer noch nicht begriffen: Genau das ist zuviel! Genau das 
ist unnötig kompliziert! Und füllt deshalb auch tausend Bücher!

Die arme Seele ist doch eher der, der das für die gegebenen 
Problemstellungen unnütz pauken musste...

Autor: Ulrich F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby schrieb:
> Richtig. Weiß ist die Lösung mit dem geringsten Aufwand...

Dann ist Weiß:
Arduino erwerben IDE auf den PC drauf, bisschen C++ rein hacken, 
aufspielen und fertig.
Mit weniger Aufwand gehts kaum.

Oder einen Raspberry....
Der bringt schon alles mit, bzw. ist der Kram leicht nachzuinstallieren.

Und ja, um alle Vorzüge des C++ auskosten zu können ist der 32Bitter 
kein schlechte Wahl. Mit irgend einem OS drauf.

Autor: TriHexagon (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Moby schrieb:
> Nur hast Du mit Deinen redlich bemühten Ausführungen meinen eigentlichen
> Kritikpunkt immer noch nicht begriffen: Genau das ist zuviel! Genau das
> ist unnötig kompliziert! Und füllt deshalb auch tausend Bücher!

Nein du kappierst es nicht. Woher willst du denn eigentlich wissen, was 
das für ein Aufwand ist? Du hast doch keinen blassen Schimmer von C++.

Du schaust dir Code an, sagst das ist viel zu kompliziert, ohne zu 
verstehen was er überhaupt macht, dann siehst du Bücher mit mehreren 
hundert Seiten und schließt daraus: das ist viel zu kompliziert, das 
lohnt sich nicht.

Tut mir leid, dass ist an Oberflächlichkeit nicht zu überbieten. Machst 
du das im Leben immer so?

Fremdsprachen erscheinen zunächst auch immer als extrem kompliziert. Bis 
man mal anfängt diese zu lernen. Plötzlich erkennt man Gesetzmäßigkeiten 
und die Sprache wird immer intuitiver, bis man sie flüssig und ohne 
aktiv nachzudenken sprechen kann. Erst dann kann man erkennen, dass die 
eigene Muttersprache Deutsch an vielen Stellen komplizierter und 
umständlicher ist, als z.B. Englisch. Aber keine Angst, eine 
Programmiersprache zu lernen ist nicht so aufwändig wie eine 
Fremdsprache. Und wenn man erst einmal eine imperative Hochsprache 
gelernt hat, ist es zum Teil gar kein Aufwand mehr eine neue zu lernen.

Autor: Decius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich ist eigentlich bei dieser Diskussion jedes Wort zuviel. 
Denn diese immer wieder aufbrandende Diskussion, riecht sehr streng nach 
absichtlicher Provokation.

Direkt nach dem Studium 1999 hab ich auch noch, in Assembler auf 8Bit 
Mikrocontroller meine ersten Projekte verwirklicht. Hätte ich das aber 
so beibehalten, hätte ich wohl in der damaligen Firma nicht lange 
überlebt. Die Produktzyklen werden immer kürzer. Man kann lange 
theoretische Diskussionen führen. Fakt ist, die praktische Erfahrung 
zeigt, dass Projekte in Hochsprachen um ein Vielfaches schneller zu 
erstellen sind. Ausserdem ist Assembler im Bereich der 
sicherheitsrelevanten Software keine akzeptierte Sprache.

Aktuell je nach Anforderung haben wir 3 unterschiedliche 
Mikrocontrollerfamilien von mehreren Herstellern im Einsatz. Es kommt 
nur auf die geforderte Funktion und geringe Kosten an. Wobei die Kosten 
bei gleicher gebotener Funktionalität dann abschliessend entscheiden.

Wichtig für uns ist also die Portierbarkeit auf andere Hardware. Damit 
fällt Assembler aus, sonst ist diese Möglichkeit nicht gegeben. 
Assembler sind immer, hardwareabhängig. Es gibt nur einen Punkt bei dem 
Assembler interressant wird. Der Geschwindigkeitsoptimierung einzelner 
Routinen in Form von Inline Assembler Anweisungen. Wobei das auch immer 
unterinteressanter wird. Warum?

Ganz einfach! Wenn ich eine Rolle ARM Cortex M3 für 1$ das Stück 
bekomme, dann werde ich kaum einen vergleichbaren proprietären 8Bitter 
zum vierfachen Preis einsetzen. Ob dabei der 32Bitter überdimensioniert 
ist, ist total uninteressant. Sein Gehäuse muss ja nicht grösser sein.

Bei dem Ganzen denkt aber nicht an Trivial-Beispiele! Geht lieber von 
Projekten in der Grössenordnung eines CANopen-Stacks aus. Dann reden wir 
schon eher, von einer realen Projektgrössenordnung. Ddie Komplexität der 
embedded Softwäre ist im laufe der Zeit kontinuierlich am Steigen.

Dennnoch sehe ich die 8Bitter auch nicht verschwinden. In einigen 
Bereichen werden sie sich sicher halten. Dabei denke ich an 
Mikrocontroller mit 3 oder 4 Pins z.B. So kleine Projekte kommen in 
meiner beruflichen Praxis aber nur in Ausnahmefälle vor.

Inwieweit das oben Geschriebene für Andere auch gilt, muss jeder selbst 
entscheiden. Irgendwann sollte man fruchtlose Diskussionnen einfach mal 
sein lassen. Es ist nunmal so, das in jedem Projekt je nach Anforderung 
die Werkezeuge neu ausgewählt werden. Wenn das 8Bit Mikrocontroller und 
Assembler bedeutet, ok warum nicht. Daraus aber eine allgemeingültige 
Regel machen zu wollen, ist einfach nur fachlicher Blödsinn. Sorry, aber 
das musste ich jetzt so deutlich schreiben.

Autor: A. H. (ah8)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Moby schrieb:
> Mein Gott, ich verstehs ja. Da hat sich jemand eine großartige
> Entwicklungsumgebung aufgebaut, jahrelang mit 1000 Seiten Schmökern
> gepaukt, womöglich studiert und muss sich nun von einem dahergelaufenen
> Bastler sagen lassen, daß sich eine große Abzahl an typischen
> Programmieraufgaben mit ein paar Asm-Wortfetzen erschlagen lassen.

Hm, der durchschnittliche deutsche Muttersprachler verfügt über einen 
Wortschatz von etwa 7000 Worten. Eine Goethe brachte es auf etwa 21000.

Mir kam gerade unweigerlich das Bild eines dahergelaufenen Bastlers in 
den Sinn, der einem Herrn Goethe zu erklären versucht, man könne doch 
auch mit ein paar Wortfetzen durchs Leben kommen. Was zweifellos stimmt! 
Denn schließlich hatte auch ein Goethe gezweifelt. (Stand er doch 
letztlich da, der arme Thor, und fühlte sich so klug als wie zuvor.)

Aber hätte ihn das Argument wirklich überzeugt? Oder wäre ihm, der ja 
auch als etwas überheblich und humorlos galt, nicht eher der schöne 
Spruch in den Sinn gekommen von der guten alten Eiche, die es kaum 
stört, wenn sich die Sau ihr scheuert? Und prompt formte sich das 
nächste Bild vor meinem geistigen Auge, diesmal das einer Sau, die sich 
neben der Eiche aufbaut und lautstark insistiert, es habe die Eiche 
gefälligst zu stören.

Ich bitte allseits um Entschuldigung, eigentlich hatte ich mir fest 
vorgenommen, zum weiteren Verlauf dieses Threads zu schweigen, aber bei 
diesem Bild konnte ich einfach nicht mehr widerstehen.

Lieber Moby, es liegt mir fern Dich beleidigen oder bloß stellen zu 
wollen. Es geht mir einfach darum einmal Feedback zu geben, wie solche 
Äußerungen auf mich wirken. Kann sein, dass das anmaßend meinerseits 
ist, kann sein, dass eigentlich ich die Sau bin und Du die Eiche, und 
dass die Assoziationen, die sich unwillkürlich bei mir bilden nur auf 
meine eigene geistige Beschränktheit zurück zu führen sind. Zumindest 
scheine ich damit aber nicht alleine zu sein. Du hast jedes Recht, meine 
Meinung zu ignorieren und Du hast selbstverständlich jedes Recht, Deine 
Meinung hier kund zu tun. Ich teile sie nicht, aber ich werde sie 
respektieren. Aber der Welt erklären zu wollen, was richtig und was 
falsch ist ist mindestens ein sehr gewagtes Unterfangen und kann schnell 
ins Lächerliche abgleiten. Ich fürchte sagen zu müssen, das nach meinem 
Eindruck dieser Punkt bereits überschritten ist.

Nun verzeihe man mir die vielen Worte, ein paar Fetzen hätten vielleicht 
auch genügt, aber das wäre möglicherweise unhöflich gewesen.

: Bearbeitet durch User
Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnt Ihr die Frage "Assembler vs. Hochsprachen" bitte privat klären?

Das Ganze wurde nun schon x-mal durchgekaut und hat genug Threads 
kaputtgemacht - es ist mir auch unverständlich, warum immer noch Leute 
darauf eingehen.

Weitere Beiträge dazu werde ich ab hier löschen.

Nochmal zur Erinnerung - die Frage war:

Welchen Controller für C++ Programmierung?

Danke.

: Bearbeitet durch Moderator
Autor: Hans W. (hans-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann mach lieber gleich den Thread zu... der 2. Post war bereits die 
Antwort!

Vielleicht noch eine Anmerkung: Sobalds einen Compiler gibt, gibts 
keinen Grund ihn nicht zu verwenden.

73

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast eigentlich Recht.

Ich mache hier mal zu. Wenn noch irgendjemand Erhellendes zum 
eigentlichen Threadthema beizutragen hat, kann er sich ja melden.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.