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?
C-Neuling schrieb:> Oder ganz anders vorgehen?
Schau Dir mal den Vortrag an:
https://www.youtube.com/watch?v=YnWhqhNdYyk
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 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.
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.
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.
> 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.
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.
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.
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_185740101_TE_item
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
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!
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.
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
> 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.
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.
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
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.
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.
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.
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.
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
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?
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.
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
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.
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
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.
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.
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/index.htm#_top
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)
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_185740101_TE_item
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-TutorialNorbert 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
1
s=3*(x-1)+4
musst du in Bascom schreiben:
1
tmp1=x-1
2
tmp2=3*tmp1
3
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 :)
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 ...
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.
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.
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 :)
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?
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.
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 ;-)
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).
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
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!
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
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
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!
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
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.
Was willst du denn hören?
Hier mal ein leeres Arduino Programm:
1
intmain()
2
{
3
for(;;);
4
}
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:
1
#include<CombiePin.h>
2
3
Combie::Pin::OutputPin<4>out;
4
5
intmain()
6
{
7
out.init();
8
for(;;)out.toggle();// 2,667MHz auf einem UNO
9
}
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!
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
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.
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
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
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.
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
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.
@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.
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.
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
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
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?
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
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...
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...
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 ;-)
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: 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.
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.
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!
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.
1
intmain()
2
{
3
DDRD|=0b00010000;
4
for(;;)PIND=0b00010000;
5
}
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
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:
1
$regfile="M328PDEF.DAT"
2
$crystal=16000000'Chrystal
3
$noinit
4
5
Ddrb.5=1
6
LedAliasPortb.5
7
8
Do
9
ToggleLed
10
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
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.
1
#include<wasauchimmer.h>
2
3
voidout_init(void);
4
voidout_toggle(void);
5
6
intmain()
7
{
8
out_init();
9
for(;;)out_toggle();// 2,667MHz auf einem UNO
10
}
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.
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
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?
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
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.
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
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.
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).
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''."
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.
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
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.
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
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.
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.
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:
1
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.
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.
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/
Moin,
Ich frage einfach mal hier weiter.
Also, Pelles C. Ganz simples Programm:
1
#include<stdio.h>
2
3
intmain(void){
4
printf("Mein erstes Programm\n");
5
return0;
6
}
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
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.
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
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
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.
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
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
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.
Norbert S. schrieb:> Kennt Stdio.h getc() nicht?
Doch, aber getc erwartet ein Funktionsargument.
Richtig wäre
1
getc(stdin);
oder
1
fgetc(stdin);
oder einfach
1
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,
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
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.
>> 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
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)
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.
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.
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)
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
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
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.
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.
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.
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.
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 :)
Norbert S. schrieb:> aber der Compliler meckert
Der wird nicht „meckern“, sondern eine Fehlermeldung wie diese geben:
1
g.c:4:2: error: too few arguments to function ‘_IO_getc’
2
getc();
3
^
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).
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.
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
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.
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...
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. ;-)
Thread beobachten
Seitenaufteilung abschalten