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 ;-)
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 ;-)
