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.
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.
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ß).
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
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.
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++. :-)
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?
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.
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.
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.
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
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.
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
...)
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.
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!“)
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).
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.
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?
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.
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
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 ;-)
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
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,
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. :-(
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.
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.
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.
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.
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.
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.
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.
"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
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.
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?
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.
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)
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.
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.
@ 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.
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)
@ 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)
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,
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.
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 :-)
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.
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.
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.
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.
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.
> 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?
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
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.
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.
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.
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.
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.
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
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:
1
// ungetestet
2
structmenu;
3
structmenu{
4
char*name;
5
structmenu*submenu;
6
};
7
structmenumenu={
8
.name="test",
9
.menu=(structmenu[]){
10
{
11
.name="a"
12
},{
13
.name="b"
14
}
15
}
16
};
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.
1
// ungetestet
2
structx{
3
int*a,*b,*c;
4
};
5
voidfunc(structxx){
6
}
7
#define func(...) func((struct x){VA_ARGS})
8
9
///////////
10
11
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.
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.
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?
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 :-)
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.
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.
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. ;-)
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:
1
// ungetestet
2
#define MENU_ITEMS(x) \
3
.items = x, \
4
.count = sizeof x
5
6
structmenu;
7
structmenu{
8
char*name;
9
structmenu*items;
10
unsignedcount;
11
};
12
13
structmenumenu={
14
.name="test",
15
MENU_ITEMS(((structmenu[]){
16
{
17
.name="a"
18
},{
19
.name="b"
20
}
21
}))
22
};
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.
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?
> 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.
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.
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
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.
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.
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.
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.
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 ....
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.
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.
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.
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 .
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.
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
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 :-)
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
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.
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. :)
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.
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.
.. 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.
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.
..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..
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.
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?
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?
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.
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
@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?
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.
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.
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...
> 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?
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 ;-)
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...
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.
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.
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.)
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
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.
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...
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 ...
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 ;-)
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?
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.
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.
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 ;-)
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.
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?
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.
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...
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...
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.
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.
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.
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.
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.
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
Thread beobachten
Seitenaufteilung abschalten