mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Buch für C-Einstieg


Autor: C-Neuling (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Moin,

Ich bin seit Ewigkeiten in Elektronik unterwegs, dann kam C-Control 
(Basic) und dann AVR mit Bascom. In der Jugend hatte ich mal Basic und 
Pascal gelernt, da fiel der Wiedereinstieg nicht schwer.
Die AVR-8 kenne ich sehr gut und programmiere sehr hardwarenah (ja, das 
geht sehr wohl mit Bascom), wohl seit nunmehr 15 Jahren.
Jetzt will ich endlich mal auf C umsteigen.
Da fehlt mir einfach der Einstieg und die meisten Bücher ziehen es für 
mich komplett unpassend auf.
Entweder wird C vorrausgesetzt (da habe ich fast 0 Vorkenntnisse) oder 
es wird beim µC und der Elektronik drumherum bei Adam und Eva angefangen 
(brauche ich kein Stück).
Alles nach dem Motto "C kann ich, jetzt mal Hardware basteln." Bei mir 
ist es genau umgekehrt.
Passt alles nicht wirklich.
Ich hatte mal ein C-Buch angefangen aber das war viel zu tiefgründig und 
umfangreich. So tief will und muss ich in die Sprache ja gar nicht 
einsteigen.
Speziell für Umsteiger wird es da kaum was geben aber ein Buch, das 
zumindest bei C von Null startet und dann nur auf das eingeht, was für 
µC gebraucht wird, das wäre schön. Es darf gerne etwas oberflächlich 
sein. Programmieren kann ich im Prinzip, nur eben nicht C.
Also alles was über einfaches Basic hinausgeht. Dazu vielleicht noch 
Einführung ins Atmel-Studio, was ja auch nicht gerade intuitiv ist, wenn 
man keinen Schimmer hat.
Klar ist, daß ich da etliche Dinge überspringen muss (was ist ein Timer) 
aber damit muss ich dann leben.
Es geht einfach erstmal darum einen Einstieg in C zu finden. Details 
kann ich dann selber erarbeiten/fragen.

Hat da Jemand einen heissen Tipp?

Oder ganz anders vorgehen?

Autor: Klaus R. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Frank G. (frank_g53)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
C-Neuling schrieb:
> Es geht einfach erstmal darum einen Einstieg in C zu finden.

http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/...

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C-Neuling schrieb:

> Oder ganz anders vorgehen?

Schau Dir mal den Vortrag an:

Youtube-Video "CppCon 2015: Kate Gregory “Stop Teaching C""

Starte direkt mit C++ auf einer hohen Abstraktionsstufe für non-µC, und 
bewege Dich dann Richtung µC. Am Ende kannst Du auch C ...

Autor: füger (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich kann dir für C und C++ Fragen das Forum c-plusplus.net empfehlen.

Folgendes Buch ist beispielsweise nicht für gutes C geeignet:

Frank G. schrieb:
> C-Neuling schrieb:
>> Es geht einfach erstmal darum einen Einstieg in C zu finden.
>
> http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/...

Wilhelm M. schrieb:
> Starte direkt mit C++ auf einer hohen Abstraktionsstufe für non-µC, und
> bewege Dich dann Richtung µC. Am Ende kannst Du auch C ...

Das ist tatsächlich keine schlechte Idee, wenn du Programmieren 
allgemein lernen willst. Da bietet C++ mehr Konzepte, die die Sprache 
allerdings auch viel aufwendiger zu lernen macht. Wenn es dir aber nur 
um die Programmierung von µC mit C geht, dann ist das nicht so sinnvoll, 
weil du dann nur vieles vermissen wirst, was du aus C++ kennst und du 
das Meiste eigentlich gar nicht brauchst. Wenn du C++ lernen willst, 
dann besorg dir am besten "Der C++ Programmierer" von Breymann. Der ist 
sehr gut.

Zu empfehlen ist für C " The C Programming Language". Das ist allerdings 
Englisch.

Autor: 1234567890 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
füger schrieb:
> Folgendes Buch ist beispielsweise nicht für gutes C geeignet:
>
> Frank G. schrieb:
>> C-Neuling schrieb:
>>> Es geht einfach erstmal darum einen Einstieg in C zu finden.
>>
>> http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/...

Wenn du nur einen Einstieg in C willst, dann mach das ohne einen 
Mikrocontroller auf dem PC z.B. in der Konsole. Das geht relativ 
schnell. und das Buch ist dafür sehr wohl geeignet. Es ist kein 
besonders gutes Buch, aber es reicht für einen Anfänger vollkommen aus. 
Nachdem du dich mit der Sprache vertraut gemacht hast, versuchst du das 
gelernete auf dem uC anzuwenden und schaust dir einfach ein paar kleine 
Beispiele von anderen an.

Autor: füger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
1234567890 schrieb:
> Wenn du nur einen Einstieg in C willst, dann mach das ohne einen
> Mikrocontroller auf dem PC z.B. in der Konsole. Das geht relativ
> schnell. und das Buch ist dafür sehr wohl geeignet. Es ist kein
> besonders gutes Buch, aber es reicht für einen Anfänger vollkommen aus.
> Nachdem du dich mit der Sprache vertraut gemacht hast, versuchst du das
> gelernete auf dem uC anzuwenden und schaust dir einfach ein paar kleine
> Beispiele von anderen an.

Klar fängt man auf dem PC an. Alles andere ist schwachsinnig.
Allerdings mit einem GUTEN Buch.
In dem oben genannten Forum wurden sowohl das C++ Buch als auch das C 
Buch von dem häufiger analysiert und zerrissen. Du musst da nur einmal 
die Suchfunktion verwenden und du findest genug Gründe.
Klar ist es ein Anfängerbuch. Aber wenn man am Anfang alles nur 
mittelmäßig erklärt bekommt, dann versteht man schon die Grundlagen 
nicht, auf denen dann alles aufbaut.

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  aber ein Buch, das
> zumindest bei C von Null startet und dann nur auf das eingeht, was für
> µC gebraucht wird, das wäre schön. Es darf gerne etwas oberflächlich
> sein.

Freunde dich mit Arduino an und schimpfe dann nicht dass zwischen HW und 
dieser Art zu programmieren was fehlt. (ja, das ist C++, nicht was 
Eigenes)

Ansonsten ist dein gewünschter Ansatz ein Trugschluss der nur zu Frust 
führt.
C kann nur erfolgreich praktiziert werden wenn man C gründlich kennt: 
man ist nämlich praktisch genötigt alle Ecken, Kanten und Haken von C zu 
kennen um nicht davon alle paar Zeilen von hinten kalt erwischt zu 
werden.
Gerade wenn man uC von der HW Ebene her mit Register und ASM gut kennt 
hat man gutes Potential diese Ecken, Kanten und Haken von C überhaupt zu 
verstehen.
Auch hilft es 2 oder mehr möglichst unterschiedliche CPU Architekturen 
zumindest etwas zu kennen, das ist nämlich was mit C abstrahiert wird 
indem die Compilerbauer dies einkapseln.

Autor: Volker S. (vloki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Frank G. (frank_g53)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C-Neuling schrieb:
> Hat da Jemand einen heissen Tipp?

Hier wird eins verkauft:
Beitrag "Verkaufe Buecher aus dem Studium"
C - Programmieren von Anfang an, 5 EUR

AVR - Hardware und C-Programmierung in der Praxis, 20 EUR VB

Autor: füger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmiersprachentheaterintendant schrieb:
>>  aber ein Buch, das
>> zumindest bei C von Null startet und dann nur auf das eingeht, was für
>> µC gebraucht wird, das wäre schön. Es darf gerne etwas oberflächlich
>> sein.
>
> Freunde dich mit Arduino an und schimpfe dann nicht dass zwischen HW und
> dieser Art zu programmieren was fehlt. (ja, das ist C++, nicht was
> Eigenes)
>
> Ansonsten ist dein gewünschter Ansatz ein Trugschluss der nur zu Frust
> führt.
> C kann nur erfolgreich praktiziert werden wenn man C gründlich kennt:
> man ist nämlich praktisch genötigt alle Ecken, Kanten und Haken von C zu
> kennen um nicht davon alle paar Zeilen von hinten kalt erwischt zu
> werden.

Auch wenn ich kein Freund von Arduino bin (oftmals eher schlechtes als 
rechtes C++) kann man das wohl tatsächlich am Ehesten empfehlen, wenn 
ich mir noch einmal die oben zitieren Zeilen vom Threadstarter 
durchlese.
Halte dich mit dieser Einstellung von ASM, C und C++ lieber fern. Da 
kann man zu viel falsch machen.

Autor: Drrrtrr (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Frank G. schrieb:
> C-Neuling schrieb:
> Es geht einfach erstmal darum einen Einstieg in C zu finden.
>
> http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/...

War das nicht eine Ansammlung an Fehlern und Bad Practices?

Autor: füger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Drrrtrr schrieb:
> Frank G. schrieb:
>> C-Neuling schrieb:
>> Es geht einfach erstmal darum einen Einstieg in C zu finden.
>>
>> http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/...
>
> War das nicht eine Ansammlung an Fehlern und Bad Practices?

Ja.

Autor: Frank G. (frank_g53)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich selbst bin mit diesem Buch eingestiegen:
https://www.rheinwerk-verlag.de/grundkurs-c-c-prog...
Ist das das gleiche wie "a-z..."?

Zusätzlich habe ich noch dieses:
http://www.hanser-fachbuch.de/buch/Programmieren+i...

Autor: +/- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C-Neuling schrieb:

> Es geht einfach erstmal darum einen Einstieg in C zu finden. Details
> kann ich dann selber erarbeiten/fragen.


Wie wärs mit damit:
http://www.netzmafia.de/skripten/

Programmieren in C
http://www.netzmafia.de/skripten/programmieren/index.html

Autor: füger (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank G. schrieb:
> Ich selbst bin mit diesem Buch eingestiegen:
> 
https://www.rheinwerk-verlag.de/grundkurs-c-c-prog...
> Ist das das gleiche wie "a-z..."?

Nicht das gleiche Buch, aber der gleiche unfähige Autor.
Ich glaube kaum, dass der in dem Buch plötzlich besser C kann.

Frank G. schrieb:
> Zusätzlich habe ich noch dieses:
> http://www.hanser-fachbuch.de/buch/Programmieren+i...

Das kenne ich ehrlich gesagt nicht. Kann ich also überhaupt nicht 
beurteilen.

Autor: 1234567890 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Drrrtrr schrieb:
> War das nicht eine Ansammlung an Fehlern und Bad Practices?

Ja, aber programmieren kann er doch schon. Und um zu sehen, wo er eine 
Klammer setzen muss, wie if ... else ..., eine Schleife und ein 
header-file funktioniert, reicht es allemal.

Wenn er soweit ist, kann er selber ein Buch raussuchen, da er weiß, was 
er sucht.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1234567890 schrieb:
> Drrrtrr schrieb:
>> War das nicht eine Ansammlung an Fehlern und Bad Practices?
>
> Ja, aber programmieren kann er doch schon. Und um zu sehen, wo er eine
> Klammer setzen muss, wie if ... else ..., eine Schleife und ein
> header-file funktioniert, reicht es allemal.
>
> Wenn er soweit ist, kann er selber ein Buch raussuchen, da er weiß, was
> er sucht.

Moin,

Ich glaube hier wurde mein Bedarf bisher am besten verstanden.
Was hat es mit den Header-Files auf sich, das Makefile, solche 
Eigenheiten die ich nicht kenne.
Datentypen, Volatile und natürlich die Syntax.
Ich habe mir jetzt -noch- nicht alle Empfehlungen angesehen aber vieles 
geht doch in Richtung einer Bibel.
Ich brauche das eigentlich nur als Mittel zum Zweck für µC und C++ werde 
ich sicher nicht mehr lernen. Damit dürfen sich unsere Softwerker mit 
rumschlagen.
Ich habe es mal mit Java versucht (gierig mal was für Android zu 
schreiben) und habe frustriert aufgegeben. Das ist nicht meins.

Arduino ist ganz sicher komplett die falsche Richtung denn die Hardware 
kenne ich in- und auswendig. PWM, ADC - alles keine Gegner, da nutze ich 
die Funktionen von Bascom nur seltenst aus Faulheit bei ganz banalen 
Dingen.

Ich würde jetzt sagen, ich will nicht viel anders als in Bascom 
programmieren, nur eben in C. Rein prozedual und hardwarenah.

Ja, ich habe die Einwände gelesen, daß man da in Fallen tappen kann aber 
für solche Spirenzien habe ich noch Backup - mind. 2-3 C-Spezis, die ich 
fragen kann.

Vielleicht hätte ich noch erwähnen sollen, daß man mit Ende 40 ganz 
anders lernt als ein Student. Zum einen viel langsamer und viel mehr auf 
der Erfahrung basierend.
Von der Pike auf lerne ich C sicher nicht mehr, ich will es nur 
anwenden.
Daß man da Zusammenhänge verstehen muss ist klar aber sicher nicht mit 
einem Wälzer von 1200 Seiten.

Ich habe mir erstmal das hier bestellt (weil vorhin lange erstmal gar 
keine Antwort kam):
https://www.amazon.de/dp/3836241145/ref=pe_3044161...

Vielleicht lasse ich mir das Studio dann einfach mal grob von einem 
Kollegen erklären.

Ich sehe mir aber alle Tipps nochmal genauer an, versprochen!

Gruß,
Norbert

Autor: Herr B. (herr_barium)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Ich würde jetzt sagen, ich will nicht viel anders als in Bascom
> programmieren, nur eben in C.

Wenn Dich niemand zwingt, dann bleib doch beim Erprobten und Bekannten. 
Eventuell gibst Du nur einen Haufen Geld für Bücher aus, die dann nur 
dazu dienen, das Sofa 5 cm höher zu stellen.

C enthält soviele Fallen und Untiefen, so daß Du (trotz der Bücher) bald 
festhängst und hier fragen mußt. Was es dann für Antworten hagelt...
Das braucht man sicher nicht!

Autor: Drrrtrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1234567890 schrieb:
> Drrrtrr schrieb:
> War das nicht eine Ansammlung an Fehlern und Bad Practices?
>
> Ja, aber programmieren kann er doch schon. Und um zu sehen, wo er eine
> Klammer setzen muss, wie if ... else ..., eine Schleife und ein
> header-file funktioniert, reicht es allemal.
>
> Wenn er soweit ist, kann er selber ein Buch raussuchen, da er weiß, was
> er sucht.

Worin liegt der Sinn etwas falsch zu erlernen? Ist doch Unsinn.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Herr B. schrieb:
> Norbert S. schrieb:
>> Ich würde jetzt sagen, ich will nicht viel anders als in Bascom
>> programmieren, nur eben in C.
>
> Wenn Dich niemand zwingt, dann bleib doch beim Erprobten und Bekannten.
> Eventuell gibst Du nur einen Haufen Geld für Bücher aus, die dann nur
> dazu dienen, das Sofa 5 cm höher zu stellen.
>
> C enthält soviele Fallen und Untiefen, so daß Du (trotz der Bücher) bald
> festhängst und hier fragen mußt. Was es dann für Antworten hagelt...
> Das braucht man sicher nicht!

Moin,

Hach, wie gerne würde ich und wie Recht hast Du!
Ich werde aber gezwungen.
Es ist nicht mein Hauptjob aber etwas programmieren will und sollte ich 
in der Firma schon weiterhin. Bisher habe ich da alles in Bascom 
gemacht. Früher mal als One-man-show in Hard- und Software. Eigentlich 
mache ich nun nur noch Hardware aber eben auch mit Software dran.
Und sei es nur, um für Tests an der Software unserer Experten 
herumzujustieren.
Speziell neue Projekte sollen nur noch in C gemacht werden.
Ich komme also nicht drumherum.

Ob ich privat auch auf C umsteige überlege ich mir dann wirklich noch 
gründlich.

Von daher auch die leicht eingeschränkten Anforderungen, die ich habe. 
Das ist ein Spezialfall.

Gruß,
Norbert

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Auch wenn ich kein Freund von Arduino bin (oftmals eher schlechtes als
> rechtes C++)
Das trifft auf das ganze C/C++ Ökosystem zu: gerade weil man, um guten 
Code in diesen Sprachen schreiben zu können, so viel intus, präsent und 
im Griff haben muss, sind echte Könner nicht häufig. Egal ob im 
professionellen Bereich oder nicht.
Weil dann soviel anfälliger Code herumliegt (Memory leaks, Buffer 
overruns, uva.) ist viel nacharbeiten nötig.
Meine Behauptung ist nach wie vor dass der Arbeitsmarkt um C/C++ so 
gross ist, nicht weil diese Sprachen so gut sind (gut!=mächtig), sondern 
weil sie so anspruchsvoll zu beherrschen sind.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert S. schrieb:
>
> Moin,
>
> Ich glaube hier wurde mein Bedarf bisher am besten verstanden.
> Was hat es mit den Header-Files auf sich, das Makefile, solche
> Eigenheiten die ich nicht kenne.

Makefiles haben ja auch nichts mit C, etc. zu tun, und make versteht 
wieder eine eigene, regelbasierte Sprache. Natürlich lohnt es sich, sich 
mit make auseinanderzusetzen.

> Datentypen, Volatile und natürlich die Syntax.

Datentypen sind das wichtigste an einer (streng-typisierten) Sprache. 
Leider kann man in C keine eigenen Datentyen definieren. Und das ist ein 
super-großer Nachteil.

Syntax - naja, Syntax kommt und geht ;-)

> Ich brauche das eigentlich nur als Mittel zum Zweck für µC und C++ werde
> ich sicher nicht mehr lernen.

Warum solltest Du nicht C++ lernen. Hast Du den Eindruck, C++ ist 
schwerer als C? Warum? Wer hat Dir diesen Eindruck vermittelt?

> Ich habe es mal mit Java versucht (gierig mal was für Android zu
> schreiben) und habe frustriert aufgegeben. Das ist nicht meins.

Warum. Bei Java frustriert man eigentlich nur, wenn man große 
Softwareprojekte macht. Und dann nicht an der Sprache, sondern an 
vielen, oft schlechten Bibliotheken. Auf "HelloWorld"-Niveau sind die 
meisten Java-Anfänger ganz begeistert.

> Arduino ist ganz sicher komplett die falsche Richtung denn die Hardware
> kenne ich in- und auswendig.

Vielleicht solltest Du dann Assembler machen. Kein Stress mit 
Datentypen, type-qualifiern wie volatile oder Syntax in Blockstruktur...

> Ich würde jetzt sagen, ich will nicht viel anders als in Bascom
> programmieren, nur eben in C. Rein prozedual und hardwarenah.

Ich verstehe immer weniger, warum überhaupt dann C lernen willst. Wenn 
dann Arbeitgeber will, dann lass Dir ein paar Schulungen verpassen!

> Vielleicht hätte ich noch erwähnen sollen, daß man mit Ende 40 ganz
> anders lernt als ein Student.

Du bist ja noch ganz jung!

> Von der Pike auf lerne ich C sicher nicht mehr, ich will es nur
> anwenden.

Anwenden ohne zu erlernen?

Insgesamt sprichst Du für mich jetzt doch in Rätseln.

Autor: wolter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wo gibt es was über einen funktions mapper?

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Norbert S. schrieb:
>>
>> Moin,
>>
>> Ich glaube hier wurde mein Bedarf bisher am besten verstanden.
>> Was hat es mit den Header-Files auf sich, das Makefile, solche
>> Eigenheiten die ich nicht kenne.
>
> Makefiles haben ja auch nichts mit C, etc. zu tun, und make versteht
> wieder eine eigene, regelbasierte Sprache. Natürlich lohnt es sich, sich
> mit make auseinanderzusetzen.
>
>> Datentypen, Volatile und natürlich die Syntax.
>
> Datentypen sind das wichtigste an einer (streng-typisierten) Sprache.
> Leider kann man in C keine eigenen Datentyen definieren. Und das ist ein
> super-großer Nachteil.
>
> Syntax - naja, Syntax kommt und geht ;-)
>
>> Ich brauche das eigentlich nur als Mittel zum Zweck für µC und C++ werde
>> ich sicher nicht mehr lernen.
>
> Warum solltest Du nicht C++ lernen. Hast Du den Eindruck, C++ ist
> schwerer als C? Warum? Wer hat Dir diesen Eindruck vermittelt?
>
>> Ich habe es mal mit Java versucht (gierig mal was für Android zu
>> schreiben) und habe frustriert aufgegeben. Das ist nicht meins.
>
> Warum. Bei Java frustriert man eigentlich nur, wenn man große
> Softwareprojekte macht. Und dann nicht an der Sprache, sondern an
> vielen, oft schlechten Bibliotheken. Auf "HelloWorld"-Niveau sind die
> meisten Java-Anfänger ganz begeistert.
>
>> Arduino ist ganz sicher komplett die falsche Richtung denn die Hardware
>> kenne ich in- und auswendig.
>
> Vielleicht solltest Du dann Assembler machen. Kein Stress mit
> Datentypen, type-qualifiern wie volatile oder Syntax in Blockstruktur...
>
>> Ich würde jetzt sagen, ich will nicht viel anders als in Bascom
>> programmieren, nur eben in C. Rein prozedual und hardwarenah.
>
> Ich verstehe immer weniger, warum überhaupt dann C lernen willst. Wenn
> dann Arbeitgeber will, dann lass Dir ein paar Schulungen verpassen!
>
>> Vielleicht hätte ich noch erwähnen sollen, daß man mit Ende 40 ganz
>> anders lernt als ein Student.
>
> Du bist ja noch ganz jung!
>
>> Von der Pike auf lerne ich C sicher nicht mehr, ich will es nur
>> anwenden.
>
> Anwenden ohne zu erlernen?
>
> Insgesamt sprichst Du für mich jetzt doch in Rätseln.

Moin,

So eine Antwort hätte ich viel früher erwartet.

Datentypen und Syntax hat Bascom auch, ist bei C nur eben anders. Ok, 
das ist wirklich der leichte Teil.

C++ ist doch OO wie Java, oder?
Ich hatte mir ein Buch so sinngemäss "Java for Android" gekauft. 
Ausdrücklich für Anfänger.
Die Denkweise "OO" wollte mir nicht in den Schädel.

C muss ich lernen. Der Softwerkerkollege sagt "hey, programmieren kannst 
Du doch, [in Bascom eben] ist nur büschn anders in C"
Eigentlich kann ich das auch weitgehend lesen bzw. mir zusammenreimen, 
was der Code macht aber selbst schreiben - da fehlt mir die Grundlage.

Ich muss tatsächlich kein C-Spezi werden. Zum einen geht es wirklich nur 
um AVR-8 und was dann später kommt ist ja jetzt nicht festgelegt.
Erstmal eine 1200-Seitenbibel durchzuackern ist aber keine Option.

Gruß,
Norbert

Autor: Thosch (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Warum nicht das legendäre Original benutzen?

Der "Kerninhan/Ritchie":
https://www.amazon.de/Programming-Language-Prentic...

Gibts auch in deutscher Übersetzung, die ich in Teilen aber weniger gut 
finde, da auch Begriffe wie z.B. "Compiler" als "Übersetzer" übersetzt 
wurden:
https://www.amazon.de/Programmieren-Reference-Manu...

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert S. schrieb:

> Datentypen und Syntax hat Bascom auch, ist bei C nur eben anders.

Worauf ich hinaus wollte, ist, dass Du in C keine eigenen DT definieren 
kannst.

> C++ ist doch OO wie Java, oder?

Klares nein!
C++ ist eine Multiparadigmen Sprache: prozedural/imperativ, OO, 
generisch/metaprogrammatisch, funktional.

> Ich hatte mir ein Buch so sinngemäss "Java for Android" gekauft.
> Ausdrücklich für Anfänger.
> Die Denkweise "OO" wollte mir nicht in den Schädel.

Das ist natürlich schade.

> C muss ich lernen.

na dann, sprich mit Deinem AG! Doch ein AG, der heute (2018) die Devise 
ausgibt, wir machen (ab jetzt) alles nur in C, ist wohl etwas 
engstirnig und wird Dich dann wohl auch nicht auf eine Schulung 
schicken.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> na dann, sprich mit Deinem AG! Doch ein AG, der heute (2018) die Devise
> ausgibt, wir machen (ab jetzt) alles nur in C, ist wohl etwas
> engstirnig und wird Dich dann wohl auch nicht auf eine Schulung
> schicken.

Wieso eigentlich? Mit C++ werden die Möglichkeiten sich ins Bein zu 
schießen potenziert, da man praktisch alle Möglichkeiten von C erbt und 
noch neue hinzukommen. Gerade für Anfänger kann es Sinn machen erstmal 
richtig C zu lernen und dann mit C++ zu erweitern.

Ich habe hier auf meinem Schreibtisch ein 15cm hohen Bücherstapel, die 
ich zwar alle empfehlen kann, aber die alle nur davon handeln, wie man 
vernünftig C++ programmiert. Und die neuen Standards sind damit noch 
nicht einmal abgedeckt:
Meyers - Effective C++
Meyers - More Effective C++
Sutter - Exceptional C++
Sutter - More Exceptional C++
Alexandrescu - Modern C++ Design

Ein Anfänger schreibt 3 Zeilen C++ und macht darin typischerweise 5 
Fehler. Schon die reine C Welt ist nicht ohne.

Autor: Alexander S. (alex998)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Markt verkauft doch einer gerade Bücher, vllt. ist ja was für dich 
dabei? (Nein, ich habe nix mit dem zu tun).

Beitrag "Verkaufe Buecher aus dem Studium"

Autor: Possetitjel (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:

> Die Denkweise "OO" wollte mir nicht in den Schädel.

Das liegt nicht an der OOP, sondern an den beschissenen
Erklärungen.

Objekte sind (digitale) ICs (=abstrakte Automaten).
Methoden sind Signalanschlüsse, die mit der internen
Kombinatorik verbunden sind.
Felder (Membervariablen) sind Flipflops im Innern des IC.

Wirklich fundamental für die OOP ist m.E. nur die
Kapselung und vielleicht die dynamische Instantiierung;
der ganze Vererbungsquatsch ist nur technische Maschinerie.

Informatiker können das aber nicht so erklären, dass
Hardware-Leute das verstehen, sondern müssen das immer
mit Lamda-Kalkülen und Chomsky-Grammatiken verzieren.


> C muss ich lernen. Der Softwerkerkollege sagt "hey,
> programmieren kannst Du doch, [in Bascom eben] ist nur
> büschn anders in C" Eigentlich kann ich das auch
> weitgehend lesen bzw. mir zusammenreimen, was der Code
> macht aber selbst schreiben - da fehlt mir die Grundlage.

Ich bin in einer ähnlichen Lage. Für mich habe ich vier
Teilstrategien festgelegt:

* Es gibt Themen, die man einfach auswendig lernen muss:
  Schlüsselworte, Operatoren, Operatorvorrang, Datentypen.
  Da ist keine Wissenschaft dabei; einfach in Portionen
  zerlegen und auswendig pauken.

* Es gibt Themen, die man gut an vergleichenden Beispielen
  lernen kann. Im Netz streuselt irgendwo ein Artikel
  herum, der einige wichtige Unterschiede zwischen Pascal
  und C an Beispielen erklärt (auf englisch), den finde
  ich extrem nützlich.

* Es gibt schließlich Themen, die eigentlich nur historischen
  Charakter haben. Zahlreiche Eigenschaften von C sind nur vor
  dem historischen Hintergrund verständlich; die Computer-
  und Compilertechnik hatte halt vor 50 Jahren, als C entstand,
  einen ganz anderen Stand als heute.
  Zu diesem Themenkreis gibt es einige gute Diskussionen hier
  im Forum; das findet man i.d.R. nicht in Büchern.

* Lustigerweise ist auch ein gelegentlicher Blick in den
  C-Standard ganz nützlich; dort finden sich z.B. Aussagen
  darüber, welche Kurzschreibweise zu welcher Langform
  äquivalent ist. Hilfreich daran: Wenn es lt. Standard
  ÄQUIVALENT ist, muss ich nur eine der beiden Formen aktiv
  beherrschen.


> Ich muss tatsächlich kein C-Spezi werden. Zum einen geht
> es wirklich nur um AVR-8 und was dann später kommt ist ja
> jetzt nicht festgelegt. Erstmal eine 1200-Seitenbibel
> durchzuackern ist aber keine Option.

Aus meiner eigenen Erfahrung ein kurioser Rat: Lerne Tcl.
Alle wichtigen Steuerstrukturen haben in Tcl dieselbe
Syntax wie in C; wenn Du Deine Scripte auf dem PC in Tcl
programmierst, ist das schonmal eine gute Grundlage für
den nächsten Schritt zu C.

Autor: füger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das bestellte Buch halte ich tatsächlich für einen großen Fehler.
Das ist genauso gut wie (kostenlose) Online-Tutorials. Das wäre mir das 
Geld nicht wert.
Tu dir selbst den Gefallen und lerne es ordenlich. Oder, wenn du nur die 
Syntax lernen willst, lies dir einfach genug Beispiele durch.
Ich verstehe aber ehrlich gesagt nicht dein Ziel.
Wenn du aber schon mit Java überfordert warst, vergiss C++.
C++ ist zwar wunderschön, wenn man alle Mittel (richtig) nutzt, aber 
eben auch unglaublich umfangreich - im Standard, ohne irgendwelche Libs.
C ist da sehr viel kompakter. Aber auch hier gibt es massig Fehler und 
Stolperfallen, auf die man als Anfänger teilweise ausdrücklich 
hingewiesen werden muss, was auch jedes gute Buch macht - das gewählte 
gehört allerdings nicht zu diesen.
Aber letztendlich kann man auch nicht mehr machen als dir raten. Was du 
daraus machst ist deine Sache.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Erstmal ausdrücklich Danke für die ganzen sachlichen Antworten.
Auch die Einwände was meine Zielsetzung angeht nehme ich ernst und kann 
sie verstehen.
Teilweise habe ich mein Ziel aber auch selber nicht ausreichent präzise 
vor Augen, weil ich vermutlich nicht wirklich weiß, was auf mich 
zukommt.
Somit ist es vielleicht auch nicht gut beschrieben.
Insgesamt habe ich einen schönen Korb an Meinungen gesammelt und ich 
habe den Eindruck, daß das alles ziemlich fundiert ist.

Ok, das Buch ist kacke? Kann ich ja mal anlesen und dann immer noch 
wieder verkloppen oder verschenken.
Ich lese aber erstmal lieber analog.

Dann gebt mir bitte etwas Zeit, um alle Tipps durchzusehen.

Klar ist aber: C++ odergar Java ist zumindest jetzt absolut kein Thema.
Daß das Buch über Java bzw. die Erklärungen dazu Scheisse waren glaube 
ich sofort. Das Prinzip wurde einfach nicht erklärt. Aber egal, das ist 
jetzt kein Thema.

Gruß,
Norbert

: Bearbeitet durch User
Autor: Jobst Q. (joquis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thosch schrieb:
> Warum nicht das legendäre Original benutzen?
>
> Der "Kerninhan/Ritchie":
> 
https://www.amazon.de/Programming-Language-Prentic...
>
> Gibts auch in deutscher Übersetzung, die ich in Teilen aber weniger gut
> finde, da auch Begriffe wie z.B. "Compiler" als "Übersetzer" übersetzt
> wurden:
> 
https://www.amazon.de/Programmieren-Reference-Manu...

Damit habe ich auch C gelernt. Da es von den Entwicklern von C 
geschrieben ist, bekommt man auch eine Ahnung davon, was sie sich dabei 
gedacht haben und welche Philosophie dahinter steckt. Ein anderes Buch 
über C habe ich dann nicht mehr gebraucht.

Der Umstieg von BASIC nach C war für mich wie der Wechsel vom Dreirad zu 
einem richtigen Fahrrad. Endlich frei von den ganzen Behinderungen, die 
BASIC angeblich einfach machen sollten. Bereut habe ich nur, das ich 
nicht früher umgestiegen bin.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Was waren das denn z.B. für Einschränkungen bei BASIC, die es bei C dann 
nicht mehr gab?

Gruß,
Norbert

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich fand damals als Basicprogrammierer den Anhang H im ATARI Profibuch 
ziemlich gut um in C reinzukommen:
http://www.atariprofibuch.de/ATARI%20Profibuch%20S...
Anhang H startet bei Seite 1269 bzw. 1302.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:

> Klar ist aber: C++ odergar Java ist zumindest jetzt absolut kein Thema.

Warum ist es Dir eigentlich so klar, dass C++ kein Thema für Dich ist?

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Ich muss tatsächlich kein C-Spezi werden. Zum einen geht es wirklich nur
> um AVR-8 und was dann später kommt ist ja jetzt nicht festgelegt.
> Erstmal eine 1200-Seitenbibel durchzuackern ist aber keine Option.

Naja, es schadet aber auch nicht. Wenn man C erstmal "kann" (in "" denn 
wer kann C schon wirklich? ;)) ist die Anwendung auf die AVR-8 Familie 
wirklich kein Ding mehr.

Autor: P.Loetmichel (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Wozu C, Bascom ist super!

Autor: Jemand (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo

auch wenn ich von eigentlichen Thema jetzt etwas abschweife erklärt der 
Beitrag von Possetitjel (Gast) sehr deutlich warum es als Hobbyist der 
mit der Hardwareseite aufgewachsen ist aber in der Software, unabhängig 
von der konkreten Sprache, so einigermaßen die Einfachen Beispiele und 
Grundlagen versteht aber hinter die Eigentliche Idee und Vorteile die 
hinter einer OOP stehen einfach nicht begreifen kann:

"> Die Denkweise "OO" wollte mir nicht in den Schädel.

Das liegt nicht an der OOP, sondern an den beschissenen
Erklärungen.

Objekte sind (digitale) ICs (=abstrakte Automaten).
Methoden sind Signalanschlüsse, die mit der internen
Kombinatorik verbunden sind.
Felder (Membervariablen) sind Flipflops im Innern des IC.

Wirklich fundamental für die OOP ist m.E. nur die
Kapselung und vielleicht die dynamische Instantiierung;
der ganze Vererbungsquatsch ist nur technische Maschinerie.

Informatiker können das aber nicht so erklären, dass
Hardware-Leute das verstehen, sondern müssen das immer
mit Lamda-Kalkülen und Chomsky-Grammatiken verzieren."

Ironischer Weise ist diese "Erklärung" genauso unverständlich bzw. 
bringt irgendwie nicht herüber was nun das geniale (?) einer OOP ist, 
leider schaffen das aber auch nicht die dutzenden Erklärvideos auf 
YouTube und wohl hunderte Texte im Netz und in Büchern, obwohl 
eigentlich oft Fachsprache vermieden wird, bzw. an einfachen (...) 
Beispielen aus den Alltag versucht erklärt zu werden.
Auch wenn ich mittlerweile andeutungsweise ein Gefühl dafür bekomme was 
OOP ist habe ich es immer noch nicht verinnerlicht bzw. vom Bauchgefühl 
verstanden.
Vielleicht vergleichbar wie man (Physiker, Astronomen) die 
Lichtgeschwindigkeit kennt, damit rechnen kann, Effekte erklären aber 
letztendlich sie trotzdem nicht wirklich begreifen und "fühlen" kann.

Aber nun sind Programmiersprachen halt Menschengemacht und für unsere 
Lebensumstände und Wünsche entwickelt worden - also muss es doch möglich 
sein OOP (und andere Konzepte) wirklich Verstehen und verinnerlichen, 
also "fühlen" zu können - nur wie?

Jemand

Autor: --- (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Diese ganzen "Drecks-"Objekte braucht doch bei Mikrocontrollern
kein Mensch. C wird benutzt um ein Programm zu strukturieren und
es auf dem Controller einigermassen performant laufen zu lassen.

Wenn es C nicht mehr hergibt, z.B. bei Controllern mit mehreren
Befehlen per Zyklus, wird sogar der Assembler rausgeholt.

Wenn man mit OO ein wenig spielen will, sollte man sowas wie
Python nehmen. Da ist die Verwendung einigermassen natuerlich.

Aber C++ ist da voellig verk.ckt.

Autor: Walter K. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
OOP ist doch nur für die Leute, die für's prozedurale Programmieren zu 
blöd sind! ;-). ...lach

Autor: Stefan (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jemand schrieb:
> also muss es doch möglich
> sein OOP (und andere Konzepte) wirklich Verstehen und verinnerlichen,
> also "fühlen" zu können

OOP war eben vor ca. 30 Jahren ein großer Hype. Schon damals waren 
einige Leute ja eher skeptisch und fanden den OOP Ansatz für einige 
Projekte eher unnatürlich. In den meisten Büchern die in den letzten 10 
Jahren erschienen sind steht OOP ja auch nicht mehr so im Mittelpunkt. 
Siehe etwa

https://news.ycombinator.com/item?id=12154228

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Leute, ich hatte vorgeschlagen, C++ zu verwenden. Aber das heißt doch 
nicht, dass man OOP bzw. Laufzeitpolymorphie (was hier oben wohl gemeint 
ist) verwenden muss. Wer sagt C++ == OOP kennt halt C++ nicht.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich halte gar nichts von der Ansage "Erst C lernen und dann C++."

Ganz im Gegenteil:
Ich behaupte: "Hat man sich erst einmal auf die prozedurale Sicht 
eingeschossen, ist man für die OO Sicht verdorben."

Gut, vielleicht nicht gänzlich verdorben, für immer, aber der Umschwenk 
auf die OOP fällt einem dann erheblich schwerer, als es sofort zu 
lernen.
Und das schlimmste daran: Der Betroffene selber merkt es noch nicht 
einmal.
Der leistet nur Widerstand.

Ein Teil meiner Ansichten beruht auf ca 30 Jahren OOP Erfahrung, viel 
Hobby, aber auch einige Jahre Beruflich.
Nicht mit C++, da bin ich recht frisch.
Dennoch habe ich einige Leute in die OOP Welt eintreten sehen, im Team.
Und von daher, weiß ich, dass Neulinge deutlich weniger Probleme haben, 
beim OOP Einstieg, als Erfahrene aus der prozeduralen Welt.

Vergleich:
Ein beschriebenes Blatt, muss erst ausradiert werden, um es nochmal, mit 
was anderem, beschreiben zu können. Wenn nicht, gibt das ein unsägliches 
Gekrackel.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Ich halte gar nichts von der Ansage "Erst C lernen und dann C++."

Siehe mein Beitrag von oben: "Stop teaching C"

Autor: Markus F. (mfro)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Frank G. schrieb:
> C-Neuling schrieb:
>> Es geht einfach erstmal darum einen Einstieg in C zu finden.
>
> http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/...

Wenn ich in jenem Buch - wahllos ein Kapitel rausgegriffen - ohne 
weitere Erklärung das hier lese:

> Folgende Wertzuweisung von Strukturen sollten Sie allerdings vermeiden:
>
> struct {
>    int a1;
>    int a2;
>    int a3;
> } werte1, werte2;
>
> werte1.a1 = 8;
> werte1.a2 = 16;
> werte1.a3 = 32;
>
> werte2 = werte1;   // Bitte vermeiden Sie solche Zuweisungen.
>
> Das ist in C zwar erlaubt, kann aber zu Fehlern führen, wenn ein
> Compiler dies nicht unterstützt. Sicherer wäre die folgende Möglichkeit:
>
> memcpy(&werte2, &wert1, sizeof(werte1));

rollen sich mir die Fußnägel auf. Das ist 1. Blödsinn und 2. ist in der 
"Empfehlung" auch noch ein Tippfehler.

Keine besonders gute Empfehlung, m.E. (auch wenn's umsonst ist)

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Norbert, ich glaube, du bist trotz deiner Zweifel genau auf dem
richtigen Weg.

Nur eins vorweg:

Dein Ziel sollte nicht Schmalspur-C, sondern richtiges, vollständiges C
sein, sonst legst du dir mittelfristig nur Steine in den Weg. Da heißt
nicht, dass du sämtliche C-Features im Detail auswendig können musst,
aber so solltest zumindest wissen, welche Features es prinzipiell gibt,
und wozu sie da sind. Die Details hast du im Bedarfsfall dann schnell
nachgeschlagen.

Der Sprachumfang von C ist nicht sehr groß, so dass man sich in wenigen
Tagen einen guten Überblick über die gesamte Sprache verschaffen kann,
der dann als Grundlage für die weitere Vertiefung dient.

C-Neuling schrieb:
> In der Jugend hatte ich mal Basic und Pascal gelernt

Da haben wir etwas gemeinsam :)

Das ist auf jeden Fall schon einmal eine gute Voraussetzung, denn je
mehr Sprachen man kennt (man muss nicht einmal viel praktische Erfahrung
damit haben), umso schneller lernt man jede weitere.

Der Auslöser, C zu lernen, war bei mir kein äußerer Zwang, sondern ein
Codebeispiel in einer Computerzeitschrift, neben dem der entsprechende
Pascal-Code (der mir bis dato eigentlich sehr gut gefiel) wie das
Geschwätz eines Politikers anmutete (was natürlich Geschmackssache ist,
denn manche lauschen auch gerne stundenlang den Reden der Herren
Politiker ;-)).

Deswegen kaufte ich mir das Buch von Kernighan und Ritchie (damals noch
dir 1. Aufgabe, die mittlerweile überholt ist) und habe dessen Inhalt,
motiviert wie ich war, innerhalb von zwei Tagen aufgesaugt.

Danach konnte ich zwar noch nicht richtig C programmieren, denn die
Routine und die Codequalität kommen erst mit der Übung. Dabei sind drei
Punkte wichtig:

1. Code von anderen anschauen und zu verstehen versuchen

2. Dinge selber ausprobieren

3. Bei Unklarheiten und Überraschungen im Lehrbuch oder im Internet nach
   Erklärungen suchen

Norbert S. schrieb:
> Was hat es mit den Header-Files auf sich, das Makefile, solche
> Eigenheiten die ich nicht kenne.

Die Makefiles würde ich erst einmal außen vor lassen. Sie sind kein
Bestandteil der Sprache C, und je nach verwendeter Entwicklungsumgebung
brauchst du sie entweder gar nicht, oder sie werden automatisch für dich
generiert. Ansonsten gibt es im Netz auch Muster-Makefiles, die auch vom
Ahnungslosen leicht an konkrete Anwendungen angepasst werden können.

Norbert S. schrieb:
> Vielleicht hätte ich noch erwähnen sollen, daß man mit Ende 40 ganz
> anders lernt als ein Student. Zum einen viel langsamer

Das stimmt zwar leider oft, in diesem (noch mittleren) Alter ist es ist
aber i.Allg. nicht die Lernfähigkeit, die nachlässt, sondern lediglich
die Motivation, sich auf etwas Neues einzulassen. Die Motivation wird
durch äußere Zwänge, wie sie bei dir vorliegen, zudem gebremst. Aber
vielleicht kannst du in den neu zur erwerbenden Kenntnissen ja auch
positive Aspekte finden, wie bspw.

- die Erweiterung des persönlichen Horizonts

- neue Möglichkeiten, die du auch im Hobby anwenden kannst

- am Ende das Gefühl, etwas Neues angegangen und schließlich auch
  durchgezogen zu haben

- bei Erfolg die Motivation, weitere neue Dinge zu lernen

> und viel mehr auf der Erfahrung basierend.

Das ist ein großer Vorteil, denn du hast nicht nur Erfahrung in zwei
anderen Programmiersprachen gesammelt, sondern im Lauf deines Lebens
auch Lernen gelernt. Effizient zu lernen ist etwas, was gerade Jüngeren
oft schwerer fällt.

In Summe bist du also gegenüber den Jüngeren nicht unbedingt im
Nachteil.

Norbert S. schrieb:
> Ich habe mir erstmal das hier bestellt (weil vorhin lange erstmal gar
> keine Antwort kam):
> https://www.amazon.de/dp/3836241145/ref=pe_3044161...

Wenn du das Buch noch nicht bestellt hättest, hätte ich dir wie schon
einige andere den o.g. K&R (2. Auflage) empfohlen, weil das Buch die
Sprache einschließlich der Standardbibliothek vollständig und prägnant
beschreibt. Andere Bücher, die vollständig sind, sind meist mindestens
doppelt so dick. Allerdings basiert das Buch auf der schon etwas älteren
ANSI- bzw. C89-Norm, d.h. es fehlen einige neuere Features.

Norbert S. schrieb:
> Ok, das Buch ist kacke? Kann ich ja mal anlesen und dann immer noch
> wieder verkloppen oder verschenken.

Das Buch kenne ich zwar nicht, aus dem Inhaltsverzeichnis lässt sich
aber erahnen, dass es für deine Zwecke durchaus eine gute Wahl sein
könnte, evtl. sogar eine bessere als der K&R:

- Es ist zwar deutlich dicker als der K&R, aber noch lange kein
  Schinken.

- Es behandelt die in C99 eingeführten Integer-Typen mit vorgegebener
  Bit-Breite, die gerade in der µC-Programmierung gerne verwendet
  werden. Im K&R fehlen sie, ebenso wie der Datentyp bool.

- Die Standardbibliothek wird zwar nur ausschnittsweise behandelt, was
  aber kein Problem darstellt, wenn du C ohnehin hauptsächlich auf µC
  verwenden möchtest. Denn die Laufzeitbibliotheken für kleinere µC wie
  dem AVR sind meist unvollständig implementiert, enthalten dafür aber
  noch einige µC-spezifische Funktionen. Der in dem Buch fehlende Teil
  wird somit durch die entsprechende µC-spezifische Doku ersetzt. Für
  den AVR ist sie hier zu finden:

    https://www.nongnu.org/avr-libc/

Weder der K&R noch das von dir bestellte Buch gehen auf µC-spezifische
Aspekte ein. Zum Lernen ist es aber ohnehin besser, sich erst einmal auf
die PC-Programmierung zu beschränken, weil du dort leichter debuggen
kannst und du die kompilierten und gelinkten Programme direkt (ohne
Flashen auf den µC) ausführen kannst.

Auf den µC solltest du erst gehen, wenn du dich auf dem PC halbwegs
trittsicher fühlst. Die dafür zusätzlich benötigten Informationen
findest du bspw. hier:

  https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

Norbert S. schrieb:
> Ob ich privat auch auf C umsteige überlege ich mir dann wirklich noch
> gründlich.

Überlege nicht lange, sondern mach es einfach, denn dann kommst du nicht
nur schneller zum Ziel, sondern hast auch noch einen persönlichen Nutzen
davon.

Norbert S. schrieb:
> Was waren das denn z.B. für Einschränkungen bei BASIC, die es bei C dann
> nicht mehr gab?

Ich kenne Bascom nicht im Detail, was mir aber sofort ins Auge springt,
ist bei Ausdrücken die Beschränkung auf eine einzige Operation. Statt

  s = 3 * (x - 1) + 4

musst du in Bascom schreiben:

  tmp1 = x - 1
  tmp2 = 3 * tmp1
  s = tmp2 + 4

Es gibt sicher noch weitere Dinge, die man in C eleganter lösen kann.

Fazit:

Mit deiner Erfahrung, dem bestellten Buch und den Informationen aus dem
Netz verbleiben kaum noch Hürden auf deinem Weg zum erfolgreichen
C-Softwareentwickler. Hau also rein und melde dich in zwei Wochen
wieder, um über deine Fortschritte zu berichten. Ich wette, du wirst bis
dahin schon deutlich mehr als die berühmte blinkende LED zustande
gebracht haben :)


Wilhelm M. schrieb:
> Starte direkt mit C++ auf einer hohen Abstraktionsstufe für non-µC, und
> bewege Dich dann Richtung µC. Am Ende kannst Du auch C ...

Ich bin ja mittlerweile auch schon (fast) zum C++-Fanboy geworden und
würde jedem, der primär PC-Programme schreiben möchte, den Weg direkt zu
C++ (ohne vorher C zu lernen) empfehlen.

Auf Norberts Situation bezogen (er will primär µC programmieren, und das
in klassisschem C, weil so vom Arbeitgeber verlangt), erscheint mir dein
vorschlagenes Vorgehen ein wenig wie:

Ein Familienvater (Norbert) möchte für sich, seine Frau und die beiden
Kinder ein Häuschen bauen (µC in C programmieren können). Jetzt kommt
der Architekt (du) und empfiehlt ihm, sich etwas Zeit zu lassen und
gleich einen Wolkenkratzer zu bauen (C++ zu lernen), davon aber nur das
– platzmäßig völlig ausreichende – Erdgeschoss (C-Untermenge von C++) zu
benutzen.

Natürlich hat der Wolkenkratzer auch Vorteile: Wenn die Kinder erwachsen
sind und selber Familien haben, brauchen sie keine Wohnung zu suchen,
sondern können das zweite und dritte Stockwerk belegen (wenn die in
Frage kommenden µC künftig größer werden, können einige zusätzliche
Features von C++ sehr nützlich sein). Der Rest des Gebäudes kann
gewinnbringend vermietet werden (Norbert könnte einen Nebejob als
PC-Programmierer annehmen und damit zusätzliches Geld verdienen).

Wenn ich aber Norbert richtig verstanden habe, will er einfach nur
möglichst schnell in sein neues Häuschen einziehen :)


Possetitjel schrieb:
> Das liegt nicht an der OOP, sondern an den beschissenen
> Erklärungen.
>
> ...
>
> Informatiker können das aber nicht so erklären, dass
> Hardware-Leute das verstehen, sondern müssen das immer
> mit Lamda-Kalkülen und Chomsky-Grammatiken verzieren.

Da verwechselt du etwas:

Mit dem Lambda-Kalkül wird nicht die OOP, sondern die FP (Funktionale
Programmierung) erklärt, die der OOP – von einigen Spezialanwendungen,
wie der GUI-Programmierung abgesehen – haushoch überlegen ist ;-)



Und schon sind wir am Ende des Worts zum Sonntag angelangt :)

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Wilhelm M. schrieb:
>> Starte direkt mit C++ auf einer hohen Abstraktionsstufe für non-µC, und
>> bewege Dich dann Richtung µC. Am Ende kannst Du auch C ...
>
> Ich bin ja mittlerweile auch schon (fast) zum C++-Fanboy geworden und
> würde jedem, der primär PC-Programme schreiben möchte, den Weg direkt zu
> C++ (ohne vorher C zu lernen) empfehlen.
>
> Auf Norberts Situation bezogen (er will primär µC programmieren, und das
> in klassisschem C, weil so vom Arbeitgeber verlangt),

Wie schon des öfteren bemerkt, würde ich dann auch den Arbeitgeber hier 
in die Pflicht nehmen: ein/zwei gute Schulungen besuchen. Denn auch der 
AG hat nichts davon, wenn er schlechten/falschen Code schreibt.

> Ein Familienvater (Norbert) möchte für sich, seine Frau und die beiden
> Kinder ein Häuschen bauen (µC in C programmieren können). Jetzt kommt
> der Architekt (du) und empfiehlt ihm, sich etwas Zeit zu lassen und
> gleich einen Wolkenkratzer zu bauen (C++ zu lernen), davon aber nur das
> – platzmäßig völlig ausreichende – Erdgeschoss (C-Untermenge von C++) zu
> benutzen.

In diesem Sinne ist das dann sein erstes Haus. Lehmhüttchen kennt er 
schon.

Wenn er dann in sein neues Haus einzieht. stellt er fest, dass er sich 
viel Mühe umsonst gemacht hat, er hat es völlig falsch geplant, sind die 
Kinder aus dem Haus, fällt eine Umnutzung schwer und von neuen 
Baustoffen hat er auch keine Ahnung. In Summe: abreissen ;-)

> Und schon sind wir am Ende des Worts zum Sonntag angelangt :)

Ha, ich war schon in der Kirche ...

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schließe mich dem Vorschlag für den K&R an. Der ist relativ kurz und 
knackig aber sicher gut für Leute mit Vorkenntnissen geeignet. Ansonsten 
kann ich uneingeschränkt den "C Primer Plus" von Stephen Prata 
empfehlen. Der hat zwar ca. 800 Seiten aber dafür werden auch keine 
Fragen offengelassen. An deiner Stelle würde ich mir wahrscheinlich 
beides zulegen.

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

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Ich schließe mich dem Vorschlag für den K&R an.

Ich auch; ich halte die deutschsprachige Übersetzung auch für brauchbar. 
Zwar steht da "Übersetzer" statt "Compiler", aber die Transferleistung 
sollte möglich sein.

Die erste Ausgabe (nicht Auflage, das ist was anderes) ist hingegen 
gerade in der deutschen Übersetzung komplett unbrauchbar, aber an die 
kommt man glücklicherweise nur noch antiquarisch ran, und wer will das 
schon?

Ja, der K&R deckt nicht alles ab, aber er ist nach wie vor ein gutes 
und stabiles Grundgerüst. Auch wenn der behandelte Standard C89 heißt, 
ist der nicht obsolet, die nachfolgenden Standards haben den 
Sprachumfang nur erweitert, nicht aber inkompatibel abgeändert.

Wer C89 beherrscht, kommt mit jedem C-Compiler zurecht; wer aber nur C11 
beherrscht, wird sich freuen, wenn er mal mit einem älteren Compiler 
arbeiten muss. Und das kann einem im Embedded-Bereich durchaus 
passieren, nicht für alles gibt es eine aktuelle und gepflegte 
gcc-Portierung.

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:

> Possetitjel schrieb:
>> Das liegt nicht an der OOP, sondern an den beschissenen
>> Erklärungen.
>>
>> ...
>>
>> Informatiker können das aber nicht so erklären, dass
>> Hardware-Leute das verstehen, sondern müssen das immer
>> mit Lamda-Kalkülen und Chomsky-Grammatiken verzieren.
>
> Da verwechselt du etwas:

Nicht sehr :)
Der Seitenhieb mit den Chomsky-Grammatiken bleibt ja
gültig.


