Möchte mal die Frage stellen, welche Bücher zum Erlernen von C für Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert wären. Ich habe mir AVR-Mikrocontroller Programmierung in C von Heimo Gaicher und Micro-Controller Technik mit AVR , Programmierung in Assembler und C von Günter Schmitt und Andreas Riedenauer zugelegt, wobei der Schwerpunkt des letzteren Werkes eher bei Assembler liegt. Das Buch von Heimo Gaischer ist schon mal ausgezeichnet aufgebaut. Der Kurs hier im Mikrocontroller.net ist ja auch sehr gut. Kurse auf Youtube liegen mir nicht so, ich habe Bücher lieber. Gibt es von euch ein paar Etzes für andere Bücher? (Grundlagen-Kenntnisse vorhanden)
:
Clean Code / Martin Working effectively with Legacy Code / Feathers The Pragmatic Programmer / ? Test Driven Development / Beck (Sorry alle Englisch) Nicht nur fuer C, aber die gelernte dinger sind fuer viele Programmiersprache nutzlich Ich habe auch irgendwo ein deutsches buch wo u.a.DoxyGen und C-Unit werden besprochen fuer benutzung mit C, kann exacten titel jetzt nicht finden Grusz Patrick aus die Niederlande
Moin, Irgendwann bringts mehr, auch mal wirklich selber was zu programmieren als das X-te Buch darueber zu lesen. Gruss WK
Das mache ich ja, aber Anregungen aus Fachliteratur können nie schaden und man kann nie genug Fachbücher haben, sag ich mal. Bisher hatte ich äusserst viel mit BASCOM programmiert, z.B. das hier zum Spiegel-Parabolisieren (für ein Newton Teleskop): https://www.youtube.com/watch?v=yOb71qoFlxA&t=2s Nun versuche ich mich halt in C. Vielleicht komme ich ja auch gut weiter.
Gerhard H. schrieb: > Möchte mal die Frage stellen, welche Bücher zum Erlernen von C für > Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert > wären. Wie wärs mit dem Kernighan Ritchie?
Gerhard H. schrieb: > Das mache ich ja, aber Anregungen aus Fachliteratur können nie schaden > und man kann nie genug Fachbücher haben, sag ich mal. In dem Themengebiet hat man lieber ein einziges gutes Buch, als viele schlechte, und lieber gar keins, als auch nur ein schlechtes. Oliver
Moin, Harald W. schrieb: > Gerhard H. schrieb: > >> Möchte mal die Frage stellen, welche Bücher zum Erlernen von C für >> Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert >> wären. > > Wie wärs mit dem Kernighan Ritchie? Ja, den haette ich auch schon fast vorgeschlagen, aber der ist halt imho eher fuer C unter unixoiden OS geschrieben, weniger fuer embedded Geruempel. Und ich hab' den nochdazu damals in einer deutschen Uebersetzung gekauft, wo's mir im Nachhinein noch die Schuhe auszieht, wie scheisse man so ein Standardwerk uebersetzen kann. WTF soll denn ein Binder sein oder ein Uebersetzer? Hoffentlich ist das derweilen besser geworden. Gruss WK
[qote]In dem Themengebiet hat man lieber ein einziges gutes Buch, als viele schlechte, und lieber gar keins, als auch nur ein schlechtes.[/quote] Ja, ganz richtig! Das ist auch mein Gedankengang, weshalb ich auch die Frage gestellt habe. So gesehen ist wahrscheinlich das Buch von Heimo Gaicher fast ideal, vermute ich. Mir fehlen halt auch die Ideen für brauchbare Anwendungen. Derzeit wäre meine einzige Idee eine Verschlusszeitmessung für analoge Kameras, weil ich mich viel mit analoger Photographie und Schmalfilm beschäftige (arbeite auch selbst alles aus.) Möglicherweise wäre eine vorläufige Rückkehr zu Arduino sogar der beste Weg, um voranzukommen, ich weiss es nicht. Mit BASCOM möchte ich nicht mehr arbeiten.
Moin, Gerhard H. schrieb: > Mir fehlen halt auch die Ideen für brauchbare Anwendungen. OK, da werden wohl auch kaum Buecher ueber Programmiersprachen helfen. Das ist sowas von dem Kaliber: Habe Loesung (C), suche Problem... Das Problem hatten hier iirc Leute schon oefter; vielleicht hilft die Suchfunktion. Gruss WK
Vergiss C, lerne C++. Gerade dann, wenn Du noch kein C kannst. Dieser Ratschlag hat überhaupt gar nichts mit OOP zu tun. Denn C++ ist eine Multiparadigmen-Sprache. Du kannst also genauso gut bzw. besser in C++ prozedural/imperativ programmieren wie in C. Jedoch sind es die kleinen "Goodies", die Dir sehr viel helfen können. Also Buch: "Der C++-Programmierer", U. Breymann
Beitrag #7336317 wurde von einem Moderator gelöscht.
Dergute W. schrieb: >> Wie wärs mit dem Kernighan Ritchie? > > Ja, den haette ich auch schon fast vorgeschlagen, aber der ist halt imho > eher fuer C unter unixoiden OS geschrieben, weniger fuer embedded > Geruempel. > Und ich hab' den nochdazu damals in einer deutschen Uebersetzung > gekauft, wo's mir im Nachhinein noch die Schuhe auszieht, wie scheisse > man so ein Standardwerk uebersetzen kann. WTF soll denn ein Binder sein > oder ein Uebersetzer? Ich würde immer das Standardwerk empfehlen, idealerweise im englischen Original. Anschliessend den Stroustroup für C++, aber erst nach etwas Praxis in C. Ein spezifisches embedded-Buch halte ich für pädagogisch verkehrt. C ist schon sehr hardwarenah, und es ist wichtiger, sich erstmal mit der C-Denkweise und den Datenstrukturen (und den Einschränkungen von C z.B. bei mehrdimensionalen Arrays) vertraut zu machen. Was man dann noch braucht, um C embedded einzusetzen, kann man auch leicht im Netz finden. Brian
Ich denke, man kann die Sprache C (oder C++) besser auf einem PC lernen. Dafür gibt es auch viel mehr Bücher und kostenlose Tutorials. Die Speziellen Feinheiten bezüglich Mikrocontroller habe ich nach und nach heraus gefunden. Die Doku der avr-libc war dabei besonders hilfreich, wie auch Ratschläge dieses Forums.
Brian Ritchie schrieb: > Ich würde immer das Standardwerk empfehlen, idealerweise im englischen > Original. Anschliessend den Stroustroup für C++, aber erst nach etwas > Praxis in C. > Ein spezifisches embedded-Buch halte ich für pädagogisch verkehrt. C ist > schon sehr hardwarenah, und es ist wichtiger, sich erstmal mit der > C-Denkweise und den Datenstrukturen (und den Einschränkungen von C z.B. > bei mehrdimensionalen Arrays) vertraut zu machen. Was man dann noch > braucht, um C embedded einzusetzen, kann man auch leicht im Netz finden. > > Brian K&R unbedingt (!) im Original. Ich hatte mal eine Übersetzung ins Deutsche - und hab sie umgehend entsorgt. Ich weis schon, man wirft keine Bücher weg und verbrennt sie auch nicht, aber in diesem Fall sowie beim Siemens-Datenbuch SAB8080 musste ich einfach eine Ausnahme machen. Sicher findet sich "The C programming Language" auch irgendwo in den Tiefen des russischen Webs. Tu dir trotzdem den Gefallen und besorg dir eine gedruckte Ausgabe - und dazu eine Anstaltspackung Post-it (R). Also ein volles AGREE für Brian! PS: Posit-it - das sind die meist gelben Zettelchen, die man NICHT an DuRöhre-Filmchen rankleben kann...
PS: Ich würde Dir zur "Second Edition of The C Programming Language" raten - und dort auch ruhig mal das Preface lesen, um sich - wie es Brian formuliert hat "erstmal mit der C-Denkweise [...] vertraut zu machen". Eine "3rd Edition" kenn ich nicht - und will auch nicht wissen, wer daninter steht ... just my 2ct
C ist schnell erlernt. Nimm ein Online Buch und schaue Code anderer an.
Wilhelm M. schrieb: > Vergiss C, lerne C++. > Gerade dann, wenn Du noch kein C kannst. Im Alter von 74, wo es nur um bissel Spaß im Hobby geht? Naja . . .
Harald W. schrieb: > Wie wärs mit dem Kernighan Ritchie? Den fand ich damals (zusammen mit den Lösungen) sehr gut!
Warum nicht Pascal von mikroe? Ansonsten C von A-Z. Wen Du hier fragst ist jedes Buch kacke außer das vom Richie:-) Aber das ist totaler Quatsch, und ja in JEDEM Buch finden die irgendwas, was falsch ist.. Scheiß drauf Hauptsache 98% sind super erklärt https://www.amazon.de/dp/3836239736/?coliid=I7C426UQ0028N&colid=1EY8PXVV38K6C&psc=1&ref_=lv_ov_lig_dp_it_im
Falk B. schrieb: > Wilhelm M. schrieb: >> Vergiss C, lerne C++. >> Gerade dann, wenn Du noch kein C kannst. > > Im Alter von 74, wo es nur um bissel Spaß im Hobby geht? Naja . . . Ja sicher. Und er hat noch Zeit den Stepanov zu lesen ;-)
AVR Mikrocontroller - Programmierung in C: Eigene Projekte selbst entwickeln und verstehen Taschenbuch – 8. Januar 2016 habe ich gerade hier, ist auch super
Das von Helmut Erlenkötter finde ich ehrlich gesagt eher durchschnittlich. Ich hatte es mir vor kurzen erst angesehen neben C von A-Z das erheblich ausführlicher ist und besser erklärt
Gerhard H. schrieb: > Bücher zum Erlernen von C für > Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert > wären. So wie ich "nicht ganz blutige Anfänger" interpretiere, würde ich diese empfehlen: https://openbook.rheinwerk-verlag.de/c_von_a_bis_z/ Ist meist recht verständlich geschrieben und man findet recht schnell was man sucht. PS: Ubs.... was solls, einer mehr :)
:
Bearbeitet durch User
Beitrag #7336460 wurde von einem Moderator gelöscht.
Beitrag #7336462 wurde von einem Moderator gelöscht.
Beitrag #7336492 wurde von einem Moderator gelöscht.
Wirklich gute Bücher für Embedded C sind wohl selten. Da kommt man mit Leaning By Doing, Google, Youtube, Blogs usw. weiter, denke ich. Am besten hangelt man sich an einem echten Projekt entlang. Sonst verliert man schnell die Motivation. "Clean Code" kann ich auch empfehlen, da hier einfach universelle Prinzipien gelehrt werden, die fast überall sehr sinnvoll sind. Ansonsten kann man sich für ne schmale Mark den MISRA-C Standard holen. Die Beispiele und "Rationals" sind extrem lehrreich, wenn man schon etwas fortgeschrittener ist. Das Preis-Leistungs-Verhältnis ist hier ausgezeichnet.
[quote]AVR Mikrocontroller - Programmierung in C: Eigene Projekte selbst entwickeln und verstehen Taschenbuch[/quote] Das von Heimo Gaicher? Das finde ich auch super. Würde ich selbst weiterempfehlen. Gerhard
P. S. schrieb: > Ansonsten kann man sich für ne schmale Mark den MISRA-C Standard holen. Ach nee, lieber nicht. MISRA ist gut für Entscheider. Die können dann immer sagen, sie haben sich an den Stand der Technik gehalten. Für Spaß und Hobby darf man gern ordentlich programmieren, aber bei solch sturen Regeln vergeht einem der Spaß manchmal doch recht schnell. @Gerhard: Fang einfach an (hast du ja schon). Die Tutorials hier haben zumindest schon mal den Mikrocontroller-Fokus, da bekommst du dann auch sowas wie die im anderen Thread genannten Bitmanipulationen erläutert, statt dass du dir anfängst, deine Bitmuster als Hex-Zahlen selbst zusammenzuschreiben.
Jörg W. schrieb: > @Gerhard: Fang einfach an (hast du ja schon). Und fange nicht auf einem µC an, C oder C++ oder ... lernen zu wollen. Mache das erstmal auf dem PC. Das geht viel einfacher, und es gibt da auch sehr viele Aufgaben, an den Du Dich versuchen kannst. Neben den ganzen Büchern, die hier empfohlen werden, lege auch immer die Transskription des C/C++- Standards daneben (denn leider gibt es eben auch sehr viele sehr schlechte Bücher, Tutorials, etc.): https://en.cppreference.com/w/ und lese da nach. Denn das ist nun mal die Richtschnur (s.a. die Diskussion um Rückgabetyp und Signatur von main(...) im anderen Thread).
Bücher über die C-Grundlagen würde ich keine kaufen. Die Syntaxregeln von C sind überraschend wenige und schnell zu lernen. Außerdem kann man sie schneller im Internet nachschlagen und auch die Operatoren und deren Rangfolge sowie die Funktionen der Standardlibs. Speziell Für den AVR-GCC findet man auch hier vieles: https://www.nongnu.org/avr-libc/user-manual/index.html Was Anfängern die meisten Probleme bereitet, ist die Herangehensweise an eine Aufgabe, d.h. der Programmierstil. Da gibt es viel falsch zu machen: https://www.tesolva.de/blogpost/quick-and-dirty-oder-doch-lieber-sauber-programmieren Daher gibt es darüber viele Bücher, z.B. "Weniger schlecht programmieren" https://www.amazon.de/Weniger-schlecht-programmieren-Kathrin-Passig/dp/3897215675
Peter D. schrieb: > Bücher über die C-Grundlagen würde ich keine kaufen. Die Syntaxregeln > von C sind überraschend wenige und schnell zu lernen. Außerdem kann man > sie schneller im Internet nachschlagen und auch die Operatoren und deren > Rangfolge sowie die Funktionen der Standardlibs. > Speziell Für den AVR-GCC findet man auch hier vieles: > https://www.nongnu.org/avr-libc/user-manual/index.html > > Was Anfängern die meisten Probleme bereitet, ist die Herangehensweise an > eine Aufgabe, d.h. der Programmierstil. > Da gibt es viel falsch zu machen: > https://www.tesolva.de/blogpost/quick-and-dirty-oder-doch-lieber-sauber-programmieren Wow, meistens bekomme ich hier was auf die Mütze, wenn ich von Clean-Code anfange ;-) Wer mit dem Programmieren angefangen hat, sollte auf jeden Fall den Stepanov "Elements of Programming" lesen.
Beitrag #7336888 wurde von einem Moderator gelöscht.
Wilhelm M. schrieb: > https://www.tesolva.de/blogpost/quick-and-dirty-oder-doch-lieber-sauber-programmieren Bei einem Punkt muss ich aber widersprechen: "Das Programm sollte in kurze Methoden (= Funktionen) aufgeteilt werden, sodass jede Methode möglichst nur eine konkrete Aufgabe erfüllt. Oft wird hier als Richtwert eine Anzahl von 4-6 Zeilen genannt." Die Ermahnung, Funktionen möglichst kurz zu halten ist ja OK, aber 4-6 Zeilen halte ich für völlig unpraktikabel.
Steve van de Grens schrieb: > Ich weiß nicht, wer diese 4-6 Zeilen nennt, aber das halte ich für > völlig unpraktikabel. Theoretiker Im Schnitt, gut das Doppelte, dürfte wohl eher realistisch sein.
Eigentlich genügt es vollkommen, wenn zusammenhängende Codestücke auf eine Bildschirmseite passen. Die ist inzwischen durchaus auch schon mal etwas länger als nur 24 Zeilen wie noch vor ein paar Jahrzehnten. Wichtiger als irgendwelche Dogmas ist, dass man sich in klaren Strukturen ausdrückt. Für das Beispiel von Gerhards Siebensegmentanzeige wäre daher eine Funktion, die jeweils die aktuelle Stelle neu ermittelt und ausgibt, sinnvoll. Die kann er dann aktuell aus main() heraus aufrufen und simpel ein Delay danach nehmen. Wenn er dann mal soweit ist, dass er auch Interrupts versteht, kann er die gleiche Funktion einfach aus dem Timerinterrupt heraus aufrufen.
Teo D. schrieb: > Steve van de Grens schrieb: >> Ich weiß nicht, wer diese 4-6 Zeilen nennt, aber das halte ich für >> völlig unpraktikabel. > > Theoretiker > Im Schnitt, gut das Doppelte, dürfte wohl eher realistisch sein. Statt ein LoC-obergrenze für normale function zu nennen, kann man auch eine Untergrenze für wahrscheinlich zu lange functionen nennen. Und die liegt bei etwa 100 LoC. > welche Bücher zum Erlernen von C für > Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert > wären. ISBN: 978-3897215672 entgegen dem Titel siehen viele Examples nach C aus. Allerdings weniger embedded/Controller als Büro-Informatik.
Steve van de Grens schrieb: > Die Ermahnung, Funktionen möglichst kurz zu halten ist ja OK, aber 4-6 > Zeilen halte ich für völlig unpraktikabel. Och, das kriege ich schon hin, es gibt aber auch Ausreißer, die deutlich länger sind. Allgemein versuche ich, Funktionen logisch aufzuteilen. Hier mal ein Beispiel:
1 | static void wd_reset(void) // force watchdog to reset the CPU |
2 | {
|
3 | cli(); |
4 | wdt_enable(WDTO_15MS); |
5 | while (1); |
6 | }
|
7 | |
8 | void cmd_reset(void) |
9 | {
|
10 | schedule_remove(wd_reset); |
11 | if (!schedule_add_oneshot(wd_reset, TICKS(0.1))) |
12 | wd_reset(); // reset if delayed reset failed |
13 | answer_success(); |
14 | }
|
15 | |
16 | void cmd_eeclear(void) |
17 | {
|
18 | Eepdata.par.crc++; |
19 | eeprom( (uint8_t*)&Eepdata.par.crc, EEPARAM_END - 2, 1, EE_WRITE ); |
20 | cmd_reset(); // reset after 0.1s |
21 | }
|
Geht natürlich nur bei MCs mit echtem Stack im RAM. Kleine PICs mit limitiertem Hardwarestack erlauben das nicht. Da sieht man deshalb oft den berüchtigten Spaghetticode mit vielen fehlerträchtigen Copy&Paste Wiederholungen.
:
Bearbeitet durch User
Jörg W. schrieb: > Wichtiger als irgendwelche Dogmas ist, dass man sich in klaren > Strukturen ausdrückt. Die Tips sollte man nicht als Dogma ansehen, sondern als Empfehlung. Einzelne Abweichungen sind also erlaubt.
Peter D. schrieb: > Kleine PICs mit limitiertem Hardwarestack erlauben das nicht. Wie kommst du auf dieses schmale Brett?! Dass das nicht sooo effizient umgesetzt werden kann, OK aber das man da auf Spaghetti-Code ausweichen muss ist schlicht weg BLÖDSINNI³. Das du die Dinger nicht magst, ist ja OK aber deswegen dummes Zeug verbreiten....
Peter D. schrieb: > Steve van de Grens schrieb: >> Die Ermahnung, Funktionen möglichst kurz zu halten ist ja OK, aber 4-6 >> Zeilen halte ich für völlig unpraktikabel. > > Och, das kriege ich schon hin, es gibt aber auch Ausreißer, die deutlich > länger sind. Ehrlich? Das ist scheiße, eine Funktion dadurch zu kürzen, das man code durch verschachtelte Funktionsaufrufe ersetzt. Einen Functionsaufruf ist IMHO auch kein funktionaler (informationsverarbeitender) Code sondern simple rumspringerei. man könnte auch sagen, da wird garnichts gemacht, da dreht sich nur der Programmcounter im kreise ;-)
Jodes Kind coded schrieb: > man könnte auch sagen, da wird garnichts gemacht, da dreht sich nur der > Programmcounter im kreise Nicht zwingend. Wenn der Compiler feststellen kann, dass das alles nur Eintagsfliegen sind, dann bleibt der erzeugte Code weiter schön linear.
Angehängte Dateien:
-
PimmelStack.PNG
51 KB
Teo D. schrieb: > Peter D. schrieb: >> Kleine PICs mit limitiertem Hardwarestack erlauben das nicht. > > Wie kommst du auf dieses schmale Brett?! > Dass das nicht sooo effizient umgesetzt werden kann, OK aber das man da > auf Spaghetti-Code ausweichen muss ist schlicht weg BLÖDSINNI³. > Das du die Dinger nicht magst, ist ja OK aber deswegen dummes Zeug > verbreiten.... was ist daran dumm? Es gibt nun mal Controller, die können Unterprogrammaufrufe nur in wenigen Ebenen verschachteln (Bsp im Anhang AVR AT90S1200 -> 3 Ebenen) und da sollte man nicht vom unterprogramm ins unter-unterprogramm verzweigen.
Jodes Kind coded schrieb: > ...sondern simple rumspringerei... Funktionen wahllos klein zu machen halte ich auch für kontraproduktiv, aber wenn es sich aus Lesbarkeitsgründen anbietet ist ein Auslagern in eine extra Funktion sehr hilfreich. Mit einem "static inline" vor der Funktion gibt es dann auch kein Sprung oder andere Nachteile.
Jörg W. schrieb: > Jodes Kind coded schrieb: >> man könnte auch sagen, da wird garnichts gemacht, da dreht sich nur der >> Programmcounter im kreise > > Nicht zwingend. Wenn der Compiler feststellen kann, dass das alles nur > Eintagsfliegen sind, dann bleibt der erzeugte Code weiter schön linear. Du meinst "Inlining"?! Darauf würde ich mich aber nicht verlassen. Und dann schaut der (C-)Code auch nicht sonderlich consitent aus. Im Code ist es (langsamer9 Unterprogrammaufruf, im Compilat dagegen flottes inlining (wenn die Compileroptionen entsprechend stehen).
Jedes Kind coded schrieb: > da sollte man nicht vom unterprogramm ins > unter-unterprogramm verzweigen. Das ist was ganz anderes, als geht nicht..... Hier gehts doch um C und nicht um Assembler....
Stefan A. schrieb: > Mit einem "static inline" vor der Funktion gibt es dann auch kein Sprung > oder andere Nachteile. "static" genügt (bzw. hilft stark – bei LTO wäre nichtmal das nötig). "inline" ist nur ein Hinweis an den Compiler, kann er ignorieren. Andererseits kann er problemlos auch ohne "inline" die Funktionen inline erweitern.
Stefan A. schrieb: > odes Kind coded schrieb: >> ...sondern simple rumspringerei... > > Funktionen wahllos klein zu machen halte ich auch für kontraproduktiv, > aber wenn es sich aus Lesbarkeitsgründen anbietet ist ein Auslagern in > eine extra Funktion sehr hilfreich. Gerade Lesbarkeistgründe sprechen IMHO gegen das Auslagern von Code-schnipseln/-fragmenten in extra Funktionen. >Funktionen wahllos klein zu machen halte ich auch für kontraproduktiv, Ich würde das nicht als "wahllos" beschreiben, sondern als "zwanghaft minimal" oder konkret 4-6 Zeilen. Das ist dann wirklich schwerer lesbar. Oben, das mit der "Bildschirmseite" (also "ohne scrollen alles im Blick") ist m.E. die beste Regel für die Länge einer Function .. obwohl es sicher auch "Spezies" gibt, die einen 1920-Bildschirm Hochkant aufstellen und den Font-size auf 8 stellen um 240 Zielen untereinander zu klatschen ;-)
Teo D. schrieb: > Jedes Kind coded schrieb: >> da sollte man nicht vom unterprogramm ins >> unter-unterprogramm verzweigen. > > Das ist was ganz anderes, als geht nicht..... Hier gehts doch um C und > nicht um Assembler.... Nö, das ist genau das selbe. Wenn ein Controller eben nur einen call-stack von 3 ebenen hat, dann hat er nur 3 ebenene, egal ob in C, assembler oder "HeisserScheiß" programmiert.
Beitrag #7337041 wurde von einem Moderator gelöscht.
Jodes Kind coded schrieb: > Ehrlich? Das ist scheiße, eine Funktion dadurch zu kürzen, das man code > durch verschachtelte Funktionsaufrufe ersetzt. Hab ich auch nie behauptet. Eine Unterfunktion wird entweder an mehreren Stellen benötigt oder führt eine klar abgegrenzte Aufgabe aus. Nur aus Jux und Dollerei unterteile ich nichts. Es muß schon der Lesbarkeit dienen. Nur einmal aufgerufene Funktionen werden eh vom Compiler inlined, d.h. verbrauchen keinen Stack.
Gerhard H. schrieb: > Gibt es von euch ein paar Etzes für andere Bücher? > (Grundlagen-Kenntnisse vorhanden) Also so grundlegend muss man immer darauf hinweisen: Lernen durch Übung, üben üben üben, Übung macht den Meister. - K+R, auch wenn die Übersetzung zum Schmunzeln animiert, der Code eher nicht. - Erlenkötter C, angenehm didaktischer Aufbau, man kann auch lernen, wie man eine Game-Engine schreibt. Diesbezüglich bräuchte man aber auch nicht zu knapp Mathe in Richtung Lineare Algebra. Statistik kann auch nicht schaden, oder Assembler. - Sedgewick, Algorithmen in C Ja, man könnte mal versuchen, Verschachtelungen, oder Verschattung auf der Assemblerebene hinzubekommen. Man wird mehrere Wege finden, und sich vermutlich auch für Disassemblies interessieren. oder: wer kann der kann: https://crypto.stanford.edu/~blynn/c/craft.html oder: man muss (darüberhinaus) schon wollen: https://bellard.org/tcc/
Beitrag #7337052 wurde von einem Moderator gelöscht.
Beitrag #7337075 wurde vom Autor gelöscht.
Teo D. schrieb: >> Ich weiß nicht, wer diese 4-6 Zeilen nennt, aber das halte ich für >> völlig unpraktikabel. > > Theoretiker > Im Schnitt, gut das Doppelte, dürfte wohl eher realistisch sein. Nicht mal das! 12 Zeilen für eine Funktion? Da hab ich ja gerade mal den Kopf geschrieben, die lokalen Variablen deklariert und das return geschrieben. Vollkommen weltfremd. Meine Funktionen sind irgendwas zwischen 5-1000 Zeilen.
Jedes Kind coded schrieb: > Teo D. schrieb: >> Jedes Kind coded schrieb: >>> da sollte man nicht vom unterprogramm ins >>> unter-unterprogramm verzweigen. >> >> Das ist was ganz anderes, als geht nicht..... Hier gehts doch um C und >> nicht um Assembler.... > > Nö, das ist genau das selbe. Wenn ein Controller eben nur einen > call-stack von 3 ebenen hat, dann hat er nur 3 ebenene, egal ob in C, > assembler oder "HeisserScheiß" programmiert. Hab ich irgendwo behautet, das sich der HW-Stack auf wundersame weise vermehrt?! :DDD
Falk B. schrieb: > 12 Zeilen für eine Funktion? Da hab ich ja gerade mal den > Kopf geschrieben, die lokalen Variablen deklariert und das return > geschrieben. Schon klar, nur der Kopf gehört für mich nicht dazu und da dürfte ich wohl nicht der Einzige sein. ;)
Hallo Gerhard H., mein Rat (als Rentner) an Dich ist auch das, was Peter D. In diesem Thread vorgeschlagen hat: Peter D. schrieb: > Bücher über die C-Grundlagen würde ich keine kaufen. Die Syntaxregeln > von C sind überraschend wenige und schnell zu lernen. Außerdem kann man > sie schneller im Internet nachschlagen und auch die Operatoren und deren > Rangfolge sowie die Funktionen der Standardlibs. > Speziell Für den AVR-GCC findet man auch hier vieles: > https://www.nongnu.org/avr-libc/user-manual/index.html > > Was Anfängern die meisten Probleme bereitet, ist die Herangehensweise an > eine Aufgabe, d.h. der Programmierstil. Fang einfach an. Nimm ein funktionierendes Code- Beispiel für Deinen Controller aus dem Forum und verändere und erweitere es für Deine Wünsche, Stück für Stück. Sind die Regeln oder die Syntax unklar, hilft ein Buch zum !Nachschlagen! oder das Internet. Peter D. hat auch einen wunderbar funktionierenden UART-Code geschrieben (findest Du im Forum), mit dem sich einfache Debug-Ausgaben und auch umfangreiche Ein- und sonstige Ausgaben (in ein Terminal-Programm auf den PC) machen lassen. Von ihm gibt es auch ein sehr gutes Code-Beispiel für Taster und Encoder-Eingaben. Kannst Du verwenden, musst Du aber nicht. Wenn Du schon soviel, wie beschrieben, auf die Beine gestellt hast, dann ist Lernen per Anleitung eines Buches verschwendete Zeit und bringt Dich nur minimal weiter. Blackbird
Angehängte Dateien:
Steve van de Grens schrieb: > "Das Programm sollte in kurze Methoden (= Funktionen) aufgeteilt werden, > sodass jede Methode möglichst nur eine konkrete Aufgabe erfüllt. Oft > wird hier als Richtwert eine Anzahl von 4-6 Zeilen genannt." > > Die Ermahnung, Funktionen möglichst kurz zu halten ist ja OK, aber 4-6 > Zeilen halte ich für völlig unpraktikabel. Richtig, bei 4-6 Zeilen pro Funktion sollte man in Forth mit refactoring starten bis man bei einer Zeile pro Funktion angekommen ist :-) Over the Shoulder 1 - Text Preprocessing in Forth, Samuel Falvo II, Andreas Wagner https://www.youtube.com/watch?v=mvrE2ZGe-rs
IMHO sollte heutzutage ein C-Buch mindestens den C99-Standard abdecken, weswegen der K&R leider etwas überholt ist. Von den neueren Büchern gefallen mir die beiden folgenden ganz gut: K. N. King, C Programming – A Modern Approach - C99 - Enthält auch ein kleines Kapitel über hardwarenahes Programmieren (Bitgepopel, Zugriff auf Hardwareregister) - Beschreibt auch recht ausführlich die Aufteilung großer Programme in separate Übersetzungseinheiten (Modularisierung) - Stil: Eher Lehrbuch - http://knking.com/books/c2/index.html Peter Prinz, Tony Crawfordm, C in a Nutshell, 2nd Edition - C11 - Kleine Einführung in GCC und Make - Stil: Eher Referenzhandbuch - https://www.oreilly.com/library/view/c-in-a/9781491924174/
:
Bearbeitet durch Moderator
Hier ist noch ein Buch: https://www-personal.acfr.usyd.edu.au/tbailey/ctext/ctext.pdf "An Introduction to the C Programming Language and Software Design" Von Tim Bailey
Gerhard O. schrieb: > Hier ist noch ein Buch: ... und hier noch eines: Notes on Data Structures and Programming Techniques by James Aspnes http://cs.yale.edu/homes/aspnes/classes/223/notes.html
Alexander S. schrieb: > Gerhard O. schrieb: >> Hier ist noch ein Buch: > > ... und hier noch eines: > > Notes on Data Structures and Programming Techniques by James Aspnes > > http://cs.yale.edu/homes/aspnes/classes/223/notes.html Besonders gut ist: "7.1 What’s wrong with C". Wobei hier der erste genannte Punkt, dass C keine Garbage-Collection hat, der am wenigsten wichtigste ist.
Teo D. schrieb: > Falk B. schrieb: >> 12 Zeilen für eine Funktion? Da hab ich ja gerade mal den >> Kopf geschrieben, die lokalen Variablen deklariert und das return >> geschrieben. > > Schon klar, nur der Kopf gehört für mich nicht dazu und da dürfte ich > wohl nicht der Einzige sein. ;) 12 Zeilen für die Signatur? Und warum definierst Du alle lokalen Variablen am Anfang einer Funktion. Das ist doch Blödsinn. Zeig doch mal ein Beispiel von so einem Monster.
Gerhard H. schrieb: > Ich habe mir AVR-Mikrocontroller Programmierung in C von Heimo Gaicher > und Micro-Controller Technik mit AVR , Programmierung in Assembler und > C von Günter Schmitt und Andreas Riedenauer zugelegt, Daneben gibt es auch noch das Buch AVR - Mikrocontroller von Ingo Klöckl. https://www.degruyter.com/document/doi/10.1515/9783110407693/html Darin wird die Hardware und die Software beschrieben. Der Fokus liegt weniger auf dem Erlernen von C, es gibt aber reichlich Beispiele. Das wurde, glaube ich, noch nicht genannt.
Wilhelm M. schrieb: > Wobei hier der erste genannte Punkt, dass C keine Garbage-Collection > hat, der am wenigsten wichtigste ist. Es ist halt ein fundamentaler Unterschied, den man wissen muss wenn man damit arbeitet. Aber nicht unbedingt schlecht. Garbage Kollektoren habe ihre eigenen Tücken, die man früher oder später schmerzlich kennen lernt, wenn man nicht drauf vorbereitet ist.
Ich habe ein hervorragendes Lehrbuch entdeckt: "Mikrocontroller programmieren lernen. Einführung in die Programmierung von Mikrocontrollern-Vom Programmiergerät bis zu fertigen Projekten" von Holger Weiß. Verwendet wird der ATMega328. Ideal für Anfänger. Endlich mal etwas, das wirklich was taugt. Empfehlenswert!
Stefan F. schrieb: > Es ist halt ein fundamentaler Unterschied, den man wissen muss wenn man > damit arbeitet. Aber nicht unbedingt schlecht. Man kann ja auch erlernen seinen Müll mal selbst weg zu räumen.
Ein allgemein gehaltenes Buch über C auf Mikrocontrollern kann es meiner Meinung nach gar nicht geben. Denn diese Programmiersprache war eigentlich für (mindestens) 16 Bit Computer mit Betriebssystem gemacht. Deswegen hat in C der normale Integer 16 Bit. Einzelne Bits gibt es in C eigentlich nicht. Interrupthandler und das Ansprechen von Registern war dem Betriebssystem vorbehalten, welches an diesen Stellen vorwiegend in Assembler programmiert wurde. Auf Mikrocontrollern braucht man das alles aber, und zwar vorzugsweise direkt in C ohne Assembler Code einbetten zu müssen. Jeder C Compiler wurde daher abweichend vom Standard C speziell für den jeweiligen Mikrocontroller Typ angepasst und bringt entsprechend spezifische Erweiterungen/Eigenheiten mit sich. Wenn man das lernen will, muss man mit einem konkreten Mikrocontroller-Typ anfangen. Die klassischen AVR eignen sich dazu sehr gut, wie ich meine.
Steve van de Grens schrieb: > Ansprechen von Registern war dem Betriebssystem vorbehalten, welches an > diesen Stellen vorwiegend in Assembler programmiert wurde. C war von vornherein dafür gedacht, möglichst große Teile des Betriebssystems damit implementieren zu können. https://www.bell-labs.com/usr/dmr/www/cacm.html "The preponderance of Unix software is written in the abovementioned C language [7]. Early versions of the operating system were written in assembly language, but during the summer of 1973, it was rewritten in C."
Steve van de Grens schrieb: > Interrupthandler und das Ansprechen von Registern war dem Betriebssystem > vorbehalten, welches an diesen Stellen vorwiegend in Assembler > programmiert wurde. Im Gegenteil: Du solltest https://www.amazon.de/Lions-Commentary-Computer-Classics-Revisited/dp/1573980137/ref=mp_s_a_1_1?adgrpid=69429517417&gclid=Cj0KCQiA54KfBhCKARIsAJzSrdqFogTRdvvEi3b_uSv_eB-FrOMB-khoNvMYSbNUDyzWv0Mo-Qh-G-caAvcHEALw_wcB&hvadid=606880222937&hvdev=m&hvlocphy=9041805&hvnetw=g&hvqmt=e&hvrand=4042124887765880146&hvtargid=kwd-298623509747&hydadcr=12219_2388108&keywords=lions+commentary+on+unix&qid=1675671388&sr=8-1 lesen.
Wilhelm M. schrieb: ... > > Im Gegenteil: Du solltest > > ... > > lesen. Danke für den Link. "A commentary on the Sixth Edition UNIX Operating System, with Source Code" gibt es im Internet, u.a. bei archive.org https://archive.org/details/CommentarySixthEditionUNIX/6thEdLions/mode/2up Links oben ist auch der Link auf den Source Code (pdf). Die 6th ed. war für eine PDP-11/40. Unter dem Namen xv6 gibt es eine moderne Implementierung für x86 und RISC-V: "xv6 is a modern reimplementation of Sixth Edition Unix in ANSI C for multiprocessor x86 and RISC-V systems. It was created for pedagogical purposes in MIT's Operating System Engineering course in 2006." https://en.wikipedia.org/wiki/Xv6
Also mir hat sehr geholfen vorher erst mal einen angenehmen Assembler (AVR-Risc) gut zu können. Daraus habe ich folgende wichtige Punkte erlernt: 1. Was der Computer eigentlich macht: C hat keine Abstraktionsebenen die Dich vor der Maschine retten. Arrays sind beispielsweise nur Pointer bei denen ein "Multiplikationsfakor für den Index" im Compiler verwaltet wird. Was daraus folgt wird klar, wenn man schon mal Assembler programmiert hat. 2. Dinge die man in C nicht machen sollte tun in Assembler richtig weh: Beispielsweise verschachtelte if-Abfragen. So was tut in Assembler einfach weh. C selbst ist dann relativ schnell erlernt. Wenn man von der Assemblerseite her kommt sieht man das schnell als Assembler mit jeder Menge Komfortfunktionen an. Dann kommt die Phase in der man dann den Umgang mit diesen angenehmen Funktionen kennen lernen sollte. Es mag vielleicht erst mal absurd klingen, aber dort kann man von anderen Sprachen lernen. Es gibt da ein Erlang-Buch, das mir geholfen hat deutlich lesbareren C-Code zu schreiben. "The Art of UNIX Programming" ist ein Standardwerk für die praktische Gestaltung von Programmen. Das ist zwar eigentlich auf UNIX-Systeme ausgelegt, man kann daraus aber auch viel für Embedded-Systeme lernen. (z.Bsp. dass es sehr häufig sinnvoll ist Textformate zu verwenden) Dann muss man wissen, was Compiler heute können. Da hilft es wenn man sich den Assemblercode ausgeben lässt, den der Compiler erstellt. Standardfunktionen sind heute zum Beispiel "Tail-Recursion", was unter speziellen Bedingungen rekursive Funktionsaufrufe in Schleifen umwandelt. Dadurch kann man, ohne Probleme mit dem Stack, Rekursion anstelle von Schleifen verwenden, was unter bestimmten Bedingungen den Code sehr viel lesbarer machen kann. Wichtig ist auch immer: Du programmierst nicht für den Compiler, Du programmierst für den der nach Dir den Code lesen muss. Je simpler Dein Code ist, je weniger unnötige Sprachelemente Du benutzt, um so leichter tut sich der Nächste. Das typische Negativbeispiel ist das typische "Hello World" in C++ mit Streams, bei Dem Du erst mal einige Wochen C++ lernen musst um es lesen zu können.
Christian B. schrieb: > Wichtig ist auch immer: Du programmierst nicht für den Compiler, Du > programmierst für den der nach Dir den Code lesen muss. Das ist man meistens selber;-)
M. K. schrieb: > Gerhard O. schrieb: >> Das ist man meistens selber;-) > > Gilt nur für die ersten Tage ;) :D Gilt besonders, wenn der Kunde Eweiterungen möchte und man sich nach einem Jahr wieder reinfitzen muß. Da zahlt es sich dann aus, wenn man nicht schnell mal eben den grausamsten C&P Spaghetticode runtergerotzt hat, sondern schon eine Struktur reingebracht hat.
Peter D. schrieb: > M. K. schrieb: >> Gerhard O. schrieb: >>> Das ist man meistens selber;-) >> >> Gilt nur für die ersten Tage ;) :D > > Gilt besonders, wenn der Kunde Eweiterungen möchte und man sich nach > einem Jahr wieder reinfitzen muß. > Da zahlt es sich dann aus, wenn man nicht schnell mal eben den > grausamsten C&P Spaghetticode runtergerotzt hat, sondern schon eine > Struktur reingebracht hat.
Gerhard O. schrieb: > Das ist man meistens selber;-) Richtig, deshalb ist es wichtig, dass selbst der dümmste Mensch den man sich vorstellen kann, den Code noch verstehen kann... denn das ist man meistens selber. :) Ich persönlich tendiere dazu, "schwierige" Konstrukte weg zu lassen, wenn sie nicht benötigt werden. Ein Beispiel ist die destruktive Zuweisung auf Variablen. In C kann man folgendes machen: int i=15; //Deklaration von Ganzzahlvariable i mit dem Wert 15 i++; //destruktives Überschreiben des Wertes von i mit 16 Besser, aber noch nicht gut ist da: i=i+1; Wobei man häufig sogar ganz darauf verzichten kann, wenn man sein Programm sinnvoll strukturiert. Was ich aus Erlang gelernt habe ist, dass man Eingabevariablen auch gleich am Anfang testen kann, also nicht: void irgendwas(char *s) { if (s!=NULL) { ... } } sondern: void irgendwas(char *s) { if (s==NULL) return; ...
Christian B. schrieb: > sondern: > void irgendwas(char *s) > { > if (s==NULL) return; > ... Dann solltest du nie mit MISRA in Berührung kommen, denn die sind der Meinung, dass eine Funktion nur einen einzigen Ausgang haben darf. Dass das dann zu undurchsichtigem if/else-Spaghetti führt, scheint sie nicht weiter zu berühren …
Jörg W. schrieb: > Christian B. schrieb: >> sondern: >> void irgendwas(char *s) >> { >> if (s==NULL) return; >> ... > > Dann solltest du nie mit MISRA in Berührung kommen, denn die sind der > Meinung, dass eine Funktion nur einen einzigen Ausgang haben darf. > > Dass das dann zu undurchsichtigem if/else-Spaghetti führt, scheint sie > nicht weiter zu berühren … Den MISRA-Standard (£15!) kann man sich alleine deswegen schon ins Regal stellen, damit man nicht den getriggerten KMU-Bastlern, die noch nie in ihrem Leben sicherheits- oder missionskritische Firmware geschrieben haben, geschweige denn mit IEC 61508 oder ISO 26262 in Berührung gekommen sind, glauben schenken muss. Dann wüsste man z. B. auch, dass die "single point of exit"-Regel lediglich "Advisory" ist. Diese Regel also nur eine "Recommendation" darstellt, die man nur "as far as reasonable practical" befolgen sollte.
:
Bearbeitet durch User
P. S. schrieb: > Dann wüsste man z. B. auch, dass die "single point of exit"-Regel > lediglich "Advisory" ist. Das hilft dir nichts, wenn dir die innerbetriebliche Bürokratie dann vorschreibt, dass du jegliche Abweichung davon in irgendeinem umständlichen Prozess dokumentieren musst. Weil darauf keiner Bock hat, wird dann doch lieber wieder Spaghetticode mit viel if / else geschrieben, denn darüber beschwert sich keiner der MISRA-Checker. Dass man den Mist hinterher gar nicht mehr lesen kann, bewertet kein maschineller Test, und MISRA schreibt auch nirgends, dass lesbarer Code einem stur die Regeln befolgenden Code zu bevorzugen wäre.
Guido Krüger, Programmieren in C OReilly - Mastering Algorithms in C Spinellis - Code Reading Ted Faison - Taking Events to the Limit Danach je nach Laune entweder mein Buch zu MCUs und/oder OReilly - AI for Game Developers und OReilly - Physics for Game Developers Alle antiquarisch gut erhaeltlich zuB bei Alibris
Jörg W. schrieb: > Dann solltest du nie mit MISRA in Berührung kommen, denn die sind der > Meinung, dass eine Funktion nur einen einzigen Ausgang haben darf. Ja, das ist so wie eine "ISO-Zertifizierung" in einem Unternehmen. Das dient primär als Zeichen dafür, dass man in so ein Unternehmen nicht gehen will. Solche Regelwerke bringen in der Regel nur "Boxticking" ohne echte Sicherheitsvorteile.
Christian B. schrieb: > Das dient primär als Zeichen dafür, dass man in so ein Unternehmen nicht > gehen will. Würde ich so nicht sagen. ISO900x besagt ja nur, dass du definierte (und dokumentierte) Prozesse haben musst. Das ist nicht per se schlecht, es ist nur initial etwas Aufwand, die Prozesse zu etablieren (ich habe das mal mehr beobachtend in einer eher kleinen Firma miterlebt). Meine Kurzzusammenfassung davon war immer: Wenn bei einem solchermaßen bestätigten Prozess einmal Schei*** rauskommt, muss der Prozess garantieren, dass immer die gleiche Schei*** rauskommt.
Christian B. schrieb: > Ja, das ist so wie eine "ISO-Zertifizierung" in einem Unternehmen. Das > dient primär als Zeichen dafür, dass man in so ein Unternehmen nicht > gehen will. Das ist nicht immer ihre Schuld. Unsere Kunden bestehen auf ISO Zertifikation und das ist eben so. Wenn man ISO Prinzipien intelligent befolgt, bringt es durchaus Vorteile, und dass man sich z.B. darauf verlassen kann, dass die Messgeräte kalibriert sind und nützliche Regeln konsistent befolgt werden. Es muss nicht unbedingt schlecht sein. Die Einhaltung der selbst aufgestellten ISO Prozeduren gibt keine Garantie für Qualität. ISO-Regeln machen sie nur konsistent. Abgesehen davon wird das jedes Jahr geprüft. Was mich betrifft, finde ich es durchaus ein gutes Konzept, solange es intelligent aufgestellt wurde und die Kollegen halten sich daran. Nachtrag: Ich stimme Joerg zu.
:
Bearbeitet durch User
Also so für das Hobby, ohne jetzt der Pro werden zu wollen,fand ich nach nen paar Jahren Autodidakt das Buch "c++ programmieren: c++ lernen" schonmal nicht schlecht. Das hat mir dann ohne langweilig zu werden noch einige Tips und Kniffe gezeigt. Man kann sich natürlich auch direkt nen Wälzer empfohlen von den professionellen Informatikern reinziehen, aber das war mir für meine Ziele etwas too much.
Tam H. schrieb: > Alle antiquarisch gut erhaeltlich zuB bei Alibris und in der Library Genesis http://libgen.rs/
P. S. schrieb: > Dann wüsste man z. B. auch, dass die "single point of exit"-Regel > lediglich "Advisory" ist. Diese Regel also nur eine "Recommendation" > darstellt, die man nur "as far as reasonable practical" befolgen sollte. Klingt sinnvoll. In der Regel bemühe ich mich darum, dass Funktionen nur ein erfolgreiches Ende haben (und zwar ganz unten). Aber im Fehlerfall dürfen sie auch früher aussteigen.
Jörg W. schrieb: > Meine Kurzzusammenfassung davon war immer: Wenn bei einem solchermaßen > bestätigten Prozess einmal Schei*** rauskommt, muss der Prozess > garantieren, dass immer die gleiche Schei*** rauskommt. Und dann kommt noch irgend ein Berater, und lässt den Prozess in Software giessen. Damit die gleiche Schxxx sehr viel schneller rauskommt. Oliver
Gerhard O. schrieb: > Unsere Kunden bestehen auf ISO Zertifikation und das ist eben so. Unsere auch. Deswegen kann ich doch nicht einfach das Handtuch werfen.
Jörg W. schrieb: > Dann solltest du nie mit MISRA in Berührung kommen, denn die sind der > Meinung, dass eine Funktion nur einen einzigen Ausgang haben darf. Man könnte MISRA ja austricksen:
1 | do
|
2 | {
|
3 | if ( Errorcase0 ) |
4 | break; |
5 | do_something0(); |
6 | if ( Errorcase1 ) |
7 | break; |
8 | do_something1(); |
9 | if ( Errorcase2 ) |
10 | break; |
11 | do_something2(); |
12 | if ( Errorcase3 ) |
13 | break; |
14 | do_something3(); |
15 | }
|
16 | while( 0 ); |
Statt break geht auch continue, z.B. wenn man per switch abbrechen will.
Peter D. schrieb: > Man könnte MISRA ja austricksen: > ... Auch von mehrfachen Breaks in Schleifenkonstrukten wird in MISRA abgeraten :) Mehrfache Returns, mehrfache Breaks und auch Gotos werden in MISRA alle ähnlich bewertet: Man sollte sie vermeiden, sie sind aber nicht verboten. Für die Fehlerbehandlung einer längeren Kette von Aktionen sind oft Gotos zu einem gemeinsamen Ziel ganz praktisch, weil man dann dort noch eine gemeinsame Abschlussaktion unterbringen kann.
Jörg W. schrieb: > ISO900x besagt ja nur, dass du definierte (und dokumentierte) Prozesse > haben musst. Kann bei alten Strukturen in der Firma aber auch auf "Excel Tabellen sind nicht mehr zeitgemäß" und zwingende Umstellung auf ein ERP führen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.