Hallo Leute, ich muss mich mal wieder mit meinen STM32-Problemen zu Wort melden. Endlich habe ich mal wieder zeit mich diesem Thema zu widmen stelle (ohne erstaunen) fest, dass ich nicht in der Lage bin anständig mit diesen Teilen zu arbeiten. Kennt jemand irgendein BUCH, in dem ganz konkret steht wie man irgendeine dieser Biester programmiert. Sei es LPC,TI,STM... Langsam beschleichen mich folgende Vermutungen: -Erstens, niemand kann mit diesen "Sche.ße in Silizium gepressen Schrott" wirklich etwas anfangen (weil es keine, aber auch wirklich keine gescheiten Informationen diesbezüglich gibt) -Niemand will sein wissen teilen -Ich bin einfach zu dumm irgendwas damit anfangen zu können -Diese zum teil hoch gelobte "standart Peripheral Library" von ST ist nicht wirklich so toll wie alle behaupten. Es kann doch nicht sein, dass da keine anständige Dokumentation vorhanden ist, nur dieses vollgerotze .CHM - file, dass nur mit links vollgestopft ist, welche die ganze zeit nur auf quellcode-schnipsel und dürftige erklärungen zeigen. Ich hab es mit ach und krach geschafft das Rs232-Modul zum laufen zu bekommen, das I2C modul macht zwar was, nur nicht das was es soll (aber sei es drum). Ich kann jetzt nicht wochenlang zeit rein investieren ohne irgendwelche Fortschritte zu beobachten. Derzeit habe ich noch ein paar LowCost boards mit LPC11xx,13xx,17xx georderdert und werde mein glück damit versuchen. Aber ich würde gerne bis die da sind mein glück weiter mit den STM32 versuchen. Es kann doch nicht sein, dass damit alle ganz tolle sachen zaubern, nur ich keine fortschritte verbuchen kann. ich hoffe irgendwer kann mir den entscheidenden tip geben. Grüße Tarkan :) PS: wenn jemand einen Kurs für einen cortex m3 empfehlen kann, wäre ich auch dankbar.
Tarkan D. schrieb: > -Erstens, niemand kann mit diesen "Sche.ße in Silizium gepressen > Schrott" wirklich etwas anfangen (weil es keine, aber auch wirklich > keine gescheiten Informationen diesbezüglich gibt) Es gibt mindestens: - Die Architecture Reference von ARM. - Das Reference zum Cortex-M3 Core von ARM. - Das Pendant von STM zum Core in den STM32. - Die Reference von STM über die I/O. - Die Reference von STM über das Flash. - Das Datasheet vom jeweiligen Device. - Das übliche heissgestricke Hitec-Dings. - Den Wälzer "The Definitive Guide to the Arm Cortex-M3". Was mir allerdings noch nicht begegenet ist: Eine Schritt für Schritt Anleitung für Leute, die noch nie einen Mikrocontroller verwendet haben. > -Niemand will sein wissen teilen Etliche Forenbeiträge und mindestens ein Artikel beweisen das Gegenteil. > -Diese zum teil hoch gelobte "standart Peripheral Library" von ST ist > nicht wirklich so toll wie alle behaupten. Es behaupten nicht alle, sondern diejenigen, die sie toll finden, prusten es raus und der Rest hält die Klappe, um nicht in Trollverdacht zu geraten. Ich persönlich mag sie nicht sonderlich und habe das im Forum auch gelegentlich zu verstehen gegeben.
Tarkan D. schrieb: > -Erstens, niemand kann mit diesen "Sche.ße in Silizium gepressen > Schrott" wirklich etwas anfangen PS: Fühlst du dich jetzt besser?
Hi A.K., A. K. schrieb: > Tarkan D. schrieb: > >> -Erstens, niemand kann mit diesen "Sche.ße in Silizium gepressen >> Schrott" wirklich etwas anfangen > > PS: Fühlst du dich jetzt besser? Um erlich zu sein - etwas besser also noch nie mit µC wäre etwas untertrieben. Ich persönlich programmiere seit Jahren Privat und damals an der FH mit Pic 18f-33fj und beruflich mit AVR. Mit keine Informationen meine ich kein "Schritt für Schritt" zeugs. A. K. schrieb: >> -Diese zum teil hoch gelobte "standart Peripheral Library" von ST ist >> nicht wirklich so toll wie alle behaupten. > > Es behaupten nicht alle, sondern diejenigen, die sie toll finden, > prusten es raus und der Rest hält die Klappe, um nicht in Trollverdacht > zu geraten. Ich persönlich mag sie nicht sonderlich und habe das im > Forum auch gelegentlich zu verstehen gegeben. Was mich vorallem stört ist, dass die Dokumentation sich nur auf die Eval-Boards bezieht. Und irgendwie wenn man den links in der Dokumentation lang genug folgt um wirklich heraus zu finden was passiert, hat man schon vergessen wonach man überhaupt gesucht hat. Baer ohne diese Lib kann man ja auch nicht viel anfangen(soweit ich das richtig verstanden habe) weil man sich sonst um irgendwelche waitstates und sonstigen kruscht kümmern muss. Irgendwie ist es wie mit den Frauen: man kann nicht ohne sie, aber mit ihnen geht es auch nicht!
Hallo Leute, also ich entschuldige mich nochmal für meinen Ton grad eben. Es ist mir einfach mal der Kragen geplatzt. Um nochmal zum eigentlichen Thema zurück zu kommen: Weiß jemand literatur, die einem den Umstieg von pic,avr zu arm erleichtert (insbesonders stm32 wäre interessant aber auch andere) Gibt es lehrgänge aus denen man wirklich schlauer raus kommt als man rein gegangen ist?Am besten welche die zeitnah beginnen.. Hat jemand einen Tip wie man sich da am besten rein arbeiten kann? (ist es beispielsweise notwendig sich zuerst 100% mit dem m3-core auszukennen bevor man sich mit peripherie rumschlägt). Ist es geplant den Artikel hier im Forum bei zeiten zu erweitern? Der Teil bezüglich der GPIO's war eigentlich wirklich hilfreich. Grüße Tarkan
Zu den meisten Peripheriemodulen gibt es excellente App-Notes bei ST. Muss man nur lesen. Das Reference Manual enthält auch alles nötige. RTFM
Lad dir bspw. das LPC17XX Usermanual runter. Da steht zu jedem Modul ganz genau drin, wie was programmiert werden muss. Dazu noch die Registerbeschreibungen etc.. Und dann musst du halt die Register beschreiben, wie bei jedem MC.... Was ist das Problem, der große Unterschied zum AVR bspw., das dich so verzweifeln lässt? Vielleicht solltest du die Treiber selber programmieren, nicht irgendwelche Libraries, die sowieso nur Probleme machen und man nicht weiss was sie machen geschweige denn, wo der Fehler liegt. Grüße Tüftler
Tarkan D. schrieb: > (ist es beispielsweise notwendig sich zuerst 100% mit dem m3-core > auszukennen bevor man sich mit peripherie rumschlägt). Wenn man Interrupts verwendet: nicht 100%, aber teilweise schon. Das recht leistungsfähige (lies: komplexe) Interrupt/Exception System der Cortex-M Reihe ist nicht in den Referenzen der realen Chips von STM oder NXP dokumentiert, sondern in der ARM Doku zur ARMv7 Architektur und teilweise in der Doku zum verwendeten Core. Und ohne dessen Kenntnis kommt man bei Interrupts nicht sehr weit. Kenntnis der Cortex M Architektur ist auch sinnvoll, wenn man Halbfertigprodukte wie Yagarto oder Codesourcery verwendet, bei denen man sich ggf. auch noch mit dem Startup-Code rumschlagen muss. Bei vollständigen Entwicklungswerkzeugen (IAR, KEIL, Atollic, Corssworks) entfällt dieser Teil. Hilfreich hierbei ist das erwähnte Buch: "The Definitive Guide to the Arm Cortex-M3".
Tarkan D. schrieb: > Was mich vorallem stört ist, dass die Dokumentation sich nur auf die > Eval-Boards bezieht. Mich stört an der StdLib beispielsweise, dass man zwei Dokus zu beackern hat. Doku und Sourcecode der Lib einerseits und die der Hardware-Referenz andererseits. Da ziehe ich es vor, gleich auf die Hardware zu gehen (z.T. über eigene Treibermodule) und verwende die Lib nur als Beispielcode. Jedenfalls bei einfachem Kram wie GPIO, Timern und CAN - USB habe ich noch nicht verwendet. Ebenfalls stört mit die Aufruftechnik mit ausgiebigster Verwendung von structs zur Parameterübergabe, was auf fruchtlose Zeilenschinderei rausläuft und einen dazu drängt, sich auch mit Parametern zu befassen, die einen im verwendetem Modus überhaupt nicht interessieren. Das KISS-Prinzip wurde bei der StdLib weitgehend vergessen.
@ türftler: Ich hab mir die LPC Datenblätter runtergeladen. Deswegen hab ich mir da auch diese NXPresso boards geordert. Die datenblätter lesen sich gut und vom programmieren her scheit das auch machbar zu sein :) @A.K. : ich verwende Rowley crossworks mit dem J-link. Was ich irgendwo gelesen hatte, dass man nicht so einfach die STDLIB beim STM32 weglassen kann, weil man sich sonst um zeugs kümmen muss von dem ich absolut keinen plan habe ( von Waitstates war die rede ).
Tarkan D. schrieb: > also noch nie mit µC wäre etwas untertrieben. Ich persönlich > programmiere seit Jahren Privat und damals an der FH mit Pic 18f-33fj > und beruflich mit AVR. Eines muss klar sein: Die CM3 basierten Mikrocontroller sind ganz erheblich komplexer als AVRs oder PIC18. Allerdings hatte ich bisher gedacht, dass man mit Kenntnis dieser 8-Bitter immerhin in der Lage ist, die entsprechenden Referenzen zu den NXP-, STM- oder Stellaris-Controllern zu verdauen, auch wenn's anfangs etwas Arbeit ist. Dass die Peripherie-Referenzen etwas kompakter sind als die mit reichlich Beispielcode bestückten Anleitungen in den AVR Datasheets liegt schlicht am Umfang. Allein die entsprechend ausführliche Beschreibung der Timer eines STM32 würde länger aufallen als das komplette Datasheet eines Mega8.
Tarkan D. schrieb: > Was ich irgendwo gelesen hatte, dass man nicht so einfach die STDLIB > beim STM32 weglassen kann, weil man sich sonst um zeugs kümmen muss von > dem ich absolut keinen plan habe ( von Waitstates war die rede ). Wenn ich mich recht erinnere muss man auch bei der StdLib explizit angeben, wieviele Waitstates man haben möchte. Zwar erspart sie dir die Kenntnis der Register, nicht aber dass es programmierbare Waitstates gibt und aber ab wieviel MHz wieviele nötig sind. Beim Rest ist es ähnlich. Die StdLib-Routinen zu den Timern ersparen dir nicht die Erkenntnis, dass so ein Timer ein totes Stück Holz ist solange man ihn nicht mit Takt versorgt. Und das geschieht ganz woanders. Diesen Zusammenhang vermittelt nur die Hardware-Referenz und allein schon deshalb kommt man nicht um sie herum. So steht auch nur dort, was man mit den Timern überhaupt alles machen kann. Nur die eigentliche Bitpfriemelei läuft mit der Lib anders ab. Und genau da wirds deshalb komplizierter, weil man nicht selten erst einmal rauskriegen muss, wie man das, was man aus der Hardware-Ref ermittelt hat, mit anderen Worten und Parametern der Lib beibringt.
@a.k.: Ich hab durchaus mit eingeplant, dass die M3 um einiges komplizierter sind. Also um genau zu sein, war es noch nichtmal das referenceManual des STM32 das mich so auf die palme gebracht hat, sondern diese verflixte stdlib. Und irgendwie ist mir noch nicht ganz klar, was ich an headerfiles etc. brauche um meine lowLevel treiber selber zu bauen. Ich hab halt dieses STM3210-E board vor den latz geknallt bekommen und musste / muss damit klar kommen. Und irgendwie klappt es nicht so wie ich wollte :( Hätte ich vorher die Wahl gehabt wäre ich gleich auf die NXP oder Atmel gegangen.
Tarkan D. schrieb: > verflixte stdlib. Und irgendwie ist mir noch nicht ganz klar, was ich an > headerfiles etc. brauche um meine lowLevel treiber selber zu bauen. Ungefähr so: Der herstellerunspezifische Teil in Form der CMSIS-Files, und das STM32-bezogene File stm32f10x.h. PS: Schimpfen kann ich auch: ;-) Beitrag "Stilblüten in der STM32 firmware library"
Mir hat dieses Buch sehr beim Verständnis des ARM-Core geholfen: Joseph Yiu, "The Definitive Guide to the ARM Cortex-M3" Gibt's u.a. bei Amazon. Gruß, Ulrich
Tarkan D. schrieb: > verflixte stdlib. Und irgendwie ist mir noch nicht ganz klar, was ich an > headerfiles etc. brauche um meine lowLevel treiber selber zu bauen. Für diese Strategie genau und nur den CMSIS Zweig der Lib verwenden, mit CoreSupport und DeviceSupport. Die Firmware-Lib ist im Stdperiph_Driver Zweig und den kannst du bei Verwendung eigener Driver komplett ignorieren. Alternativ kannst du das auch komplett ignorieren und auf dem Support im Crossworks aufbauen.
Servus Tarkan Auch ich hatte so meine Mühe beim Umstieg von AVR -> STM32. Hat Jahre gedauert. Aber die Library find ich sehr gut. Die ist für eben solche Leute wie Du und ich geschrieben, denen man einen Satz schön langsam Buchstabe um Buchstabe vorsagen muss. Oder mit anderen Worten: Die Library ist viel zu sehr aufgeblasen, hat aber den Vorteil, dass man, wenn man mit dem Debugger die einzelnen Schritte verfolgt, man sehr schnell ein "Achsoooooo" Erlebnis hat. Und danach braucht man die Library nicht mehr und kann seine bessere (?) Library oder was auch immer schreiben. Als Lektüre hatte ich nur "The Insers Guide" von Hitex. Aber sehr viel im Internet recherchiert. Nicht aufgeben. Die Durst- und Frust-Strecke durchzustehen lohnt sich auf alle Faelle.
Sicher, der Beitrag ist alt und gerade deswegen frage ich hier. Gibt es mittlerweile schon einiges an Büchern? Ich habe bis jetzt nur das hier schon erwähnte, "The Definitive Guide to the ARM Cortex-M3", gefunden?
Sicher. Es gibt auch einen lesenswerten "The Definitive Guide to the ARM Cortex-M0" und wer haette es gedacht: einen "The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors". Wer mit den TI-ARMs hantiert, wird mit Gewinn: "INTRODUCTION TO ARM®CORTEX-M MICROCONTROLLERS" von Jonathan W. Valvano lesen.
Tarkan D. schrieb: > Langsam beschleichen mich folgende Vermutungen: > > -Erstens, niemand kann mit diesen "Sche.ße in Silizium gepressen > Schrott" wirklich etwas anfangen (weil es keine, aber auch wirklich > keine gescheiten Informationen diesbezüglich gibt) > > -Niemand will sein wissen teilen > > -Ich bin einfach zu dumm irgendwas damit anfangen zu können > > -Diese zum teil hoch gelobte "standart Peripheral Library" von ST ist > nicht wirklich so toll wie alle behaupten. Hmm.. erwartest du jetzt, daß ich dir bzgl. Pkt 3 widerspreche? Also, mein Rat: laß dich nicht von den ubiquitären Software-Schaumschlägern verwirren. Ja - auch dieses Forum ist voll von Leuten, die allen anderen erzählen wollen, daß man ja garnix zu wissen braucht, sondern nur die EINE besondere IDE zu nehmen braucht und schon geht alles wie von selbst. Das sind alles Scharlatane und fiese Lügner. In Wirklichkeit muß man sich mit der Hardware ordentlich befassen und darüber Kenntnisse sich aneignen. Aber eben zur HARDWARE!!! und nicht zu irgendwelchen Trittbrett-Software-Epen oder irgendwelchen IDE's Zur CPU liest du die Referenz von arm.com zum betreffenden CPU-Core. Zum Chip und dessen Eckdaten (Spannungen, Strom, usw.) liest du das Datenblatt des betreffenden Chips von der Homepage des Herstellers. Zum Verständnis der Funktionalität und der Hardware-Register liest du das Referenzmanual zum Chip oder zur Chip-Familie des Herstellers. Dort kannst du auch aus allererster Hand die Adressen der Register und die Bedeutung ihrer Bits entnehmen. Zum Beginnen deines ersten Projektes suchst du dir mehrere Startupcodes in Assembler im INet (vorzugsweise bei Keil oder IAR), studierst diese bis du deren Sinn verstanden hast und dann nimmst du einen davon und änderst selbigen ab, bis daß er zu deinem Chip paßt. Das betrifft vor allem die Vektoren. (Von Beiträgen, wo geschrieben wird, daß man ja gar keinen Assembler-Startupcode bräuchte oder selbiger bereits in einer IDE vorrätig sei, bitte ich hier schlichtweg ABZUSEHEN! - sowas dient nicht dem Verstehen und ist nur für diejenigen Doofen, die partout doof bleiben wollen) So. Jetzt weißt du, was zu lesen sich lohnt. Den Rest an Datenrauschen kannst du getrost ungelesen in die Tonne treten. Dazu gehört eben auch CMSIS und ST-Lib und 80% aller Beiträge hier im Forum. Ja ja, ich weiß, daß RefManuals sich gewöhnlich nicht so nett lesen wie ein Liebesroman - aber da mußt du durch! W.S.
Hallo W.S., deine Aussage trifft im Kern auf das zu, was ich bisher an Erfahrungen mit AVR's und eigentlich allen IC's gemacht habe. Die besten Erkenntnisse gewinnt man durch lesen der Datenblätter und Apnotes der Hersteller. Aber gerade bei den Cortexen finde ich sehr viel, so dass man gar nicht wirklich weiß, wo man wirklich anfängt.
Den Zauber hinter CMSIS habe ich auch nicht verstanden. Letztlich legt CMSIS ja (fast) nur Namenskonventionen fest? Das einzige was bei allen Cortex Derivaten gleich ist, ist ja der Kern, aber 85% von dem was einen µController aus macht, also die Peripherie unterscheidet sich von Hersteller zu Hersteller. Allen gemeinsam ist glaube ich nur ein einziger Timer im Prozessorkern, der sicher für Systicks gedacht ist ? Deshalb CMSIS als Softwarelayer zu bezeichnen, finde ich irreführend. Ich sehe da jedenfalls nicht viel Codeportabilität? Ihr seht die vielen Fragezeichen. Bin leider kein Vollprofi auf µControllern, auch wenn ich es gerne währe.
Bei ST soll es diese Portabilität zwischen den Familien ja geben und man soll, wenn es z.B. auf dem M0 zu eng wird, auf einen größeren ausweichen können und dabei den Code weiter verwenden konnen.
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.