mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Literatur für ARM-CORTEX-M3


Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tarkan D. schrieb:

> -Erstens, niemand kann mit diesen "Sche.ße in Silizium gepressen
> Schrott" wirklich etwas anfangen

PS: Fühlst du dich jetzt besser?

Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ttl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tueftler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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 ).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: bitschubser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: ./. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chefkoch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.