> Mit dem Lambda-Kalkül wird nicht die OOP, sondern die FP
> (Funktionale Programmierung) erklärt,

Ich weiss.

Das ändert aber nichts (wesentliches) an meinem Kernpunkt,
der da lautet: Informatiker können der Erfahrung nach
immer nur alles als formale SPRACHE erklären -- aber das
durch die Sprache Beschriebene ist für sie immer nur ein
ALGORITHMUS.

Dass mittels der formalen Sprachen auch (endliche bzw.
abstrakte) AUTOMATEN beschrieben werden können, kommt in
ihrem Universum nicht vor. Alle Außenseiter, nämlich sowohl
die Steuerungsprogrammierer als auch die VHDL-Leute wissen
das -- nur die "richtigen" Informatiker nicht.

Das ist deswegen wichtig, weil das Konzept "abstrakter
Automat" den Hardware-Leuten normalerweise m.o.w.
vertraut ist -- vielleicht nicht in der Theorie, aber aus
der Erfahrung.

"Einen 74193 auf das Steckbrett stecken und anschließen"
ist halt anschaulicher als "ein Objekt instaziieren",
obwohl das im Prinzip genau dasselbe ist.

> die der OOP – von einigen Spezialanwendungen, wie der
> GUI-Programmierung abgesehen – haushoch überlegen ist ;-)

