Moin zusammen. Ich bin noch ein Anfänger auf dem Gebiet der Cortex M4 (stm32f4) Microcontroller und würde gerne von euch wissen, ob es sich für mich lohnen würde, dieses Buch anzuschaffen. Hat also jemand Erfahrungen mit dem Buch o.ä.? Ich würde mich sehr freuen, wenn ihr mir das sagen könntet. Ps: Programmieren kann ich relativ gut in C, in Assembler habe ich jedoch nie Grundkenntnisse. Bisher sind due einzigen mC, mit denen ich mich beschäftigt habe AVRs. PPS: ISBN 0124080820
St M schrieb: > Ich bin noch ein Anfänger auf dem Gebiet der Cortex M4 (stm32f4) > Microcontroller und würde gerne von euch wissen, ob es sich für mich > lohnen würde, dieses Buch anzuschaffen. Mit etwas Geduld findest du das Vorgänger-Buch (nur M3, ohne M4) als PDF im Internet und kannst dann selber bewerten, ob es für dich geeigent ist. Wenn es deine Erwartungen erfüllt, kannst du es dann immer noch kaufen. Das Buch ist schon relativ ausführlich und gibt einem ein gutes Verständnis für diese Prozessor-Architektur. Allerdings sind die Datenblätter von ARM und von ST auch recht ausführlich, so dass man die meisten notwendigen Informationen auch dort findet. Für Anfänger wäre möglicherweise eher ein Buch geeignet, das speziell für Anfänger geschrieben worden ist. Dieses Buch ist eher für Leute gemacht, die prinzipiell schon Erfahrung mit Mikrocontroller-Programmierung haben und Informationen speziell für diese Architektur benötigen.
St M schrieb: > Ich bin noch ein Anfänger auf dem Gebiet der Cortex M4 (stm32f4) > Microcontroller und würde gerne von euch wissen, ob es sich für mich > lohnen würde, dieses Buch anzuschaffen. Man kann Auto fahren, ohne zu wissen, wie ein Motor funktioniert. Ähnlich ist es auch mit den Cortex M3/M4, die man mit irgendeiner IDE zum Laufen bringt. Das Buch zeigt die Interna des Prozessors, ist sehr informativ und gibt recht kompakt Informationen, die in den Datenblättern eben nicht zu finden sind! Beispiel: 'lazy stacking' bei Interrupts mit FPU Benutzung. Wenn Du mittelfristig auch nur ein bißchen über den Tellerrand schauen möchtest, kann ich es nur empfehlen; auch für einen Anfänger, der keiner bleiben möchte. Dabei muß man nicht alles sofort und jetzt verstehen, aber man kann gezielt nachschlagen, wenn es Probleme gibt. Ich habe mir das Buch besorgt, da A.K. es hier wiederholt empfohlen hat: das war ein sehr guter Tipp!
Als Anfänger kannst du es vergessen, dieses Buch ist eindeutig an den Profi adressiert. Nimm dir lieber die Datenblätter von ST (user manual) und fange an OHNE diese scheussliche "ST-Periheal Lib" zu programmieren (also ganz altmodisch mit Registern). Die Datenblätter sind super; wenn man sich die Mühe macht einzulesen, dann klappt das damit sehr gut. Wenn du die Timer, ADC, USART, SPI und GPIO etc. alle in Betrieb genommen hast, dann hast du schon mal ein viel besseres Verständnis für den uC als die Heerscharen an Möchtegern-Programmierern, die auf diese komische Library schwören (weil sie sich dadurch wohl nicht mit der HW beschäftigen müssen und bei jedem Schei.... hier im Forum rumheulen) Just my 2 cents...
Dennis schrieb: > Wenn du die Timer, ADC, USART, SPI und GPIO etc. alle in Betrieb > genommen hast, Darüber steht in dem Buch doch garnichts; dafür ist es nicht geschrieben!
Ich habe die allererste Ausgabe. Das Buch beschreibt den Prozessorkern. Das macht es wirklich gut, und dafür ist es auch zu empfehlen. Peripherie bleibt außen vor. Die ist ohnehin von Chip zu Chip und von Hersteller zu Hersteller komplett verschieden. Dafür gibt es andere Informationsquellen. fchk
m.n. schrieb: > Dennis schrieb: >> Wenn du die Timer, ADC, USART, SPI und GPIO etc. alle in Betrieb >> genommen hast, > > Darüber steht in dem Buch doch garnichts; dafür ist es nicht > geschrieben! Und jetzt versuche mal mein Posting vollständig zu lesen und zu verstehen :-)
Achso, vieleicht sollte ich mich konkretisieren: der TO möchte - so wie ich es verstenaden habe - den uC erst einmal verwenden, nicht die letzten Feinheiten ausloten.
@Dennis: Das ist richtig, aber ich möchte mir auch ein gewisses Grundverständnis der Architektur aneignen und ich denke, dass mir das Buch da enorm weiterhelfen könnte.
Dennis schrieb: > der TO möchte - so wie ich es verstenaden habe - den uC erst einmal > verwenden, nicht die letzten Feinheiten ausloten. Fangen wir mit der allerersten Feinheit an: NVIC Ohne zu wissen, was dort abgeht, ist jede ISR zunächst ein Blindflug. Noch etwas: PDF vs. Buch Das Buch kann man überall lesen, auch im Garten bei Sonnenschein oder bei Stromausfall mit Kerzenlicht.
Wenn du einfach nur was programmieren willst, reichen die Peripheral Manuals vom jeweiligen MCU Vendor. Wenn du das Dingen an die Grenzen treiben willst, schnapp dir das Buch :-) Alles lesen brauchst du nicht, aber die Anfangskapitel sind schon nicht uninteressant, bzw. das Buch als Nachschlagewerk benutzen. Vor allem der NVIC hat's richtig in sich, schau dir dazu auch mal den CMSIS Layer, die Funktionen in der core_cm3.h (bzw. dem Äquivalent) an. Auch empfehle ich, bei etwas komplexeren Anwendungen frühzeitig auf ein RTOS zu setzen, das erspart dir hinterher ne Menge Arbeit.
> Ohne zu wissen, was dort abgeht, ist jede ISR zunächst ein Blindflug.
Hmmm ... lasse ich so nicht stehen.
Mit den CMSIS Hilfsfunkionen reicht schon mit NVIC_EnableInterrupt() und
de Kiste rennt.
Was meisst auch ausreicht. Später kann man sich dann um die Prioritäten
NVIC_SetPriority() bzw. das Priority Grouping Gedanken machen.
CMSIS Standardisierung ... man ist das lang her :-)
Ich kann den Yiu empfehlen (nach einem laengeren Projekt auf Freescale Kinetis). Du wirst, wenn Du nicht gerade etwas extrem Langweiliges machst, irgendwann seltsame Crashes bekommen, und dann kommt eine Erklaerung, wie man die Fault-Status-Register interpretiert und wie ein Interrupt-Stack-Frame aussieht, gerade recht. Kann man sich vermutlich auch woanders zusammensuchen, aber wenn Deine Zeit nicht gratis ist, lohnt sich so'n Buch schon. Auch so Sachen wie den Syscall-Mechanismus mit PendSV erklaert er recht gut. Da musste ich auch schon mal debuggen (Freescale MQX auf Kinetis). --Konrad
Konrad schrieb: > wenn Deine Zeit nicht gratis ist, > lohnt sich so'n Buch schon. Zeitlich noch lohnender ist es, wenn man auf Syscall-Mechanismus mit PendSV, Interrupt-Stack-Frames,seltsame Crashes, Fault Status Register Interpretation, NVIC_SetPriority() bzw. das Priority Grouping, CMSIS Layer, die Funktionen in der core_cm3.h usw. in seinen konkreten Projekten verzichten kann und diese weiter mit gewohntbewährter, einfacher AVR Technik umsetzt ;-)
manche schwören darauf, ich finds nicht allzugut... perönlicher geschmack... manual vom hersteller + das manual vom core reichen eigentlich... core-manual gibts bei arm selbst -> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0403c/index.html 73
Hans Wilhelm schrieb: > manche schwören darauf, ich finds nicht allzugut... perönlicher > geschmack... Kannst du ein konkretes Beispiel geben, was du an dem Buch nicht magst? Würde mich mal interessieren, weil du bis jetzt der einzige bist, der dieser Meinung ist.
Niemand wird daran gehindert, sich eine "Leseprobe" aus den Indernet zu zuzeln. Bei Gefallen kann man sich den Schinken dann trotzdem beim jobverachtenden Yankee bestellen. Der U.S. Gockel hilft einem sogar dabei.
Moby schrieb: > Zeitlich noch lohnender ist es, wenn man auf Syscall-Mechanismus mit > PendSV, Interrupt-Stack-Frames,seltsame Crashes, Fault Status Register > Interpretation, NVIC_SetPriority() bzw. das Priority Grouping, CMSIS > Layer, die Funktionen in der core_cm3.h usw. in seinen konkreten > Projekten verzichten kann und diese weiter mit gewohntbewährter, > einfacher AVR Technik umsetzt ;-) Ich kann mir nicht vorstellen, dass du die CMSIS NVIC Funktionen in deinem Code schneller hinbekommst, als sie im CMx core Layer implementiert sind :-) Ok, ein Vergleich fällt weg, wo zwischen Core und Vendor Interrupts unterschieden wird, aber sonst bekommst es nur dann schneller, wenn du die SetPrio für 4 nebeneinanderliegenden Interrupts merged. Oder äquivalent für das Enable/Disable jeweils Gruppen von 32 Interrupts :-) AFAIK: Der AVR (8Bit) verfügt nicht über die oben gelisteten Mechanismen :-) Ich selbst bin so gar kein Fan von DriverLibraries, und CMSIS hat auch überhaupt nichts damit zu tun. CMSIS ist lediglich die Spezifizierung der Peripherals als structs, sowie eine Hand voll Funktionen für spezielle Core Zugriffe / NVIC, die dann über alle Compiler gleich aussehen. DriverLibs setzen ggf. auf CMSIS auf.
Random ... schrieb: > AFAIK: Der AVR (8Bit) verfügt nicht über die oben gelisteten Mechanismen > :-) Und das ist auch gut so !!! SimplyAVR heißt das Zauberwort, was die Bastleraugen strahlen läßt ;-)
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.