Hallo, ich suche ein Buch über "C". Doof an allen die ich in den Bibliotheken so finden kann ist, dass sie irgendwie immer auf PC-Programmierung getrimmt sind. Für einen uC brauche ich keine printf()! auch brauche ich wohl kein malloc() und viele andere große Funktionsbibliotheken sind ebenso nicht nutzbar. GIbt es nicht ein C-Buch, dass speziell auf die PRogrammierung von uC eingeht?
Franzis-Verlag, Feldkord: "Einführung in die C-Programmierung mit dem ATMega32" Ich sage nicht, dass es gut ist, aber es ist ein spezialisiertes Buch ...
und wenn man damit bei Amazon zu suchen anfängt, geht es immer weiter mit passenden Titeln und Bewertungen dazu: https://www.amazon.de/AVR-Mikrocontroller-Programmierung-entwickeln-verstehen/dp/3732358542/ref=pd_rhf_cr_s_cp_4?ie=UTF8&dpID=51hUEMyZcsL&dpSrc=sims&preST=_SL500_SR89%2C135_&psc=1&refRID=G1DBTFD5JXG1GEXDFDZ7
C--Programmierer schrieb: > GIbt es nicht ein C-Buch, dass speziell auf die PRogrammierung von uC > eingeht? Was im Speziellen erwartest du denn dann noch? Gut, Bitoperationen sollte man vielleicht mal verstanden haben. Aber ansonsten ist der Wortschatz von C damit schnell ergründet. Der Umgang mit den SFRs und der Peripherie ist ja nun nichts C-Spezifisches. G. Schmitt: Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie. Oldenbourg. Nicht mehr ganz aktuell, aber ganz nett weil immer C und Assembler parallel behandelt werden.
Hallo ich ich vermisse auch so ein Buch. Das immer wieder vorgebrachte Argument der Hardware als weitere Fehlerquelle kann man ja durch eine preiswerte z.B. Arduinohardware (Chinaclone) umgehen. Direkt an oder mittels Praktischen Beispielen und Bauteilen lernen ist meiner Meinung nach viel zielführender zumindest wenn man genau weis was man möchte, also nur µC Programmierung und keine Programme für den PC. Als erstes Hello World Programm eben nicht eine Textausgabe sondern einen Ausgang schalten. Und als großes Endprojekt nicht wieder mal eine Datenbank sondern eine komplette Steuerung bei der auch eine Bibliothek für z.B. ein Display oder Sensor selbst entwickelt wird. Und das ganze noch im engen Zusammenhang mit den Datenblatt und schon wäre das das Buch was immer noch fehlt. Das alles gibt es gut verteilt im Netz schon ansatzweise, aber leider habe ich noch nicht durchgängiges gefunden - entweder wird schon jede Menge vorausgesetzt oder irgendwann "einfach" abgebrochen - wobei es aber auch wirklich sehr aufwendig ist so etws vollständig und für jedermann verständlich darzustellen. Wie es nicht geht (leider) beweist das µC Tutorial dieses Internetauftritts , für den Anfänger unverständlich und für den Fortgeschritten nichts neues. Empfehlenswert ist aber z.B dieses Videotutorial: https://www.youtube.com/watch?v=JMMamSVy1Zs&list=PLAADD7F0253E8AB8C wobei leider her das Problem darin liegt das zu früh aufgehört wurde und in den späteren Videos so einiges nicht detailliert erklärt wurde, während die ersten Videos inhaltlich vorbildlich sind und es "nur" an der technischen Qualität und den Umgebungsgeräuschen mangelt. Und ja: Wieder mal schon recht alt und in Englisch was zumindest bei Themen wo man totaler Anfänger ist das lernen und verstehen erschwert. Aber gerade bei diesen Videotutorial sieht man wie aufwendig und schwer es ist ein gutes und tief gehendes Tutorial, bzw. Buch zu erstellen. Beführworter
Beführworter schrieb: > Das immer wieder vorgebrachte Argument der Hardware als weitere > Fehlerquelle kann man ja durch eine preiswerte z.B. Arduinohardware > (Chinaclone) umgehen. Ugh, gewagte These, es gibt genug China-Müll bei dem zum Beispiel auf sämtliche Kondensatoren rund um den Controller verzichtet wird.
C--Programmierer schrieb: > GIbt es nicht ein C-Buch, dass speziell auf die PRogrammierung von uC > eingeht? Neben dem bereits erwähnten Buch "Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie" von Günter Schmitt, Oldenbourg Verlag, das speziell auf die Programmierung der AVRs eingeht, gibt es noch "Die Programmiersprache C" von Helmut Schellong http://www.schellong.de/c.htm Das Tutorial bzw. Buch geht nicht speziell auf Mikrocontroller ein, enthält aber einiges, was für "hardware-nahe" Programmierung relevant ist.
> Als erstes Hello World Programm eben nicht eine Textausgabe sondern > einen Ausgang schalten. Die intellektuelle Uebertragungsleistung die darin besteht printf("Hello") durch das schreiben eines Bytes in ein Ausgangsregister zu ersetzen ist erheblich geringer als die welche darin besteht erstmal dieses Register zu finden, es korrekt als Ausgang zu initialisieren, eventuell den Takt dazu einzuschalten usw. Wenn man das dann aber auch nicht will/kann, dies also auch vom Buch gezeigt werden soll, dann kommst du aber schnell zu einem Buch das nur mit einem ganz bestimmten Mikrocontroller und nichts anderem mehr funktioniert. Das sind aber dann in der Regler Buecher dir das Fummeln an einem bestimmten Controller, aber nicht das Programmieren beibringen. Oder anders gesagt: Fuer mich hat K&R+Datenblatt gereicht, wieso fuer dich nicht? :-) Es schadet auch nicht malloc zu kennen damit man weiss warum man es nicht verwenden kann. Wenn man dann erstmal die Grundlagen von K&R drauf hat, dann ist danach sicherlich ein spezielleres Buch fuer Microcontroller sinnvoll das einem die Augen fuer bestimmten Strategien und Probleme oeffnet wie man sie nur auf so kleinen Plattformen findet. Olaf
Sollte mal betrachtet werden: https://de.m.wikibooks.org/wiki/Datei:CProgrammierung.pdf Relativ wenig PC-Gedöns
Ich brauche immer printf. Ok, nicht das direkte printf, aber snprintf, um mal formatiere Strings zu erstellen. Diese dann an die serielle Debugschnittstelle, und schon hat man ein paar sinnvolle Hilfsausgaben. Statt malloc verwende ich lieber new und delete. Auch bei kleinen Controllern. Man muss eben wissen, bis zu welchem Grad das sinnvoll und nützlich ist. Was du brauchst ist ein normales C-Buch, und dann das Prozessor-Handbuch. Dazu kommt dann die Erfahrung, wann man was macht, und was besser läßt. Und das kann man eh nicht durch ein Buch lernen. Da muss man durch. Ist wie beim Bäcker, der übt auch ein halbes Jahr, wie man Brötchen richtig knetet.
> Diese dann an die serielle Debugschnittstelle, und schon > hat man ein paar sinnvolle Hilfsausgaben. Ich kannte mal einen, der auf die Art und Weise versucht hat, eine ISR auf einem DSP zu debuggen. Da muss ich heut noch lachen. > Statt malloc verwende ich lieber new und delete. Auch bei kleinen > Controllern. Statt Wasser also Weihwasser. Gibt trotzdem irgendwann Rost im geschmierten Programm.
> Ich kannte mal einen, der auf die Art und Weise versucht hat, > eine ISR auf einem DSP zu debuggen. Und ich kenne einen der hat sich ein eigenes oprintf (fuer olaf) geschrieben das dazu bei vielen Interrupts, wenn auch nicht allen Interrupts in der Lage waere. .-) Allerdings neige ich dazu zum debuggen auch einen Debugger zu verwenden. Olaf p.s: Der Trick besteht darin ein Shadowram zu haben wo alle printf-Ausgaben landen. Dies wird dann gelegentlich von einem niedrig priorisierten IRQ aufs Display geschrieben. Und wenn man gut ist dann kann man sein Display sogar einfach mal ab/an stecken und eine Sekunde spaeter steht wieder alles im Display. Und natuerlich unterteilt man sein Shadowram in Segmente und schreibt nur die mit etwas hoeherer Prioritaet aufs LCD die sich geaendert haben um die Datenrate niedrig zu halten.
König, A: Handbuch PIC24/dsPIC-Mikrocontroller Praxisbeispiele zur Anwendung der Module und Befehle ISBN 978-3-645-65273-5
> Allerdings neige ich dazu zum debuggen auch einen Debugger zu verwenden.
Ja, ich auch.
Meine serielle Debugausgaben mache ich, wo ein Debugger nicht
zur Verfuegung steht, mit einem Soft-UART der ohne Interrupts
und Timer auskommt.
Das geht dann auch in nicht allzu zeitkritischen ISRs ohne Probleme.
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.