Ich bin zwar nicht Deiner Meinung, finde aber die
provokatorische Absicht sympathisch :)

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:

> Das ändert aber nichts (wesentliches) an meinem Kernpunkt,
> der da lautet: Informatiker können der Erfahrung nach
> immer nur alles als formale SPRACHE erklären -- aber das
> durch die Sprache Beschriebene ist für sie immer nur ein
> ALGORITHMUS.

Was sind denn das für Informatiker? Haben die nicht OOA gelernt?

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:

> Leute, ich hatte vorgeschlagen, C++ zu verwenden. Aber das
> heißt doch nicht, dass man OOP bzw. Laufzeitpolymorphie
> (was hier oben wohl gemeint ist) verwenden muss.

Nein, ich hatte nicht die Laufzeitpolymorphie im Auge,
sondern primär die Kapselung.

Das Ärgernis mit der OOP geht ja schon damit los, dass sich
selbst die Theoretiker nicht wirklich einig sind, was OOP
eigentlich ist. Als charakteristische Kennzeichen werden
aber m.W. häufig genannt...
- Kapselung,
- Vererbung,
- Laufzeitpolymorphie.

Es ist aber meiner Erfahrung nach so, dass die Kapselung
ein Prinzip ist, dessen Wichtigkeit mMn kaum überschätzt
werden kann und das weit über den Bereich der OOP hinaus
überragende Bedeutung hat.

