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)
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.
[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.
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.
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.
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.
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.
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 ...
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
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
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.
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.
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.):
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
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
"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.
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.
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.
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
staticvoidwd_reset(void)// force watchdog to reset the CPU
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.
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....
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 ;-)
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 AVRAT90S1200 -> 3 Ebenen) und da sollte man nicht vom unterprogramm ins unter-unterprogramm verzweigen.
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.
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).
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 ;-)
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.
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.
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.
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.
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
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.
"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 :-)
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.
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.
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.
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.
"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.
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.
"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."
Interrupthandler und das Ansprechen von Registern war dem Betriebssystem
vorbehalten, welches an diesen Stellen vorwiegend in Assembler
programmiert wurde.
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:
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.
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.
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.
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.
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;
...
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.
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.
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.
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.
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.
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.
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.
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.
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.