Aus meiner Sicht macht der TO daher einen strategischen
Fehler, wenn er die OOP so in Bausch und Bogen ablehnt,
denn es lohnt sich, ein paar Grundideen von dort zu klauen.

Vererbung kann man natürlich nur verwenden, wenn sie
von Sprache und Compiler unterstützt wird -- aber
Kapselung (und in Grenzen auch Laufzeitpolymorphie) kann
man auch "von Hand", also ohne explizite Unterstützung
durch den Compiler praktizieren. Meiner bescheidenen
Meinung nach ist das sehr lohnend.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Die erste Ausgabe (nicht Auflage, das ist was anderes) ist hingegen
> gerade in der deutschen Übersetzung komplett unbrauchbar

So harsch würde ich es nicht ausdrücken, denn immerhin habe ich damit C
gelernt :)

Die Übersetzung war für mich schon ziemlich schmerzhaft (so sind bspw.
sämtliche zusammengesetzten Substantive getrennt geschrieben, also nicht
einmal mit Bindestrich), die Verständlichkeit hat darunter aber nicht
gelitten. Für heutige Hipster, die einen ganz ähnlichen Schreibstil
pflegen, wäre der Text vielleicht sogar angenehmer zu lesen als ein in
richtigem Deutsch geschriebener ;-)

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Possetitjel schrieb:

> Es ist aber meiner Erfahrung nach so, dass die Kapselung
> ein Prinzip ist, dessen Wichtigkeit mMn kaum überschätzt
> werden kann und das weit über den Bereich der OOP hinaus
> überragende Bedeutung hat.

Richtig, und lose Koppelung: und C++ fördert durch templates gerade ja, 
ein eigentlich falsches "is-a" durch "has-a" zu ersetzen.

> Aus meiner Sicht macht der TO daher einen strategischen
> Fehler, wenn er die OOP so in Bausch und Bogen ablehnt,

Und nicht nur OOP (aber vermutlich weiß er noch gar nicht, was die 
anderen Dinge bedeuten).

: Bearbeitet durch User
Autor: Norbert S. (norberts)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Moin,

Yalu, danke, ich glaube Du hast die Situation erfasst.

Nochmal für alle: C++ kommt nicht in Frage, weil ich überhaupt keine 
Ambitionen auf PC-Programmierung habe.
Für 8-Bitter kommt das wohl auch nicht in Betracht (wenn ich richtig 
gelesen habe) und wenn ich doch mal mit 32-Bittern arbeite - wer weiß.

"Weil der AG es verlangt" vermittelt so ausgedrückt einen falschen 
Eindruck.
Wenn ich weiter (auch) programmieren will, dann bei neuen Projekten in 
C.
Lerne ich kein C, sperre ich mich da zwar aus aber mein Hauptjob ist 
Hardware.
Ich habe ausdrücklich das GO, mich in der Arbeitszeit damit zu befassen. 
Nun werde ich mich nicht ins Büro setzen und ein C-Buch lesen aber 
simple Dinge zusammenstecken und Kollegen fragen wenn's hakt - das ist 
ausdrücklich gewünscht. Da kommen Dinge wie Struct sicherlich auch viel 
schneller rüber, weil die Kollegen genau wissen, wo sie mich abholen 
müssen. Kein Anfang bei Adam und Eva und keine theoretischen Orgien, die 
eher an eine Uni gehören.
Dabei habe ich Zugriff auf C-Kenntnisse von knapp über Hobbyniveau bis 
zu einem echten Könner (behaupte ich mal).
Fliesst etwas in echte Produkte ein, geht das sowieso nur mit Begleitung 
der Softwerker. Daß ich mir da gruseligen Stil angewöhne ist also eher 
unwahrscheinlich bzw. würde mir da schnell wieder ausgetrieben.

Es sind noch einige Dinge in Bascom unterwegs und werden auch weiter 
gepflegt. Es steckt sogar noch ein Bootloader in Bascom in einem der 
Hauptprodukte (mit ordentlich ASM drin) während die eigentliche Firmware 
längst in C ist.

Noch eine Analogie zu meinem Ziel und C++:
Fragt einer nach einem Problemchen mit NE555, mit µC hat er nichts am 
Hut. Das soll nur ein spezieller Blinker für irgendwas werden. 
Antworten: Nimm einen µC, damit ist das ganz einfach.
Stimmt zwar, nur für ihn trifft das nicht zu.
Und selbst wenn er später mit µC anfängt, besseres Verständtnis des 
NE555 ist garantiert nicht für den Fuss.

Bascom vs. C:
Das mit der einen Anweisung pro Zeile - da muss ich schmunzeln.
Pipifax (obwohl es manchmal nervt)
Das ist als Argument für C ungefähr so valide wie genau die gegenteilige 
Argumentation, speziell auf µC mit knappen Ressourcen: Bei Bascom wird 
eher ersichtlich, wenn ein Zwischenschritt der Rechnung die Variable(n) 
überlaufen lässt.

C ist einfach der Standard, da kommt man nicht drumherum.
Diskussionen in der Richtung sind hinfällig.

Ginge es nur um private Dinge, wie bei mir eher nur Mittel zum Zweck, 
würde ich nicht drüber nachdenken. Da ist Bascom viel einfacher und 
reicht dicke (wenn C da überhaupt einen messbaren Vorteil hätte).
Da geht es mir nicht um das Programmieren als Hobby sondern Dinge bauen, 
die eben mit µC umsetzbar sind, diskret eher schlecht bis gar nicht.
Vieles ist dabei Quick'n'Dirty, soll nur Dinge möglich machen.
Elektronik oder Programmieren als Hobby zum Selbstzweck - das ist es bei 
mir ganz klar nicht (mehr).

Im Job trifft das auf C zu. Das wird nie Kern meines Jobs sein sondern 
nur ein notwendiges Mittel zum Betrieb der Hardware.

Ich sehe mir das bestellte Buch mal an. Das soll nur ein Anfang sein.
Dann hole ich mir vielleicht mal Hilfe bei einem Kollegen, wie ich im 
Studio überhaupt anfange und dann sollte die erste LED bald blinken.
Nein, den Umweg über PC werde ich nicht wählen. Dafür ist das alles viel 
zu sehr auf µC fokussiert und die Hardware ist mein absolut geringstes 
Problem.

Ich möchte nochmal ausdrücklich loben, wie sachlich diese Diskussion war 
bzw. ist. Das ist hier ja nicht selbstverständlich.

Gruß,
Norbert

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Moin,
>
> Yalu, danke, ich glaube Du hast die Situation erfasst.
>
> Nochmal für alle: C++ kommt nicht in Frage, weil ich überhaupt keine
> Ambitionen auf PC-Programmierung habe.
> Für 8-Bitter kommt das wohl auch nicht in Betracht

Sorry Norbert: das ist vollkommen falsch!

> (wenn ich richtig
> gelesen habe)

dann hast Du falsch gelesen ;-)

So, aber jetzt höre ich auf - viel Spaß in der neuen Welt!

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Von wegen deutsche Übersetzung:
Im Zweifelsfall würde ich immer die englische Version wählen. Das ist 
kein Problem.

OO:
Ich sehe ja gerne ein, daß das nicht so unglaublich schwer ist wie es 
mir erschien (die Erklärungen waren nur Mist oder nicht vorhanden).
Kann mir einer bitte sagen, was mir das bringen soll, wenn ich vorerst 
bzw. weiterhin bei AVR 8-Bit bleiben will?
Die Frage ist ernst gemeint. Als Frage, nicht als Provokation.

Gruß,
Norbert

Autor: Norbert S. (norberts)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
>> Nochmal für alle: C++ kommt nicht in Frage, weil ich überhaupt keine
>> Ambitionen auf PC-Programmierung habe.
>> Für 8-Bitter kommt das wohl auch nicht in Betracht
>
> Sorry Norbert: das ist vollkommen falsch!
>
>> (wenn ich richtig
>> gelesen habe)
>
> dann hast Du falsch gelesen ;-)
>
> So, aber jetzt höre ich auf - viel Spaß in der neuen Welt!

Moin,

Aber ich sehe doch richtig, daß C eine Untermenge von C++ ist bzw. C++ 
eine Erweiterung von C.
Es besteht momentan überhaupt kein Bedarf für C++, warum sollte ich das 
dann jetzt lernen?
Wie verbreitet ist C++ auf 8-Bittern? (Arduino zählt nicht, das ist wie 
Windows XP auf einen 486er zu quetschen).

Gruß,
Norbert

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Wie verbreitet ist C++ auf 8-Bittern? (Arduino zählt nicht, das ist wie
> Windows XP auf einen 486er zu quetschen).

Meine Meinung:
Hier sieht man, wie tief du im Irrtum steckst!

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Arduino F. schrieb:
> Meine Meinung:
> Hier sieht man, wie tief du im Irrtum steckst!

Meinung ohne Fakten ist Glauben. Geglaubt wird in der Kirche.
So ist dieser Beitrag leider komplett sinnlos.
Kläre mich doch auf, anstatt mir bloß Irrtum vorzuwerfen.

Gruß,
Norbert

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

Bewertung
1 lesenswert
nicht lesenswert
Arduinos verwenden u.a. 8-Bit-AVRs,  und auch wenn viele naserümpfend 
darauf hinabblicken - darin steckt C++, und es ist damit wirklich /sehr 
weit/ verbreitet.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Was willst du denn hören?

Hier mal ein leeres Arduino Programm:
int main()
{
  for(;;);
}

Meldung:
Der Sketch verwendet 134 Bytes (0%) des Programmspeicherplatzes. Das 
Maximum sind 32256 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers, 2048 
Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.


Die OOP Variante, für Pin toggeln:
#include <CombiePin.h>

Combie::Pin::OutputPin<4> out;

int main()
{
  out.init(); 
  for(;;) out.toggle();// 2,667MHz auf einem UNO
}

Meldung:
Der Sketch verwendet 140 Bytes (0%) des Programmspeicherplatzes. Das 
Maximum sind 32256 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers, 2048 
Bytes für lokale Variablen verbleiben.


Für die Pin Initialisierung und das toggeln werden 6 Byte Flash belegt, 
und 0 Byte Ram.
Das bekommst du weder in C, noch mit deinem Basic, knapper hin.


Was ist da mit deinem Urteil:
Norbert S. schrieb:
> das ist wie Windows XP auf einen 486er zu quetschen
Das ist doch dann Unsinnig, oder?

Du hast offensichtlich keine Ahnung von C++!
Null!
Aber erlaubst dir vernichtende Urteile.
Ich empfinde das schon als ein wenig irre.

Übrigens:
> Wer will findet Wege.
> Wer nicht will erfindet Gründe!

Autor: Norbert S. (norberts)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Moin,

Ja, weit verbreitet bei Künstlern und Hobbyisten.
3D-Drucker laufen teilweise auch damit.
Alles bekannt aber kommerziell C++ auf 8-Bittern?

Gruß,
Norbert

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

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Alles bekannt aber kommerziell C++ auf 8-Bittern?

Warum sollte das Arduino-Framework nicht auch kommerziell verwendet 
werden?

Und warum sollte, was für die Nutzung beim Arduino ausreicht, nicht auch 
für andere C++-Frameworks ausreichen?

Natürlich wird man nicht jede beliebige "fette" C++-Klassenbibliothek 
auf jeden 8-Bit-µC portieren können, dem sind natürlich Grenzen sowohl 
bei der Codegröße als auch dem verfügbaren RAM gesetzt.

Obendrein wird nicht jedes C++-Sprachfeature von jedem C++-Compiler für 
µCs unterstützt werden.

Aber das braucht man für die Embedded-Programmierung ja nun auch nicht 
unbedingt.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Können wir das mit C++ hier vielleicht einfach lassen?
Darum ging es mir nie und ich will das hier auch nicht diskutieren.
Bei der Syntax wird mir ja schon schlecht.

Ich habe ja nun einen Plan und C++ kommt da nicht vor.

Gruß,
Norbert

Autor: visitor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn du die AVR's gut kennst und noch heute damit unterwegs bist, 
dann empfehle ich dir das Buch von Günter Schmitt vom Oldenbourg Verlag.
Dort werden die Grundlegen Dinge von C und soagr Assembler erklärt und 
dann anhand vieler typischen AVR Schnittstellen und Projkte in C und 
Assembler erklärt und in Listings zur Verfügung gestellt.

Somit könntest du das gelernte zielgerichtet in deinen Schaltungen auf 
einem AVR auch anwenden. Dies ist meines Erachtens sinnvoller als C auf 
einem PC zu lernen. D.h. nicht dass dies nicht auch ginge, könnte aber 
falls du keine PC Anwendungen im Sinn hast irgendwann langweilig werden 
und du könntest die Lust verlieren.

https://www.degruyter.com/view/product/221318

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> und ich will das hier auch nicht diskutieren.
Wenn du im Gegenzug deine unqualifizierten C++ Abwertung sein lässt...

Übrigens, dieses ist ein Forum, da kann jeder posten, was er für richtig 
hält. Und das behalten wie hier auch schön so bei!


Einzig die Moderatoren haben ein Zensurrecht, ja, die  Pflicht dazu.
Du nicht.

: Bearbeitet durch User
Autor: Norbert S. (norberts)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Norbert S. schrieb:
>> und ich will das hier auch nicht diskutieren.
> Wenn du im Gegenzug deine unqualifizierten C++ Abwertung sein lässt...
>
> Übrigens, dieses ist ein Forum, da kann jeder posten, was er für richtig
> hält. Und das behalten wie hier auch schön so bei!
>
>
> Einzig die Moderatoren haben ein Zensurrecht, ja, die  Pflicht dazu.
> Du nicht.

Moin,

Komm mal runter, ich wollte nur vorschlagen, hier nicht weiter über C++ 
zu diskutieren. Das schliesst meine Äusserungen natürlich ein, ich werde 
auf das Thema auch nicht weiter eingehen.
Du darfst hier natürlich weiter sinnlos für C++ und Arduino schreiben, 
ich darf es dann aber auch ignorieren, wenn es mir am Mors vorbei geht.

Schade, daß es so eskaliert ist - ich habe doch nur nach einem C-Buch 
gefragt.
"Mein Opel ruckelt [Details] - was tun?" - "Kauf dir nen BMW"
Och nö.

Gruß,
Norbert

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank G. schrieb:
> http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/...

Das Buch sagt zu goto:
> Ich habe mir lange überlegt, ob ich goto überhaupt
> in diesem Buch erwähnen soll ...
> ...
> Warum also ist goto so verpönt?
> Aus Performance-Gründen!
> ...

Egal, was man von Goto hält...
Aber das ist doch irgendwie Verrückt!

Ein Autor, welcher ein C-Fachbuch schreibt, und überlegt, ob er Goto 
aufnehmen möchte?
Nee...

Und Performance?
Das ist doch ganz sicher kein tragfähiges Argument gegen Goto.
Da wird doch eher andersrum ein Schuh draus.

: Bearbeitet durch User
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
@Wilhelm:

Natürlich gibt es etliche mächtige C++-Features, die problemlos und
gewinnbringend auch auf 8-Bit-Controllern verwendet werden können.

Die Frage ist nur: Welche Features sind das genau?

Einer, der C++ vollständig beherrscht, kann für jedes einzelne Feature
sofort entscheiden, ob es auf einem µC nützlich ist, oder ob man es
besser in er PC-Ecke lässt.

DU kannst das auf jeden Fall, ich ansatzweise auch.

Was ist aber mit einem wie Robert, der bisher ausschließlich in Basic
und Pascalprogrammiert hat? Woher soll er die Information nehmen, welche
Abschnitte des 1000-Seiten-C++ für die µC-Programmierung relevant sind
und welche nicht? Es wird ihm nichts anderes übrig bleiben als das
komplette Buch durchzuarbeiten, was mindestens 2 Wochen dauert.

Aber damit nicht genug: Um die µC-Relevanz der einzelnen Features
bewerten zu können, muss er sie nicht nur kennen, sondern auch benutzen
können. Dazu muss er üben, fremde Software anschauen, viele Threads auf
Stackoverflow lesen und nachvollziehen, evtl. weitere Bücher von Meyer
und Sutter durcharbeiten und noch mehr und noch mehr üben. Das alles
dauert nicht Wochen, sondern Monate, wenn nicht Jahre.

Als nächstes muss er ein Gefühl dafür bekommen, wieviele Ressourcen die
einzelnen C++-Features in welchem Kontext verschlingen. Das macht man am
besten dadurch, dass man sich den vom Compiler erzeugten Assemblercode
anschaut. Also muss sich Robert auch noch in die Assemblerprogrammierung
einarbeiten, zumindest so weit, das er den Code lesen und verstehen
kann. Auch das geht nicht von heute auf morgen.

Irgendwann wird er dann vor einen µC gesetzt, für den kein C++-Compiler
verfügbar ist. Dann muss er sich damit beschäftigen, welche der
liebgewonnenen C++-Features nicht mehr verfügbar sind und was am Ende
noch übrig bleibt, um seine Entwicklung trotzdem zu realisieren. Das
könnte er nach der Trial-and-Error-Methode tun, indem er seine
Programmierung nach und nach solange ändert, bis der Compiler keine
Fehler mehr meldet. Der geradlinigere Weg wird aber sein, in einem
C-Buch nachzuschauen, was in C alles geht, statt durch Herumprobieren
herauszufinden, was alles nicht geht. Aber auch das kostet wieder
Zeit.

Wenn er hingegen direkt mit einem C-Buch beginnt, wird er zwar nicht in
den Genuss einiger nützlicher C++-Features kommen, die Eleganz seines
Codes wird auch nicht die eines erfahrenen C++-Programmierers erreichen.
Er wird aber ziemlich sicher bereits nach zwei Wochen sein erstes
nichttriviales µC-Programm auf die Beine stellen, und genau darum geht
es ihm doch. Seine Kollegen und seinen Arbeitgeber wird das sicher
ebenfalls freuen, wenn er nicht erst nächstes Jahr die ersten Ergebnisse
liefert.

Ich kenne deine Historie nicht, gehe aber davon aus, dass du schon seit
vielen Jahren in C++ programmierst. Ich weiß, es ist nicht leicht: Aber
versuche dich mal in die Anfangszeit zurückzuversetzen, als du die
ersten Gehversuche mit C++ unternommen hast: Wie hätten deine ersten
paar µC-Programme in C++ ausgesehen? Genauso wie du sie heute
realisieren würdest? Oder wären sie evtl. aus Speichermangel gar nicht
gelaufen, weil du eben damals noch nicht wusstest, wie sich die
Verwendung verschiedener C++-Features auf den Ressourcenverbrauch
auswirkt?

Wenn es ein gutes Buch mit dem Titel

  "C++-Programmierung auf 8-Bit-Mikrocontrollern für C++-Unkundige"

gäbe, in dem alles Relevante (und nur das), was du dir in deiner
C++-Laufbahn zu diesem Thema erarbeitet hast, in für den Anfänger
verständlicher Form aufbereitet ist, wäre ich fast geneigt, mich an
deiner Kampagne für "C++ auf allem, was irgendwie rechnet" beteiligen.

Garantiert würde ich das tun, wenn es zusätzlich zum Buch noch eine
umfassende Template-Bibliothek gäbe, in der das Ganze als einfach zu
benutzende Klassen und Funktionen umgesetzt ist. Mit der Möglichkeit
einer einfachen und geradlinigen Programmierung ähnlich Arduino, aber
ohne dessen Effizienzeinbußen, wäre das die ideale Programmierumgebung,
nicht nur für Anfänger.

Aber vielleicht schreibst du dieses Buch und die Bibliothek ja gerade,
und wir können alle auf die baldige Veröffentlichung gespannt sein :)
Von einem C++-Anfänger wie Robert können wir das jedenfalls nicht
erwarten.


Ok, ich habe wieder viel zu viel geschrieben, wollte dem TE aber auch
nicht einfach ein unbegründetes

  "Vergiss für dein Vorhaben C++"

vor die Nase knallen, auch wenn das genau die Aussage ist, die ich
loswerden wollte :)

Wenn es schon C++ sein muss, wäre vielleicht tatsächlich Arduino eine
Option, aber das wird wahrscheinlich von den Kollegen nicht akzeptiert,
an deren Arbeitsweise Robert sich ja anpassen soll.

: Bearbeitet durch Moderator
Autor: F. F. (foldi)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Wenn es ein gutes Buch mit dem Titel
>
>   "C++-Programmierung auf 8-Bit-Mikrocontrollern für C++-Unkundige"
>
> gäbe, in dem alles Relevante (und nur das), was du dir in deiner
> C++-Laufbahn zu diesem Thema erarbeitet hast, in für den Anfänger
> verständlicher Form aufbereitet ist, wäre ich fast geneigt, mich an
> deiner Kampagne für "C++ auf allem, was irgendwie rechnet" beteiligen.

Das ist der Punkt.
Ganz im Anfang habe ich mir C und C++ angesehen. C++ hätte mir total 
gelegen, aber da C der Standard auf den µC's ist und es kein Buch gab, 
dass mir das für den µC beigebracht hätte, habe ich das Buch wieder in 
den Schrank gestellt. Selbst wenn ich damit hätte wunderschöne Windows 
Programme schreiben können. Wollte von Arduino auf C, weil nun so 
ziemlich alle Bibliotheken in C sind und man das nicht einmal gescheit 
einbinden kann, wenn man C nicht versteht.

C++ sieht für einen Anfänger nicht so kryptisch aus, wie ich finde.

Autor: Norbert S. (norberts)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Moin,

Yalu, Du hast die Situation m.M.n exakt erfasst.
Arduino ist keine Option, ich muss oder besser gesagt soll mich an C der 
Kollegen anpassen. Das ist/wird ein einheitlicher Stil, damit man 
austauschbar wird. Für Kündigung schlecht, für Urlaub gut.
Mehr nicht.
Ich werde nur das umsetzen, was auch bisher in Bascom möglich war. 
Vielleicht etwas eleganter, nur in C schlechter lesbar ;-)
Die hochtrabenden Sachen mache nicht ich sondern unsere Softwerker. Da 
will und muss ich gar nicht hin.
Ich sehe auch nichts, was in C plötzlich möglich wird was in Bascom 
nicht ging. Bascom ist eben "nur eine proprietäre Bastlersprache" und 
deswegen verpönt. Echte technische Vorteile von C (auf µC 8-Bit) konnte 
mir noch keiner nennen.

Naja und dann heisse ich Norbert, nicht Robert.
Unsere Chinesen haben aber auch teilweise Jahre gebraucht, den Namen 
halbwegs korrekt auszusprechen, da hiess ich teilweise auch lange Robert 
;-)

Gruß,
Norbert

Autor: F. F. (foldi)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> nur in C schlechter lesbar ;-)

Das liegt an dir selbst.

Autor: Elmi (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Also ich finde ja, wer C-lernt sollte sich gleich mal mit den 
MISRA-Regeln vertraut machen. Die verhindern nämlich die ganzen 
verwirrenden, Fehler erzeugenden Programmierstile, die in C möglich 
sind:
https://de.wikipedia.org/wiki/MISRA-C

Autor: Elmi (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Norbert, wenn ich mir noch den kleinen Hinweis erlauben darf: Wenn Du 
Deinen Informatikerkollegen den MISRA-Standard vorschlägst, wird ihr 
Kopf wahrscheinlich gleich rot glühend. Das macht aber nichts, warum 
sollen sie sich nicht auch an Programmierregeln für Standards halten, 
die jeder versteht?

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Elmi, das ist zum Einen schon gesunder Menschenverstand und zum Anderen 
sind diese Regeln bei uns für alle schon hinterlegt.
Jetzt steigen die in zertifizierte Programmierung für 
sicherheitsrelevante Dinge ein (damit wir das nicht in Hardware machen 
und umständlich abnehmen lassen müssen).
Die sind Kummer gewohnt :-)

Gruß,
Norbert

Autor: Hunsbuckel (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
MISRA C?

- rekursion verboten
- pointerarithmetik verboten
- dieses verboten und jenes verboten

Also C für Beamte?

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Moin,
>
> Aber ich sehe doch richtig, daß C eine Untermenge von C++ ist bzw. C++
> eine Erweiterung von C.

Norbert, ich denke in diesen Satz interpretierst Du etwas rein, was 
nicht ist.

Elektronik HW ist wohl mit Legospielen vergleichbar: grössere Vorhaben 
benötigen mehr Steine, mehr Farben, mehr Varianten d. Steine, also mehr 
und andere Transistoren, mehr Schaltungen, mehr OpAmps, weitere 
Logikfamilien. Das ist zwar in mehreren Dimensionen, aber immernoch 
linear.

Die selbe Überlegung lässt sich nunmal NICHT 1:1 auf Programmiersprachen 
SW übertragen werden. (hier vermute ich dein Knoten im Denken)

Programmiersprachen unterscheiden sich eben in Syntax, Semantik und 
Paradigmen.
In der einen kann man mit weniger Quellcode konziser dasselbe ausdrücken 
als in einer anderen, was gleichzeitig nicht implizieren muss dass dabei 
mehr oder anderen Maschinencode generiert wird.

Noch ein Beispiel: Datenstrukturen.
In ASM Quellcode steht kaum etwas zu Datenstrukturen (und die wenigsten 
BASICs f. uC erlauben eigene, strukturierte Datentypen zu definieren), 
das ist höchstens als Kommentar für den Leser. Es obliegt dann alleine 
dem Programmierer die Disziplin der Datenstrukturen einzuhalten wenn er 
Routinen schreibt welche damit umspringen. Von Assembler u. Linker ist 
da keine Unterstützung zu erwarten.

Höhere Programmiersprachen setzen (u.v.a.) da an. Das hat die Forschung 
schon vor den 70'er erkannt und entsprechende Programmiersprachen 
hervorgebracht. Danach ist aber nicht Stillstand eingetreten!

> Es besteht momentan überhaupt kein Bedarf für C++, warum sollte ich das
> dann jetzt lernen?

Weil es eben um SW, um das Programmieren geht!
Es geht nicht um den letzten Schrei und Trend, aber warum willst Du auf 
bewährte Erkenntnisse verzichten? Machst du nur Retroprojekte in TTL 
74xx Technik?

> Wie verbreitet ist C++ auf 8-Bittern? (Arduino zählt nicht, das ist wie
> Windows XP auf einen 486er zu quetschen).
Du stellst Fragen, zu einem Bereich wo Du zugibst keine Erfahrungen zu 
haben UND schliesst dabei einen Bereich an Antworten aus, welcher 
bestens zu deiner Frage passt?
Ich vergleiche das mit:
"""
Ich suche eine Schaltung für ein präzises Labornetzteil, max. 4 bipolare 
Transistoren. ZDiode + Emitterfolger reichen nicht mehr.
Es dürfen aber keine OpAmps sein und wehe es kommt mir einer mit 
Regelungstechnik.
"""
Solches fragen kann man sich gleich sparen...

Autor: Thosch (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hunsbuckel schrieb:
> MISRA C?
>
> Also C für Beamte?
Nee, eher so was wie C für Theoretiker, die es als Challenge betrachten, 
mit selbst auferlegten Handycaps zu programmieren.

Vergleichbar einem Schwimmer, der mit gefesselten Beinen startet, oder 
einem 100m-Läufer, der in einer Zwangsjacke läuft...

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Ich sehe auch nichts, was in C plötzlich möglich wird was in Bascom
> nicht ging. Bascom ist eben "nur eine proprietäre Bastlersprache" und
> deswegen verpönt. Echte technische Vorteile von C (auf µC 8-Bit) konnte
> mir noch keiner nennen.

Das liegt einfach daran, das es kaum Leute gibt, die sich sowohl mit
Bascom als auch mit C beschäftigen. Vielleicht kannst du demnächst ein
Urteil darüber abgeben als einer, der beide Welten kennt :)

Das mit den gezwungenermaßen mehrzeiligen Ausdrücken in Bascom ist mir
halt ein paarmal in hier veröffentlichtem Bascom-Code aufgefallen,
weswegen ich im Handbuch nachgeschaut habe, ob das wirklich nicht anders
geht.

Für dich mag das kein Problem darstellen, für mich gehört eine
mathematische Formel aber nur dann zerstückelt, wenn jedes einzelne
Fragment wieder eine logische Einheit bildet. Wenn es schwer fällt, sich
für die Zwischenergebnisse aussagekräftige Variablennamen auszudenken
(also nicht einfach tmp1, tmp2, tmp3 oder a, b, c), ist das ein Indiz
dafür, dass die Formel nicht aufgeteilt werden sollte.

Außerdem erinnert mich die Beschränkung auf eine Rechenoperation pro
Zeile zu sehr an Assemblerprogrammierung, die ich zwar nicht ablehne,
aber wenn schon Assembler, dann bitteschön echten Assembler ;-)

Ein weiteres Argument gegen Bascom und für C ist ganz einfach die
Verfügbarkeit auf verschiedenen Mikrocontrollern. Sollte sich dein
Arbeitgeber eines Tages dafür entscheiden, vom AVR auf eine andere
Controllerfamilie umzusteigen, ist dein gesamtes Bascom-Wissen
(zumindest für die Firma) auf einen Schlag wertlos. Mit C musst du dich
nur in die Eigenschaften des neuen Controllers einarbeiten und kannst
dann sofort wieder produktiv arbeiten. Dabei kannst du sogar die nicht
allzu zu hardwarespezifischen Teile des alten AVR-C-Codes mit wenigen
Modifikationen übernehmen.

> Naja und dann heisse ich Norbert, nicht Robert.

Oh, ich bitte um Entschuldigung.

In meinem ersten Beitrag habe ich das noch richtig gemacht. Aber nun
merke ich, dass auch ich älter werde ;-)

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Das liegt einfach daran, das es kaum Leute gibt, die sich sowohl mit
> Bascom als auch mit C beschäftigen. Vielleicht kannst du demnächst ein
> Urteil darüber abgeben als einer, der beide Welten kennt :)

Ich hoffe, daß ich das irgendwann kann.
Vor >10 Jahren hatte ich da mal was auf Spotlight mit dem hier präsenten 
Crazyhorse verglichen. Das tat sich nicht viel.
Bascom hat am Anfang etwas mehr Overhead aber dann tut sich das fast 
nix.

Das mit der Verfügbarkeit ist natürlich ein Hammerargument.
Mit Bascom geht nur AVR.
Ich plädiere aber doch nicht generell für Bascom (ausser für das Hobby).

Ich glaube wir sind hier durch.

Gruß,
Norbert

Autor: Elmi (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Autor: Thosch (Gast)
>Hunsbuckel schrieb:
>> MISRA C?
>>
>> Also C für Beamte?
>Nee, eher so was wie C für Theoretiker, die es als Challenge betrachten,
>mit selbst auferlegten Handycaps zu programmieren.

Ja, das sind die gefühlten 50.000 Softwaretheoretiker, die dafür gesorgt 
haben, dass dein Auto fährt.
MISRA-C ist eher nichts für Bastelbuden, in denen noch 
Spaghettiprogrammierung gepflegt wird.

Autor: Jobst Q. (joquis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Der Sketch verwendet 140 Bytes (0%) des Programmspeicherplatzes. Das
> Maximum sind 32256 Bytes.
> Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers, 2048
> Bytes für lokale Variablen verbleiben.
>
> Für die Pin Initialisierung und das toggeln werden 6 Byte Flash belegt,
> und 0 Byte Ram.
> Das bekommst du weder in C, noch mit deinem Basic, knapper hin.

Und wieso belegt er 134 Bytes für's Nichtstun? Vermutlich steckt da 
schon einiges drin, was die nur 6 Bytes Zusatz erklärt.

Unter 140 Bytes zu bleiben ist für ein toggelndes C-Programm kein 
Problem.

Autor: Hunsbuckel (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Elmi schrieb:
> Autor: Thosch (Gast)
> Hunsbuckel schrieb:
> MISRA C?
>
> Also C für Beamte?
>
> Nee, eher so was wie C für Theoretiker, die es als Challenge betrachten,
>>mit selbst auferlegten Handycaps zu programmieren.
>
> Ja, das sind die gefühlten 50.000 Softwaretheoretiker, die dafür gesorgt
> haben, dass dein Auto fährt.
> MISRA-C ist eher nichts für Bastelbuden, in denen noch
> Spaghettiprogrammierung gepflegt wird.

MISRA-C hat nun mit Spaghettiprogrammierung rein gar nichts zu tun ...
aber sehr wohl mit Philosophien deren Auswüchse dann so Unfug wie 
„geplante Qualität- und Management“, schwachsinnige DIN ISO 
Zertifizierungen 900x und folgende, Kulturwandel, KaiZen...
und „fahrende“ Autos gab es vor diesen skizzierten Schwachsinn auch 
schon!

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jobst Q. schrieb:
> Und wieso belegt er 134 Bytes für's Nichtstun? Vermutlich steckt da
> schon einiges drin, was die nur 6 Bytes Zusatz erklärt.

Die 6 Byte sind die 3 mindest notwendigen ASM Statements, um den Pin 
vorzubereiten und dann in der Schleife zu toggeln.

Dieses macht das gleiche, wie das OOP förmige.
Generiert exakt den gleichen Code.
int main()
{
  DDRD |= 0b00010000;
  for(;;) PIND =  0b00010000;
}



Die 134 Byte sind dem AVR-GCC Standard Initcode geschuldet.
Inclusive Stack Initialisierung und Interrupt Sprungleiste.
Alleine diese Interrupt Tabelle nimmt über 100 Byte


//--

Jobst Q. schrieb:
> Unter 140 Bytes zu bleiben ist für ein toggelndes C-Programm kein
> Problem.
Fällt mir schwer, das zu glauben...
Ich bitte dich um einen Gegentest!

Meine Beispiele sind für den ATMega328P Kompiliert worden.
Mit der Arduino IDE

: Bearbeitet durch User
Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Bascom hat da leider 190 Byte Overhead.
Der Pin toggelt dabei aber mit 3,2MHz bei 16MHz. 5 Takte für eine 
Schleife.
Die Initialisierung kann man bei Bascom aber auch abschalten.
Das sind dann 88 Byte:
$regfile = "M328PDEF.DAT"
$crystal = 16000000                                         'Chrystal
$noinit

Ddrb.5 = 1
Led Alias Portb.5

Do
  Toggle Led
Loop

Sorry...

Arduino F. schrieb:
> Die OOP Variante, für Pin toggeln:#include <CombiePin.h>
>
> Combie::Pin::OutputPin<4> out;
>
> int main()
> {
>   out.init();
>   for(;;) out.toggle();// 2,667MHz auf einem UNO
> }

So ist das aber natürlich auch ganz intuitiv lesbar. Fast wie 
gesprochene Spache!
Geiler Scheiss, muss ich auch lernen!

Bitte lasst uns mit dem Schwanzvergleich aufhören!
Ich hatte nur nach einem C-Buch gefragt!

Gruß,
Norbert

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

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:

Exakt so!
Ein lesenswerter Beitrag!

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

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Bitte lasst uns mit dem Schwanzvergleich aufhören!

Fang Du damit an und lass' Deine Kommentare über angeblich so unlesbares 
C++ sein.

Das Ardunio-Beispiel da kann man in C ziemlich ähnlich schreiben, dazu 
muss man nur die Funktionen des Objekts "out" in entsprechend benannten 
Funktionen unterbringen.
#include <wasauchimmer.h>

void out_init(void);
void out_toggle(void);

int main()
{
  out_init(); 
  for(;;) out_toggle();// 2,667MHz auf einem UNO
}


Statt out.init und out.toggle werden hier out_init und out_toggle als 
Funktionsaufrufe verwendet; die Implementierung überlasse ich dem 
geneigten Leser, die Prototypen stehen da schon mal.

Das ist C. Über die leeren Klammern von main() kann man sich streiten, 
aber davon abgesehen ist das vollkommen legales C.

Und das willst Du schließlich lernen.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Ok, vergesst es, das war alles nicht das Thema.
Ich lerne den Quatsch ausschliesslich weil es alle verwenden. Damit muss 
ich leben. Ich muss es ja nicht mögen.

Jetzt atmen wir alle nochmal tief durch und beruhigen uns:

Ich mag die Syntax nicht aber "so what", lerne ich das eben.
Das WIE war gefragt.
C++ lerne ich JETZT nicht, weil es bei mir (!) nicht angesagt ist.
Alle Compiler sind so gut oder so schlecht wie der, der damit arbeitet. 
Der Compiler ist nur ein kleiner Teil der Performance, das grösste 
Problem sitzt normalerweise vor dem Rechner.

So, nun entspannen wir uns alle hoffentlich etwas.
Sorry für alle "Anfeindungen", wenn sie denn so aufgefasst wurden.
Morgen ist Montag, da sollten wir heute abend vielleicht alle etwas 
runterfahren.

Gruß,
Norbert

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:

> Für heutige Hipster, die einen ganz ähnlichen Schreibstil
> pflegen, wäre der Text vielleicht sogar angenehmer zu
> lesen als ein in richtigem Deutsch geschriebener ;-)

A Gramma Tiker?

Autor: Timo (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
immer köstlich,wie selbst der Moderator dem Threadstarter sagt was er zu 
sagen und  zu fragane hat und was nicht..zu geil dieses Forum :-)
Wenn der Thmenstartet sagt, er möchte darüber nicht reden, kommen andere 
mit Komentaren wie..hier darf jeder sagen was er will und das bleibt 
auchs oo" lol zu geil hier
<hier mitzulesen ist einfach zum Kringeln:-)
Und wie immer ist der Fragesteller kaum weiter nach etlichen 
Bildschirmseiten sinnloser Kommentare...so geil

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der hat seine Buchempfehlungen bekommen.
Was er damit macht, ist seine Sache.
Und mehr wollte er offensichtlich nicht.

In einem 1/2 Jahr sollte er weiter sein.
Viel schneller wirds nicht gehen.

: Bearbeitet durch User
Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Nunja, ich kann selektieren.
Sinnlosen Quark von sinnvollen Hinweisen trennen.
Das geht schon.
Ist nur lästig, daß so viel Quatsch geschrieben wird, der mir Null 
weiter hilft.
Hier ging das aber bis vor Kurzem noch. Ist nur zum Ende hin etwas 
eskaliert.

Gruß,
Norbert

Autor: Elmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Norbert,
wenn durch BASCOM grundsätzlich Strukturen der Programmierung kennst, 
sollte das Erlernen von C kein Problem sein.

Als erstes muss man lernen das ";" am Ender der Zeile nicht zu 
vergessen. Das machen Anfänger trotz Hinweis immer.
Danach lernt man die grundsätzlichen Strukturen: if, while, for und was 
man für "printf" mit "#include" heranzieht.
Man muss wissen, das in einem Vergleich "==" statt "=" verwendet wird.
Dann noch der Minimaleinstatz von Pointern für die Parameterrückgabe bei 
Funktionen: int * wert im Funktionsrumpf und die Übergabe der 
Pointeraddresse mit &wert.
Dann vielleicht noch, dass man am Anfang eines Header-Files ein "#ifder 
SchonMalDagewesen" macht.
Das kann man mit Vorwissen in 2 Tagen lernen und dann schon mal 
grundsätzlich los legen.

Autor: udok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, eines der kompaktesten Tutorials ist von Kernighan:
https://www.lysator.liu.se/c/bwk-tutor.html

Die Hilfe zu den wichtigen Funktionen findest du auf der freebsd Seite:
https://www.freebsd.org/cgi/man.cgi?query=fprintf&...

Der C-Standard in der C89 Version ist sogar noch lesbar:
http://port70.net/~nsz/c/

Grüße,
Udo

Autor: Ralph S. (jjflash)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Viele Bücher zu C behandeln (fast) nur die Syntax der Sprache und setzen 
eine betriebsfähige Entwicklungsumgebung vorraus. Hierbei werden extrem 
häufig das später fast wichtigste zu C weggelassen, das Zusammenspiel 
von :

Präprozessor
Compiler
Linker

Einer der Gründe (wenn nicht der Hauptgrund) für den Erfolg des 
Arduino-Frameworks (auch wenn das ein Subset von C++ darstellt) dürfte 
sein, dass der Anwender sich ersteinmal mit den oben genannten Dingen 
NICHT beschäftigen muss und im Editor mit allen seinen Einschränkungen 
seinen Programmcode eingeben kann.

Die komplette Hardwareabstraktion ist "versteckt".

Als Elektronikausbilder hatte ich versucht, Auszubildenden die Sprache C 
(nicht C++) näher zu bringen, in dem ich ein vorgefertigtes Setup 
mitgegeben habe und eben auch erst einmal die Syntax nahe brachte, in 
dem sie einfach nur den Programmcode eingeben mußten.

Ich bin auf die Nase gefallen.

Auch wenn der Einstieg schwerer war, war es für das Verständnis danach 
einfacher, C zu erst auf Konsolenebene (für PC) zu praktizieren und C 
anhand von Makefiles zu steuern.

Das ging unter Linux auf Kommandozeile deutlich einfacher als unter 
Windows. Willst du C lernen, solltest du zuerst im Netz nach genau 
diesem Zusammenspiel Präprozessor, Compiler und Linker und deren 
Steuerung über Makefiles suchen.

Zum besseren Verständnis sollte auch die Begrifflichkeit dessen, was 
eine Library und was eine Kombination von *.h und *.c Dateien ist 
verstanden werden (auch wenn einige sagen, *.h und *.c seien quelloffene 
Bibliotheken).

Die Kombination von AVR und C ist Dank des AVR-GCC und der libc wirklich 
gut, da es schon einmal ein Linkerscript und einen Startupcode (wie bei 
32-Bit ARM Prozessoren) nicht benötigt.

Sinnvoll wäre es also, so bisher unter Windows gearbeitet wurde, evtl. 
ein Live-Linux System auf USB-Stick zu haben und darauf Experimente mit 
GCC (für PC) oder AVR-GCC zu starten.

Für ein Erarbeiten der Grundlagen dürfte tatsächlich der steinigere Weg 
über reine Texteditoren und "manuelles" Kompilieren und Linken mittels 
Makefiles nachhaltiger sein.

Suche also nach "Hallo Welt" Beispielen, die für den PC mittels 
Makefiles das Programm builden.

- spiele mit bedingter Kompilierung (Präprozessor) und erkenne, was mit 
#defines möglich ist und was nicht

- lerne die esentiellen Datentypen: char, int, float und Arrays zu 
diesen Datentypen

- lerne die (wenigen) syntaktischen Dinge der Programmsteuerung wie 
if-then-else, while, do, for

- lerne, ein Programm in Funktionen (Unterprogramme) zu zerlegen und wie 
man die Funktionen parametrisiert

- lerne die Gültigkeit von Variablen (lokale, globale und statische)

- lerne für was Zeiger wichtig sind und wie man mit Zeigern umgeht

- lerne, wie man Funktionen universell verwenden kann und lagere diese 
in *.h und *.c Dateipaare aus. Schreibe diese so, dass sich diese 
Dateipaare von Hardwarenah zu abstrahierten Funktionen aufbauen. Bspw. 
ein Paar zum Ansprechen der UART und ein weiteres Paar, das einen Parser 
darstellt und sich des Paares der UART nur noch bedient.

- lerne union und struct

Für all diese Dinge findest du unzählige Beispiele im Netz, aber 
zusammenhängend in einem guten Buch finde ich nichts mehr (früher gab es 
solche Bücher für MS-DOS, aber das ist 1000 Jahre her).

Wenn du das oben geschriebene verinnerlicht hast, kannst du auch einfach 
auf eine IDE (Atmel Studio, Eclipse, Embitz oder wie sie alle heißen 
mögen) umsteigen, wenn du das dann noch möchtest.

Vielleicht ist es an der Zeit, ein Buch zu schreiben, das dem Leser C 
näher bringt wie es in den 90er Jahren üblich war, angepasst an moderne 
Betriebssysteme in Verbindung mit µC.

Meinen Auszubildenden hat für das Erlernen der Syntax die (ur)alte 
Hilfefunktion des Turbo-C Systems von Borland geholfen (nachdem sie den 
Zusammenhang von Präprozessor, Compiler und Linker verstanden hatten).

Die Syntax selbst von C ist eher leicht (auch wenn mir sicherlich 
widersprochen wird).

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
udok schrieb:
> Ich glaube, eines der kompaktesten Tutorials ist von Kernighan:
> https://www.lysator.liu.se/c/bwk-tutor.html

Schön, kannte ich noch nicht :)

Man sollte aber keinesfalls den Disclaimer überlesen:

  "Disclaimer: This ``tutorial'' is presented as a historical document,
  not as a tutorial.  Although it has lost little of its didactic value,
  it describes a language that C compilers today do no longer
  understand: the C of 1974, four years before Kernighan and Ritchie
  published the first edition of ``The C Programming Language''."

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph S. schrieb:
> Viele Bücher zu C behandeln (fast) nur die Syntax der Sprache und setzen
> eine betriebsfähige Entwicklungsumgebung vorraus.

Empfehlung: "21st Century C" von Ben Klemens, IIRC bei O'Reilly. Davon 
soll es mittlerweile auch eine deutschsprachige Übersetzung geben.

> Auch wenn der Einstieg schwerer war, war es für das Verständnis danach
> einfacher, C zu erst auf Konsolenebene (für PC) zu praktizieren und C
> anhand von Makefiles zu steuern.
>
> Das ging unter Linux auf Kommandozeile deutlich einfacher als unter
> Windows.

Im aktuellen Windows 10 gibt es die Möglichkeit, diverse Linux-Werkzeuge 
direkt aus den Ubuntu-Repositories zu installieren und natürlich auch zu 
nutzen. IIRC heißt das Feature "Windows Subsystem for Linux" ("WSL") und 
sollte seit dem Creators Update stabil sein.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Sorry, zu viele der Antworten, da kann ich nicht auf alle eingehen.
Durch die Vielfalt der Antworten ergibt sich aber ein Bild.

Ich habe jetzt mit dem Buch "Grundkurs C" angefangen und das liest sich 
recht flüssig.
"Pelles C" auf dem Rechner installiert (darauf bezieht sich der Autor) 
und die ersten Beispiele funktionieren.
Speziell für mein Profil gibt es wohl nichts also werde ich doch die 
ersten Gehversuche auf dem PC machen, um die grundlegenden Unterschiede 
von C vs. Basic zu verstehen.
Mir laufen da Dinge über den Weg, die ich schon wusste aber es explizit 
nochmal zu lesen (definiert) ist nicht schlecht.
Ich glaube das Buch passt ganz gut.
Für den Transfer auf µC brauche ich dann nur Tutorials zum Atmel Studio. 
Gibt es ja genug. Wie man µC programmiert ist dann ja kein Problem.

Für meinen Zweck aber irgendwas mit Linux und Console vorzuschlagen - 
och nö.

Gruß,
Norbert

: Bearbeitet durch User
Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Für meinen Zweck aber irgendwas mit Linux und Console vorzuschlagen -
> och nö.

Der GCC (den du nunmal mit an Sicherheit grenzender Wahrscheinlichkeit 
verwenden wirst) stammt nunmal aus der Linux-Ecke. Darüber hinaus sind 
auch andere Compiler grundsätzlich Kommandozeilenwerkzeuge und werden 
lediglich aus einer IDE heraus aufgerufen, wobei dieser Aufruf zumeist 
automagisch stattfindet. Man klickt auf Play und schon passiert 
irgendwas und am Ende blinkt die LED. Um diese "schwarze Magie" etwas 
transparenter zu machen empfiehlt sich meiner Meinung nach das erlernen 
des Zusammenspiels zwischen Compiler und Linker, etc., genauso wie Ralph 
S. es sehr schön beschrieben hat. Das kannst du natürlich auch nativ 
unter Windows alles machen, schließlich gibt es den GCC ja auch für 
Windows aber es ist halt alles etwas komplizierter als in einer 
vernünftigen *nix-Umgebung. Wenn du es also ordentlich lernen willst, 
dann schnapp dir das Linux-Subsystem for Windows, MSYS2 oder von mir aus 
auch gleich eine richtige (virtuelle) Linux-Maschine.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

So sehr ich diesen Ansatz verstehe (vernünftig lernen) - das will ich 
gar nicht.
Ja, klingt blöd oder ignorant aber ich bin Hardwaremensch und in dieser 
Materie nur Anwender.
Das Atmel-Studio verwendet den GCC? Schön, das reicht mir dann aber auch 
an Info.
AVRdude wird verwendet, auch schön. Bisher nehme ich den und mache mir 
Skripte dafür, nix Bascom.
Tiefer in den Maschinenraum will ich gar nicht. Unsere Spezis haben eine 
funktionierende Toolchain, in die ich nur einsteigen muss.
Da fange ich garantiert nicht mit Linux an.

Wäre ich Student und wollte komplett neu einsteigen, wäre ich sofort 
dabei aber meine Motivation, Zeit und Umstände sind nunmal ganz anders.

Gruß,
Norbert

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Ich habe jetzt mit dem Buch "Grundkurs C"

Das ist sehr gut, weil sofort jede Kleinigkeit erklärt wird. ZB (void). 
Wird sonst in anderen Büchern nicht erklärt.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
F. F. schrieb:
> Norbert S. schrieb:
>> Ich habe jetzt mit dem Buch "Grundkurs C"
>
> Das ist sehr gut, weil sofort jede Kleinigkeit erklärt wird. ZB (void).
> Wird sonst in anderen Büchern nicht erklärt.

Geeeenau. Das war tatsächlich das erste Aha-Erlebnis.

Autor: x^2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Empfehlung: "21st Century C" von Ben Klemens, IIRC bei O'Reilly. Davon
> soll es mittlerweile auch eine deutschsprachige Übersetzung geben.

Anstatt sich den ernsthaften Themen zu widmen entgleitet der Autor 
regelmäßig in "persönliche Angewohnheiten", über die er aber gerne 
seitenlang berichtet. Er scheint Konstrukte gerne auch nach der Anzahl 
gedrückter Tasten zu bewerten. Möglicherweise hat er eine spezielle 
Tastatur, bei der jeder Tastenanschlag zu heftigen Stromstößen führt. 
Das wäre eine Erklärung.

Kapitel 7: Ich habe noch eine wirrere Ansammlung von schlechten Ideen 
gesehen. Beim Unterkapitel "Deprecate Float" habe ich dann aufgehört 
(bereits das Kapitel "Enums and Strings" hat heftige Schmerzen 
verursacht).

Gäb's in C nen 512-Bit Fließkommatyp hätte der Autor wohl "Deprecate 
Double" geschrieben. Begründung jeweils "Genauigkeit". Das ist bei 
Fließkomma nunmal so. Für wen Genauigkeit Thema ist, der muss sich eine 
arbitrary precision library nehmen. Ich könnte auch schreiben "deprecate 
unsigned" und begründen -42 ließe sich nicht damit darstellen. Dass ein 
Target aber vielleicht eine IEEE754 FPU hat, "float" 
hardwarebeschleunigt läuft und "double" komplett in Software emuliert 
wird (und dann langsam wie eine Schildkröte ist), diese Gedanken sind 
dem Autor wohl nicht gekommen.

Auch wie man enum's einsetzt versteht der Autor offenbar nicht. 
Begründung warum sie schlecht sind war, erstens gibt es dann ja einen 
globalen Typ mehr, da sie typischerweise in Header Files gepackt werden, 
ja und zweitens sieht's doof aus. Zitat:
At that point, an innocuous and sensible idea has fallen apart. I don’t want to type these messes, and I use them so infrequently that I have to look them up every time (especially because many are infrequently used error values or input flags, so there’s typically a long gap between each use). Also, all caps reads like yelling

Sorry, aber so ein Buch kann man niemandem ernsthaft empfehlen wollen.

Autor: Jens G. (jensg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
visitor schrieb:
> Also wenn du die AVR's gut kennst und noch heute damit unterwegs bist,
> dann empfehle ich dir das Buch von Günter Schmitt vom Oldenbourg Verlag.
> Dort werden die Grundlegen Dinge von C und soagr Assembler erklärt und
> dann anhand vieler typischen AVR Schnittstellen und Projkte in C und
> Assembler erklärt und in Listings zur Verfügung gestellt.
>
> https://www.degruyter.com/view/product/221318

Ich habe das Buch in der 3.Auflage vor mir liegen. Es ist sehr 
Hardwarenahe geschrieben - im Buch geht es sehr viel auch um Assembler. 
Der C-Code wird verwendet um Assembler darin "einzuwickeln" -- Ich 
persönlich würde nicht mehr sehr viel in hardwarenaher Weise lernen 
wollen. Was man damit entwickelt .. lässt sich später nicht mehr 
verwenden.

C lernen ist gut --  später kann eventuell noch Cpp dazu kommen. ... und 
Arduino ist etwas zwischen beiden Welten (C .. Cpp).

Weil ich faul bin und nicht zu tief in die Hardware gehen möchte, 
verwende ich Arduino. Sehr schnell ein Demo aufbauen geht immer. Es gibt 
sehr viel Unterstützung durch die vielen offen gelegten Quellen.

Autor: +/- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C-Neuling schrieb:

> .... bei C von Null startet und dann nur auf das eingeht, was für
> µC gebraucht wird, das wäre schön. Es darf gerne etwas oberflächlich
> sein. Programmieren kann ich im Prinzip, nur eben nicht C.
> Also alles was über einfaches Basic hinausgeht. Dazu vielleicht noch
> Einführung ins Atmel-Studio, was ja auch nicht gerade intuitiv ist,...

Du wirst wie bereits etabliert ANSI-C wollen.
such mal nach 'AVR+μC+ANSI-C' gibt paar interessante Treffer in dt. 
Sprache.


http://homepages.uni-regensburg.de/~erc24492/

SuMa:  site:http://homepages.uni-regensburg.de/~erc24492/PDFs/

Autor: flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach und effektiv:

"C Programmierung mit einfachen Beispielen" von Jürgen Wolf
----------------------------------------------------------

Gibt es wahrscheinlich in fast jeder Bücherei.


Leseprobe:
https://books.google.de/books?id=7bxY6Bze5u4C&prin...

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Ich frage einfach mal hier weiter.
Also, Pelles C. Ganz simples Programm:
#include <stdio.h>

int main (void) {
  printf("Mein erstes Programm\n");
  return 0;
}
Rufe ich das aus der IDE auf, bleibt das Fenster der Konsole stehen, wie 
bei einer Batch mit "Pause" am Ende.
"Press any key to continue"
Mit Doppelklick aus dem Explorer auf die .exe blitzt die Konsole nur 
kurz auf und ich sehe die Ausgabe natürlich nicht.
Kann mir das einer kurz erklären? Was entspricht dem "Pause" in einer 
Batch?

Klingt jetzt nach einer albernen Kleinigkeit aber wenn ich das schon 
durcharbeite, will ich sowas nicht übergehen.

Gruß,
Norbert

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht kannst du dir was mit getc() basteln.

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Klingt jetzt nach einer albernen Kleinigkeit aber wenn ich das schon
> durcharbeite, will ich sowas nicht übergehen.

Ist aber Windows und hat mit deinem eigentlichem Programm nichts zu tun.
Das verhält sich immer gleich.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Ihr sprecht in Rätseln.
Was soll ich mit getc() basteln? So ist diese Antwort irgendwie sinnlos.

Warum bleibt das Fenster offen, wenn ich das aus der IDE aufrufe und 
schliesst sich sofort, wenn ich es aus dem Explorer aufrufe?
Ja, ist Windows, auch Pelles C. und das ist eben nicht gleich.

Habe ich wirres Zeug geschrieben oder warum sind die Antworten so 
komisch?

Gruß,
Norbert

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Was soll ich mit getc() basteln?

Eine Abfrage eines Tastendrucks, so dass das Fenster immer offen bleibt, 
auch wenn es nicht aus der IDE gestartet wird

Autor: F. F. (foldi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Was ist daran nicht zu verstehen?
Du fragst wieso das Fenster einmal auf bleibt und wieso das durch 
anklicken der Exe wech ist.

Dann musst du cmd /k ausführen und dann die aufrufen.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Norbert S. schrieb:
>> Was soll ich mit getc() basteln?
>
> Eine Abfrage eines Tastendrucks, so dass das Fenster immer offen bleibt,
> auch wenn es nicht aus der IDE gestartet wird

Moin,

Das habe ich mir zwar gedacht aber der Compliler meckert.
[c]
#include <stdio.h>

int main (void) {
  printf("Mein erstes Programm\n");
  getc();
  return(0);
}
[/]
Kennt Stdio.h getc() nicht?

Warum geht das dann, wenn ich es aus der IDE aufrufe?

Gruß,
Norbert

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Warum geht das dann, wenn ich es aus der IDE aufrufe?

Weil die das Fenster aufhält ( /k ).

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
F. F. schrieb:
> Norbert S. schrieb:
>> Warum geht das dann, wenn ich es aus der IDE aufrufe?
>
> Weil die das Fenster aufhält ( /k ).

Aha, und das mache ich wie, wenn ich die .exe im Windows Explorer nur 
per Doppelklick ausführen will?
In einer Batch ist das "Pause", wie mache ich das in meinem "Hello 
World" Progamm?

Gruß,
Norbert

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe ich gerade schon unter Windows 10 geguckt.
Bei älteren Versionen (XP) konnte man das unter "Eigenschaften" 
einstellen.
Das ist bei mir nicht mehr drin.

Im DOS Fenster aufrufen. Wenn das nicht offen bleibt, dann erst cmd /k 
und dann das Programm aufrufen.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Kennt Stdio.h getc() nicht?

Doch, aber getc erwartet ein Funktionsargument.

Richtig wäre

  getc(stdin);

oder

  fgetc(stdin);

oder einfach

  getchar();

Diese Methode funktioniert leider nicht mehr richtig, wenn du in deinem
Programm später die Funktion scanf benutzt.

Besser (und ohne dein Programm mit irgendwelchem getchar-Zeugs am Ende
verunstalten zu müssen) ist es, das Programm aus einer bereits
geöffneten Konsole zu starten. Diese Konsole bleibt auch nach Beendigung
des Programms offen, so dass du dieses (auch nach Änderungen und
Neukompilierung) in derselben Konsole immer wieder starten kannst.

Das spielt aber alles keine Rolle mehr, wenn du auf den Mikrocontroller
gehst, denn dieser kennt weder eine Konsole noch endende Programme :)

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Aha.
Pelles C ruft das also mit /k auf.
Direkt aus dem Windows Explorer geht das nicht, ich müsste also von der 
Kommandozeile aus die .exe mit /k aufrufen. Sehr geil, wenn die in 
...Dokumente... liegt.
Da geht der Pfad fast über die gesamte Bildschirmbreite.
Gibt es keinen Befehl in C, der das Fenster offen hält?
Also wie "Pause" in einer Batch?

Gruß,
Norbert

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Was soll ich mit getc() basteln? So ist diese Antwort irgendwie sinnlos.

Du solltest MIT der Sprache arbeiten.
Und nicht dagegen.
Denn das "dagegen", verlierst du.

Oder anders formuliert:
> Du musst dein Ändern leben.

Autor: Norbert S. (norberts)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Norbert S. schrieb:
>> Kennt Stdio.h getc() nicht?
>
> Doch, aber getc erwartet ein Funktionsargument.
>
> Richtig wäre
>
>
>
>   getc(stdin);
> 
>
> oder
>
>
>
>   fgetc(stdin);
> 
>
> oder einfach
>
>
>
>   getchar();
> 
>
> Diese Methode funktioniert leider nicht mehr richtig, wenn du in deinem
> Programm später die Funktion scanf benutzt.
>
> Besser (und ohne dein Programm mit irgendwelchem getchar-Zeugs am Ende
> verunstalten zu müssen) ist es, das Programm aus einer bereits
> geöffneten Konsole zu starten. Diese Konsole bleibt auch nach Beendigung
> des Programms offen, so dass du dieses (auch nach Änderungen und
> Neukompilierung) in derselben Konsole immer wieder starten kannst.
>
> Das spielt aber alles keine Rolle mehr, wenn du auf den Mikrocontroller
> gehst, denn dieser kennt weder eine Konsole noch endende Programme :)

Moin,

Danke für die Hilfe.
C heisst also, daß ich irgendwelche Zeichenfolgen eintippe, bei denen 
ich keinen Schimmer habe, was die tun?
Wenn ich Pech habe, kollidiert das mit anderen Funktionen?
Und dieses Konzept beherrscht die Embedded-Programmierung? WTF?
Da verstehe ich C-Hater jetzt etwas besser aber ich werde mich wohl 
durchbeissen müssen und damit leben.

Mit
getc(stdin);

Funktioniert es tatsächlich.

Gruß,
Norbert

Autor: F. F. (foldi)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Angenommen dein Programm heißt C.exe.
Du legst eine Datei mit dem Texteditor an, bennenst sie um, in (c.bat 
würde sich anbieten) eine Batch Datei. Die dann wie im Bild aussieht.

(Mein Gott, wie lange man schon kein DOS mehr gemacht hat)

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Mit
>   getc(stdin);
>
> Funktioniert es tatsächlich.
Sach ich doch!

Norbert S. schrieb:
> C heisst also, daß ich irgendwelche Zeichenfolgen eintippe, bei denen
> ich keinen Schimmer habe, was die tun?
Das ist ein Irrtum!

Bitte, gib C, oder ich würde dir gar zu C++ raten, eine Chance.
Neben einigen Macken, steckt da VIEL Sinn drin.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Norbert S. schrieb:
> C heisst also, daß ich irgendwelche Zeichenfolgen eintippe, bei denen
> ich keinen Schimmer habe, was die tun?

Hast du dein neues C-Buch etwa schon komplett durchgearbeitet?

Wenn ja, dann taugt das Buch anscheinend doch nichts.

Wenn nein, wird der Schimmer ganz sicher noch kommen.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Und dieses Konzept beherrscht die Embedded-Programmierung? WTF?
Nicht nur die!

ALLE Betriebssysteme, ihr Kern, sind größtenteils in C geschrieben.
(zumindest alle, welche mehr als 0,001% Marktanteil haben)

Autor: Norbert S. (norberts)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Moin,

Nein, ich habe eben erst angefangen mit dem Buch. Ich hoffe, es wird im 
Verlauf dann klarer.
Toll ist der Start aber nicht, wenn man gleich mal DOS bemühen muss, das 
kann es doch heute nicht mehr sein.

Das Buch ist wirklich nicht schlecht, bei Anderen wäre ich garantiert 
schlechter aufgehoben, ich habe ein paar Proben gelesen.
Didaktisch ist aber alles eigentlich Schrott. Programmierer haben wohl 
ein so verbogenes Hirn, daß sie ihre Kenntnisse nicht mehr verständich 
vermitteln können.
Ich bedanke mich für die Hilfe hier aber genau das kann man hier auch 
sehen.


Gruß,
Norbert

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Norbert S. schrieb:
> aber genau das kann man hier auch sehen.

Tipp:
Du solltest freundlich mit deinen Problemen umgehen.

Autor: Norbert S. (norberts)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Norbert S. schrieb:
>> aber genau das kann man hier auch sehen.
>
> Tipp:
> Du solltest freundlich mit deinen Problemen umgehen.

Das ist ein extrem schöner Satz.
Das sollte man sich in die Wand meisseln.
Sind ja auch alles keine Probleme, sondern nur spannende 
Herausforderungen.

Gruß,
Norbert

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

: Bearbeitet durch User
Beitrag #5396070 wurde vom Autor gelöscht.
Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Norbert S. schrieb:
> Toll ist der Start aber nicht, wenn man gleich mal DOS bemühen muss, das
> kann es doch heute nicht mehr sein.

Das kann ich verstehen, DOS ist wirklich total 80er. Deswegen hatte ich 
ja oben auch den Hinweis auf Linux gegeben.

Abgesehen davon ist es wohl das normalste auf der Welt, dass das 
DOS-Fenster nach Programmbeendigung zugeht. Das ist auch garantiert 
unabhängig von der Programmiersprache. Wie sollte man denn sonst auch 
sinnvoll verschiedene Programme per Skript steuern können, wenn man nach 
jedem Einzelprogramm eine Taste drücken muss?

GUI kannst du natürlich haben. Qt, GTK, WxWorks, Visual-C++, etc. stehen 
dir zur Verfügung. Einfacher macht es die Sache aber garantiert nicht.

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber was heute wirklich schade ist, dass man das nicht mehr einstellen 
kann.
Habe mich gestern noch etwas damit befasst und ein paar Schalter in der 
Registy gefunden.
Ohne neu zu booten hatten sie zumindest keine Auswirkungen.
Muss noch im dicken XP Buch blättern und sehen, ob da was steht.

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seit Windows 7 ist der Bedarf Windows zurecht zu biegen nicht mehr da.
Windows 10, können alle sagen was sie wollen, ist das beste Windows was 
MS bisher zustande gebracht hat.
Man muss diesen Scheiß mit den Apps ja nicht nutzen und Cortana kann man 
auch beibringen die Fresse zu halten.

Autor: Bernd N (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
F. F. schrieb:
> Seit Windows 7 ist der Bedarf Windows zurecht zu biegen nicht mehr da.
> Windows 10, können alle sagen was sie wollen, ist das beste Windows was
> MS bisher zustande gebracht hat.
> Man muss diesen Scheiß mit den Apps ja nicht nutzen und Cortana kann man
> auch beibringen die Fresse zu halten.

WIN-10 muß man noch viel mehr abgewöhnen bevor man es benutzen kann. M$ 
hat es geschafft das sich der Computer permanent mit sich selbst 
beschäftigt. Wie dem auch sei, hier gehts um C lernen.

@Norbert, ich kann deinen Frust gut verstehen. Ich habe vor 15 Jahren 
auch den Wechsel von ASM nach C vollzogen und ich gebe dir recht, ein 
gutes Buch ist nicht einfach zu finden. Ich habe damals ein Buch mit dem 
Titel "Der Keil C Compiler" verwendet + diverse Hilfen aus dem Netz. Ich 
habe das mit Freude und freiwillig gelernt.

Bei dir merkt man aber deutlich das du scheinbar C lernen musst. Mein 
Tip, erinnere dich wie du Bascom gelernt hast und versuche mal die 
einfachsten Programme aus dieser Zeit in C zu übersetzen. Das sollte dir 
helfen.

Dein Konsolen Beispiel läuft ja im Prinzip. Was du bemängelst ist 
Systembedingt. Pack dein Programm in eine Endlosschleife, dann bleibt 
das Fenster auch offen. Mit control+c kannst du es dann abrechen.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Norbert, du hängst dich gerade an einem Problem auf, das

1. überhaupt nicht C-spezifisch ist und

2. deinem Ziel, µCs zu programmieren, in keiner Weise im Weg steht.

Für die einfachste Lösung musst du, wie du selber schon erkannt hast,
überhaupt nichts tun:

Norbert S. schrieb:
> Rufe ich das aus der IDE auf, bleibt das Fenster der Konsole stehen, wie
> bei einer Batch mit "Pause" am Ende.
> "Press any key to continue"

Reicht das nicht?

Warum willst du das Programm unbedingt per Doppelklick starten?

Du willst ja schließlich C lernen und nicht deine Programme an andere
weitergeben, die die IDE nicht installiert haben.

Wenn du das Programm außerhalb der IDE mit Doppelklick startest, kommst
du nicht in den Genuss des Debuggers, der gerade beim Lernen oft eine
große Hilfe darstellt, da du damit Programme schrittweise ausführen
lassen kannst.

Auf dem AVR, wo du letztendlich hin willst, gibt es keinen Doppelklick.
Da startet das Programm automatisch nach einem (Power-Up-)Reset.

Also: Vergiss den Doppelklick einfach komplett und schau lieber zu, dass
du mit dem Lernen von C vorankommst :)

Autor: Martin H. (horo)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert S. schrieb:
> aber der Compliler meckert

Der wird nicht „meckern“, sondern eine Fehlermeldung wie diese geben:
g.c:4:2: error: too few arguments to function ‘_IO_getc’
  getc();
  ^

Und zum Problem, dass ein Kommandozeilenprogramm eine Kommandozeile 
braucht, wurde schon einiges weiter oben geschrieben. Du hast es ja so 
programmiert, dass ein Text ausgegeben wird (printf(..);) und 
anschließend das Programm sich beendet (return 0;). Wenn Du statt eine 
Zeile per printf() auszugeben einige Tausend Textzeilen schreibst, dann 
siehst Du, solange das Programm läuft, auch eine Aktion. Aber mit return 
ist Schluss (und sogar, wenn Du return weglässt, ist Schluss).
Sieh es so, bevor Du mit dem Flugzeug in die Luft gehen willst, musst Du 
erstmal üben, auf dem Flugplatz zu rollen. Und manchen Menschen reicht 
das Rollen und die nehmen statt des unhandlichen Jumbos 
(Windows-Programm mit Klick und Bunt und Soße und scharf) lieber den 
Porsche (das Command-Line-Interface).

Autor: Martin H. (horo)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Auf dem AVR, wo du letztendlich hin willst, gibt es keinen Doppelklick.
> Da startet das Programm automatisch nach einem (Power-Up-)Reset.

Genau, und das Verhalten deined ersten Programms ist dort auch ähnlich, 
das Programm läuft durch, schreibt einen Text auf's LCD, UART,... und 
beendet sich. Auf dem AVR willst Du aber im Normalfall, dass das 
Programm immer wieder was tut (z.B. Deine LED blinken lässt oder Deine 
Heizung regelt, tagelang, wochenlang, ein Leben lang...). Du musst also 
im C-Programm Vorkehrung treffen, dass es kein „One-Shot“ ist, sondern 
durch Kontrollstrukturen (...das kriegen wir später...) ein geregelter 
Ablauf stattfindet und Du nie ans Ende von main() kommst.

Autor: Norbert S. (norberts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Ich gehe jetzt freundlich mit dem Problem um und habe es ja nun auch 
verstanden.
Das wird jetzt so hingenommen und gut is'.

Ja, ich muss C lernen aber das ist mehr eigener Antrieb als wirklich 
Druck von aussen. Ohne C bin ich nicht übermorgen meinen Job los und mit 
C gibt es nächstes Jahr nicht 10k/a mehr. Ich kann dann einfach mehr 
interessante Dinge machen.
Ich WILL es können (das ist das Ziel) und dafür MUSS ich es lernen.
Das Lernen ist kein Selbstzweck weil ich neugierig bin. Wenn man sich 
das einfach kaufen könnte, würde ich das tun aber das dauert wohl noch 
etwas, bis die Neurologie so weit ist.

Gruß,
Norbert

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Auch wenn jetzt gleich von allen Seiten gezetert wird, schlage ich vor 
gleich ins Wasser zu springen. In den Links die ich da oben gepostet 
habe, sind genug praktische Beispiele und Erklärungen der C Sprache 
soweit sie Embedded Applications betreffen, gegeben.

Da bei embedded immer notwendig ist, daß die Hardware detailliert für 
jede Anwendung spezifisch eingerichtet werden muß, ist es keine Schande 
abzuschauen und nachmachen was hunderte Ingenieure und Engagierte schon 
vorher gemacht haben. Die C Sprache wurde doch dort detailliert 
beschrieben. Man operiert doch einen Blinddarm auch nicht immer auf 
verschiedenste Weise. Es ist Zeit, daß Du bewaffnet mit Bord und Tools 
ins Wasser springst und Dir mal die Wellen des Wassers zu Gemüte führst. 
Das ganze Buch lesen hilft da eher oft wenig. Das Geschick kommt mit dem 
Anwenden und Tuen und Fehler machen und zu beheben. Da lernst Du Sprache 
automatisch. Beim Tischler fallen ja auch Späne und ein inkorrekter Code 
Abschnitt kostet meistens kein wirkliches Lehrgeld.

Also, die Zeit der Gründe ist vorbei und wandere den vorgezeichneten Weg 
zum Erfolg, und, jetzt an die Arbeit!

Ich finde es wird hier einfach zu viel geredet und diskutiert und 
prokrastiniert. Manchmal hindert das Forum anstatt zu beschleunigen und 
man fällt in die Analyse Paralyse aus der man schwer wieder heraus 
kommt.

Das Internet ist Dein Freund. Es gibt genug kompetente Seiten als 
Nachschlag Referenz.

Autor: Alexander S. (alesi)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Das sind alle praktische Werke mit Augenmerk auf Embedded.

Vielen Dank an Gerhard O. für die interessanten Links.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino F. schrieb:

> Ich behaupte: "Hat man sich erst einmal auf die prozedurale Sicht
> eingeschossen, ist man für die OO Sicht verdorben."
>
> Gut, vielleicht nicht gänzlich verdorben, für immer, aber der Umschwenk
> auf die OOP fällt einem dann erheblich schwerer, als es sofort zu
> lernen.

Das ist sowas von wahr, aber trotzdem irgendwie doch falsch.

Ich verstehe ganz genau, was du meinst, denn ich habe mir das OO-Konzept 
vor nunmehr 25 Jahren selber unter Schmerzen beigebogen und das war 
wirklich nicht einfach.

Genau genommen habe ich es am Ende nur deshalb verstanden, weil ich es 
in meiner Verzeifelung von ganz unten betrachtet habe, aus der Sicht des 
Assemblerprogrammierers. Erst das hat mir das Konzept der Sache und die 
Bedeutung der Schlüsselworte wirklich klar gemacht. Danach war es dann 
einfach und danach war ich auch in der Lage, das OO-Konzept sinnvoll zu 
nutzen. Und von dem damaligen ObjectPascal auch auf diverse andere 
OO-Sprachen zu übertragen. Unter anderem auch C++...

Allerdings bin ich immer noch der Meinung: C war schon eine ziemlich 
beschissene Programmiersprache, C++ ist eine noch sehr viel 
beschissenere Sprache. Weil: sie fördern beide konzeptionell völlig 
unnötige Programmierer-Fehler. Das ist nicht das, was eine Hochsprache 
tun sollte. Die hat einfach zu sein. Einfach zu lernen und einfach 
anzuwenden. Ist sie es nicht, brauch' ich sie nicht, denn dann 
erleichtert sie mir nix.

Wenn ich was schwieriges will, programmiere ich einfach direkt in 
Assembler. Das schränkt zumindest die Lese-Notwendigkeit zur Behebung 
der Fehler von vieltausendseitigen obszönen Machwerken auf ein paar 
Dutzend Seiten "instruction set reference" der jeweiligen 
Zielarchitektur ein. Und OO ist selbst
in Assembler möglich, nur nicht so hübsch komfortabel...

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Ich verstehe ganz genau, was du meinst, denn ich habe mir das OO-Konzept
> vor nunmehr 25 Jahren selber unter Schmerzen beigebogen und das war
> wirklich nicht einfach.

Laß' mich raten: Du hast, genauso wie ich seinerzeit, immer gedacht daß 
da noch irgendetwas sein müsse, das Du nicht verstanden hast. Und am 
Ende hat sich herausgestellt, daß das Ganze viel einfacher ist als 
erwartet. ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.