Hallo zusammen, ich werde mich demnächst mit meinem neuen STM32F0
Discovery Board beschäftigen. Habe mir sämtliche Datenblätter und auch
die Beispielprogramme heruntergeladen.
Eine Frage habe ich da nur, ST hat ja kürzlich auf die HAL Library
umgestellt, da ich weder mit der Standard Peripherals Library noch mit
der HAL etas zu tun gehabt habe würde es mich interessieren, ob die
Beispiele des Discovery Boards schon in HAL sind oder noch in der alten
SPL. An was kann man sonst noch erkennen welche Library genutzt wird?
Hier mal ein Codeausschnitt für GPIO:
1
intmain(void)
2
{
3
/*!< At this stage the microcontroller clock setting is already configured,
4
this is done through SystemInit() function which is called from startup
5
file (startup_stm32f0xx.s) before to branch to application main.
6
To reconfigure the default setting of SystemInit() function, refer to
vs schrieb:> An was kann man sonst noch erkennen welche Library genutzt wird?
am HAL_Init(); in main und diversen MX Funktionen
Wenn Du STM32CubeMX benutzen willst werden die Projekte mit HAL erzeugt.
Soll sich aber demnächst evtl. ändern.
Und noch eine Frage zwischendurch, benötige ich das Reference Manual /
Programming Manual wenn ich die HAL nutze? So wie ich das verstanden
habe ist es nicht nötig den Controller im Detail zu verstehen wenn ich
die HAL nutze.
vs schrieb:> Und noch eine Frage zwischendurch, benötige ich das Reference Manual
Ja
> So wie ich das verstanden habe ist es nicht nötig den Controller> im Detail zu verstehen wenn ich die HAL nutze.
Wenn du der Meinung bist, es wäre zu kompliziert oder aufwendig oder
sonstwie unnötig, den verwendeten µC im Detail zu verstehen, dann
solltest du am besten gleich die Finger davon lassen und dir ein
anspruchsloseres Hobby suchen. Vielleicht Briefmarken sammeln.
Auch wenn Axel teilweise recht hat, eine schöne und treffende
Formulierung gewählt hat, lass die Definition von "im Detail" mal ausser
acht. Jeder hat einmal angefangen. Was du brauchst sind auf jeden Fall
die Manuals und du musst anfangen dich in die Materie einzuarbeiten.
Ohne die Manuals wirst du nicht viel mehr wie ein paar LEDs zum Blinken
bringen können. Und wie gesagt, ich empfehle dir mit der SPL anzufangen.
Reginald L. schrieb:> Vor allem als Anfänger empfehle ich dir die SPL zu nutzen.
Ich empfehle Anfängern eher, das Datenblatt zu lesen und (wenn nötig)
den Artikel Bitmanipulation und dann direkt mit den Registern des µC
und den Bits darin zu arbeiten. Eine HAL im eigentlichen Sinn sind ja
weder SPL noch das was ST neuerdings HAL nennt. Denn abstrahiert wird
da gar nichts [1].
Es ist auch nicht wirklich einfacher. Statt den magischen Namen eines
Registers zu kennen, muß man jetzt einen magischen Funktionsnamen
kennen. Statt des magischen Namens des Konfigurationsbits den magischen
Namen des äquivalenten Funktionsparameters. Und natürlich sind beide
Namen nicht gleich. Ähnlich, aber doch hinreichend verschieden daß man
trotz Kenntnis des einen den anderen nicht erraten kann. Irgendwie kein
Vorteil. Außer daß man zusätzlich zum Datenblatt auch noch die
Beschreibung der Library lesen muß.
[1] Das Kennzeichen einer HAL ist (zumindest nach meinem Verständnis)
daß die Bedeutung der Funktionsnamen und Parameter von der Hardwareebene
auf die Applikationsebene verschoben wird. Also statt GPIO_Write(Port,
Pin, Wert) eine Funktion LED_Error_On(). Statt GPIO_PortA_Write(Byte)
eine Funktion LCD_Command(Byte). etc. pp.
Die logische Folge ist, daß eine solche HAL nicht generisch sein kann,
sondern spezifisch für jede Applikation sein muß.
Axel S. schrieb:> Wenn du der Meinung bist, es wäre zu kompliziert oder aufwendig oder> sonstwie unnötig, den verwendeten µC im Detail zu verstehen, dann> solltest du am besten gleich die Finger davon lassen
Wie maschst du dass aufm PC? Schreibst du deine Programme speziell für
Core i-5? Und nur für ein spezielles Mainboard, bei dem du jede
Kleinigkeit ganz genau kennst?
Lass das mal sacken, denk mal darüber nach. ;-)
no name schrieb:> Wie maschst du dass aufm PC? Schreibst du deine Programme speziell für> Core i-5?
Natürlich, ein Treiber - nichts anderes schreibt man ja bei uC
Peripherie Zugriffen ja - ist auch auf dem PC an die Hardware angepasst.
Die PC Programme, die nicht an die Details der Hardware angepasst sind,
benutzen die Hardware Abstraktion des OS. Nur wenn man ein OS mit
ähnlich vollständiger Abstraktion auf dem uC nutzt, kann man die Details
der Hardware ignorieren. Allerdings kann man dann auch meistens nicht
die Spezial Features einiger uC-spezifischer Peripherie nutzen...
Axel S. schrieb:> Ich empfehle Anfängern eher, das Datenblatt zu lesen und (wenn nötig)> den Artikel Bitmanipulation und dann direkt mit den Registern des µC> und den Bits darin zu arbeiten.
Vor allem Anfänger wollen möglichst schnell Erfolge sehen. Das bedeutet
nach einigen Minuten programmieren soll man etwas "sehen" können. Das
fördert das Selbstbewusstsein und man bleibt am Ball anstatt frustriert
aufzugeben (der eine früher der andere wesentlich später). Deshalb mein
Verweis auf die SPL: Es gibt viele Beispielcodes hierzu. Änderungen
lassen sich aufgrund der Lesbarkeit leichter und schneller
bewerkstelligen. Mit der nötigen Übung kann man dann auf direkte
Bitänderungen umsteigen.
Ist natürlich Ansichtssache, welche Methoden man zum Erlernen einer
Aufgabe bevorzugt, genauso wie beispielsweise bei der Kindererziehung
oder dem Schulsystem.
no name schrieb:> Wie maschst du dass aufm PC? Schreibst du deine Programme speziell für> Core i-5? Und nur für ein spezielles Mainboard, bei dem du jede> Kleinigkeit ganz genau kennst?
Der Vergleich hinkt etwas. Wenn du ein eigenes OS programmierst, dann
ja. Falls du auf Windows einen Kreis zeichnen möchtest, eher weniger.
Auf einem µC programmierst du in Richtung OS. Ansonsten ist es absolut
so wie Dr.Sommer sagt.
Reginald L. schrieb:> Auf einem µC programmierst du in Richtung OS.
Nö, die Meisten schreiben Anwendungen. Unsinniger Weise erfinden sie
dabei das Rad jedesmal neu, weil sie keine libs nutzen. Und genau wie
heute die C Runtimes normal sind, wird morgen Cube und Co. normal.
No name schrieb:> Nö, die Meisten schreiben Anwendungen. Unsinniger Weise erfinden sie> dabei das Rad jedesmal neu, weil sie keine libs nutzen. Und genau wie> heute die C Runtimes normal sind, wird morgen Cube und Co. normal.
Na dann viel Spaß mit deinem Cube und zeitkritischen Anwendungen. Ich
komme nicht aus der Elektronikerbranche, aber ich kann mir kaum
vorstellen, dass ein ernsthafter Entwickler Cube benutzt.
Wenn es bei zeitkritischen Anwendungen auf den einzelnen Befehl ankommt,
hast du einen schwerwiegenden Designfehler. Da solltest du an anderer
Stelle mehr Hirnschmalz einsetzen.
Naja, die Diskussion über den (Un-)Sinn der STM SPL (Standard Peripheral
Library) bzw. der neuen HAL hatten wir ja schon ein paar mal. Ich habe
bisher ganz ohne dies Programmiert und nur die HW-Definitionen aus dem
CMSIS verwendet.
Ich habe mich jetzt bei meinem letzten kleinen Projekt auf dem STM32F030
mal selbst gezwungen, die SPL zu verwenden.
Positiv:
- Ein paar Kleinigkeiten bei der Initialisierung mit den Init-Funktionen
werden automatisch beachtet, so dass man sich nicht selbst darum kümmern
muss
- Es sind auch für Sachen Definitionen vorhanden, die in den normalen
Standard CMSIS Header-Files fehlen
Negativ:
- Die Strukturen für die Initialisierung nehmen evtl. Speicher (Stack)
weg
- Natürlich bekomme ich als ehem. ASM-Coder Krätze, wenn ich mir
überlege, dass ich z.B. zum Setzen oder Abfragen eines Bits ein
Unterprogramm aufrufe, welches teilweise auch noch relativ sinnfreie
IF-Abfragen enthält.
Neutral:
- Keine echte HW-Abstraktion, man muss die Beschreibung der Funktionen
und Register im Ref.manual auf jeden Fall verstanden haben.
- Mit dem SPL bzw. HAL wird es nicht unbedingt einfacher. Letzten Endes
musste ich nun nicht nur die Funktionen und Bits anhand des Ref.manuals
verstehen, sondern auch noch zusätzlich die Definitionen bzw. teilweise
auch die Implementierung(!) der entsprechenden SPL-Funktion anschauen um
sie einsetzen zu können.
Da aber viele Leute die SPL/HAL einsetzen, werde ich wohl jetzt dabei
bleiben und im Zweifelsfall die Initialisierung darüber machen und bei
zeitkritischen Sachen direkt mit den Registern/Bits arbeiten.
Bei den Definitionen für die Bits/HW gibt es aber definitiv
Verbesserungspotential. Zumindest beim STM32F030 gibt es für einige
Sachen garkeine Definitionen, da hat sich Atmel beim AVR mehr Mühe
gegeben.
No name schrieb:> Wenn es bei zeitkritischen Anwendungen auf den einzelnen Befehl ankommt,> hast du einen schwerwiegenden Designfehler. Da solltest du an anderer> Stelle mehr Hirnschmalz einsetzen.
Nö. Man entscheidet sich immer für einen bestimmten Weg eine
Problemstellung zu lösen. "Hirnschmalz" kannst du genauso gut mit "Geld"
ersetzen.
Schwerwiegender Designfehler... neuer Begriff für effizienten Code?
Was machst du morgen, wenn eine Kleinigkeit ergänzt oder geändert werden
muss? Du fängst wieder von ganz Vorne an?
Nee, da wirst du nicht weit kommen. Du denkst zu kurz. Die meisten
Projekte enden nicht mit dem Roll out.
> auf den einzelnen Befehl ankommt
Das SPL- und besonders das HAL-Gedoehns ist nicht nur einzelner
Befehl mehr.
Da wird teilweise auch voellig ungefragt Funkionalitaet
angeworfen, die man weder braucht noch will.
Fuer die STM32F0 braucht man nicht mehr als das typspezifische
Headerfile (und die Referenzmanuals vom Controller/M0).
Da ich Anfänger bin stellt sich für mich halt die Frage was ich alles
lesen muss um den Controller zu programmieren.
Ich will definitiv NICHT in Assembler programmieren sondern in C. Reicht
das Reference Manual u. Controllerspezifische Datenblatt dafür aus? Wozu
gibt es das Programmen Manual?
Kurz und knapp gefragt: Was brauche ich mindestens um den STM32F0 in C
zu programmieren?
Im controllerspeufisichen Datenblatt sind die einzelnen Pins und ihre
Spezialfunkionen ("Alternate Functions") definiert. Auch die
elektrischen Eigenschaften sind dort festgelegt.
Für die Programmierung benötigst Du das Reference Manual zu der Serie.
Im Reference Manual solltest Du Dir auf jeden Fall den Abschnitt zum RCC
(Clockverteilung) und dann zu der jeweiligen Peripherie anschauen.
Also für den Anfang dann am besten den Abschnitt über die GPIOs.
Viele Peripherieeinheiten haben wirklich viele Features, so dass man
schnell das Gefühl hat erschlagen zu werden. Aber ich würde mir das
alles ruhig einmal durchlesen um einen Überblick zu haben und danach
dann die Stellen mit den wirkich benötigten Funktionen.
Die eigentlichen Einstellungen für die Taktberechnung musst Du nicht
selbst machen. Das ist alles schon im Startup-File enthalten bzw. Du
kannst dieses File generieren lassen (dafür gibt es bei STM ein
Excelsheet mit Makros).
vs schrieb:> Kurz und knapp gefragt: Was brauche ich mindestens um den STM32F0 in C> zu programmieren?
Zuerst mal eine geeignete IDE mit Toolchain, EmBlocks oder CooCox
benutzen viele. Ich benutze VisualStudio mit VisualGDB.
Dann brauchst du natürlich noch die SPL- (bzw. HAL-) Library. Für die
Einrichtung einer IDE gibt es massig Tutorials, -> Google.
Wenn du Erfolge sehen willst (und wirklich Anfänger bist(!)), fang bloß
nicht an die Manuals "durchzulesen" wie hier so mancher empfiehlt. Du
wirst eh kaum kapieren was da drin steht. Ich spreche aus eigener
Erfahrung, bin Maschinenbauer und hatte vor einem Jahr meinen ersten
Kontakt mit µCs. Lade dir trotzdem schon mal das ReferenceManual für
deinen µC runter. Das ist das wichtigste Dokument, dass du dann immer
wieder und immer öfter durchblättern wirst. Das ProgrammingManual
brauchst du auch, dort sind die Hardware-Fakten hinterlegt, wie zb.
maximale ADC-Taktrate etc.
Einfach mal googlen nach deinem µC und den o.g. Manuals.
Google ist, neben den Manuals, dein wichtigster Begleiter.
Es empfiehlt sich, sich an irgendwelche Examples oder Tutorials zu
halten und die den Entsprechenden Wünschen anzupassen.
Just my 2cents.
Ok danke erstmal für die Empfehlungen. Wie sieht es aus wenn ich zB
weder die SPL noch die HAL nutzen will, sondern direkt die Register
beschreiben will? Geht das dann nur noch mit Assembler oder auch mit C?
Ich frage weil es wohl leute gibt die auf diese Weise ihre eigenen
kleinen Bibliotheken zusammenbasteln und somit unabhängig von der SPL /
HAL sind oder was auch immer noch kommen mag.
vs schrieb:> Wie sieht es aus wenn ich zB> weder die SPL noch die HAL nutzen will, sondern direkt die Register> beschreiben will? Geht das dann nur noch mit Assembler oder auch mit C?
Das sind zwei verschiedene Paar Stiefel. Du kannst die Register
natürlich selbst setzen. Ob in Assembler oder in C ist dir überlassen.
Was natürlich nicht geht, ist SPL in Assembler. Als Anfänger würde ich
erst mal die Finger vom Assembler lassen. Mag sein, dass man hier mehr
über die Funktionsweise eines µCs kennenlernt. Für mich wäre das zuviel
auf einmal.
vs schrieb:> Ich frage weil es wohl leute gibt die auf diese Weise ihre eigenen> kleinen Bibliotheken zusammenbasteln und somit unabhängig von der SPL /> HAL sind oder was auch immer noch kommen mag.
Klar, es gibt auch eine C++ Lib ("STM32plus"). Wie gesagt, für den
Einstieg empfehle ich SPL.
Was bei der lesenswerten Dokumentation immer gerne weggelassen wird,
ist die "technische Referenz" von ARM selber.
Nur in Ausnahmefaellen, z.B. Philips, ist das in die Manuals
eingefuegt worden.
Fuer die STM32F0 waere das:
Cortex™-M0
Technical Reference Manual
ARM DDI 0432C
Viel Erfolg!
vs schrieb:> Kurz und knapp gefragt: Was brauche ich mindestens um den STM32F0 in C> zu programmieren?
* Einen PC (vorzugsweise mit Linux, Windows geht aber auch zur Not)
* Reference Manual und Datenblatt für den Controller
* OpenOCD
* GNU Arm Toolchain
* Überdurchschnittliche C-Kenntnisse
* Gute Kenntnisse der verwendeten Tools (Compiler, Linker, Debugger,
etc)
* Einen brauchbaren Texteditor¹
* Ein paar funktionierende Beispiele zum Einstieg
* Geduld und Ausdauer
______________
¹Den Texteditor wirst Du später (SPÄTER!) durch eine IDE ersetzen, aber
erst wenn Du verstehst wie alles zusammenhängt, ansonsten wird es von
Anfang an ein Blindflug im Nebel.
So langsam kommt in mir die Frage auf ob ich mich als Anfänger mit dem
stm32 übernommen habe? Es heist doch die seien nicht schwerer als die
kleinen Controller. Ich frage weil der letzte Beitrag sich sehr
abschreckend anhört, alle fangen doch mit einer IDE an, warum nicht mit
der Zeit immer mehr in den Controller einarbeiten.
Lass dich nicht entmutigen :) für die STM32's findest du für fast jede
Frage eine Antwort incl. Beispielcode mit google. Am Anfang ist wichtig
zu lernen das es wie bei allen Sachen immer Hardliner gibt die man nicht
zu ernst nehmen sollte :D. Es seiden natürlich man hat lust auf
Glaubenskriege...
viel Erfolg :)
no name schrieb:> Axel S. schrieb:>> Wenn du der Meinung bist, es wäre zu kompliziert oder aufwendig oder>> sonstwie unnötig, den verwendeten µC im Detail zu verstehen, dann>> solltest du am besten gleich die Finger davon lassen> Wie maschst du dass aufm PC? Schreibst du deine Programme speziell für> Core i-5? Und nur für ein spezielles Mainboard, bei dem du jede> Kleinigkeit ganz genau kennst?> Lass das mal sacken, denk mal darüber nach. ;-)
Du bist echt eine Prothese! Denk darüber nach!
_______________________________________________
@TE
Fang einfach mit der SPL an. Wenn du bei 48Mhz ein
Geschwindigkeitsproblem findest, dann nehmst du den stm32f103 mit 72Mhz
oder den stm32f4 discovery mit 168Mhz usw.
BZW du lehrnst effektiv zu programmieren, dann merkst du, dass fast bei
jeden Projekt ein 8Bitter aussreichend ist.
Ahmen.
> immer Hardliner gibt
Wenn man einer Sache auf den Grund gehen will, darf man
nicht nur an der Oberflaeche herumkratzen.
Gerade die STM32F0 sind uebersichtlich genug, mit dem
Referenzmanual bewaffnet, auch mal selber an den Knoepfen
zu drehen und das nicht irgendwelchen Libs zu ueberlassen.
Ansonsten wird das Wissen oberflaechlich bleiben, sieht
man hier ja an den vielen Arduino-"Experten".
Bei komplexeren Themen sind Libraries natuerlich der richtige Weg.
Aber hier geht es um den Einstieg.
./. schrieb:
>Ansonsten wird das Wissen oberflaechlich bleiben, sieht>man hier ja an den vielen Arduino-"Experten".
Für mich war Arduino der richtige Einstieg. Ich hatte keine großen
Ziele. Aber mit der Zeit wollte ich mehr und jetzt mache ich
Zeitkritische Sachen auf dem F0 ohne irgendwelche Libraries... Ist doch
immer die Frage was man grade will.
> Für mich war Arduino der richtige Einstieg. Ich hatte keine großen> Ziele. Aber mit der Zeit wollte ich mehr und jetzt mache ich> Zeitkritische Sachen auf dem F0 ohne irgendwelche Libraries... Ist doch> immer die Frage was man grade will.
So in etwa habe ich das auch vor gehabt, habe auch schon eine Hand voll
guter Tutorials. Erstmal einfach anfangen.
vs schrieb:> So langsam kommt in mir die Frage auf ob ich mich als Anfänger mit dem> stm32 übernommen habe?
Kommt drauf an, wie du mental gebaut bist. Im Grunde ist alles durchaus
einfach, wenn man sich nicht auf Aufgebauschtes stürzt und wenn man
einigermaßen fix mit dem Kapieren ist.
Also was brauchst du wirklich:
1. eine Toolchain, also Compiler, Assembler, Linker, Hexfilegenerator
(aka fromelf) und die Bibliotheken zum Compiler.
2. eine Hardware, also deinen Lieblingschip auf einer Leiterplatte.
3. etwas zum Brennen des erzeugten Codes in den Chip. Das hängt vom Chip
UND von der Leiterplatte ab. Alle (mir bekannten) STM32xyz haben einen
festeingebauten Bootlader intus, der es gestattet, selbige über eine
poplige serielle Schnittstelle (z.B. USB->seriell) zu programmieren.
Parallel dazu haben die meistenauch noch ein JTAG-Interface und darin
enthalten eine SWD-Interface. Aber für die letzteren brauchst du ein
spezielles Geschirre, also einen JTAG/SWD-Adapter - und der kann (muß
aber nicht sein) mit auf der LP sein.
4. einen Editor.
5. ein Brennprogramm, das zu Punkt 3 paßt. Hier hakt es am ehesten. Für
die Verwendung des Bootladers gibt es ein schlecht gepflegtes Projekt
bei ST, für SWD könntest du dir einen Seggerschen J-Link Edu kaufen
(aber der enthält keine Lizenz für JFlash) und ob es ein gutes
Standalone-Programm für den ST-Link gibt, weiß ich momentan ncht. Das
alles zusammen ist zumeist der Grund, weswegen hier viele auf irgend
eine IDE zurückgreifen, da diese zumeist das Brennprogramm eingebaut
haben. Aber alle diese IDE's haben ihre Nachteile, insbesondere den Hang
zum Aufgebauschten.
6. ein klitzekleines Stückchen Kenntnis von ARM-Assembler, um einen
ordentlichen Startupcode für deinen Chip schreiben oder adaptieren zu
können - UND!!! um wenigstens den blutigen Anfang verstehen zu lernen.
7. Das HW-Manual zu deinem Chip, um nachlesen zu können, was wo an
welchem Pin raus oder reingehen kann
8. Das Familien-Referenzmanual, um Kenntnis der Hardware-Register und
systemaufbau zu erlangen
9. Die Schaltung zu deiner Leiterplatte
W.S.
W.S. schrieb:
...
> 5. ein Brennprogramm, das zu Punkt 3 paßt. Hier hakt es am ehesten. Für> die Verwendung des Bootladers gibt es ein schlecht gepflegtes Projekt> bei ST, für SWD könntest du dir einen Seggerschen J-Link Edu kaufen> ... ob es ein gutes> Standalone-Programm für den ST-Link gibt, weiß ich momentan ncht.
Wenn man ein unixoides Betriebssystem hat oder ein passend erweitertes
Windows, dann kann man stm32flash verwenden, um einen STM32 über den
Bootloader zu flashen. Und stlink oder openOCD liefern einen Debug-
server für die ST-Link Hardware. Dann kann man (s)ein Programm aus dem
Debugger heraus auf den Chip laden und auch debuggen.
> 6. ein klitzekleines Stückchen Kenntnis von ARM-Assembler, um einen> ordentlichen Startupcode für deinen Chip schreiben oder adaptieren zu> können - UND!!! um wenigstens den blutigen Anfang verstehen zu lernen.
Assembler ist optional. Man kann den Startup-Code durchaus auch in C
schreiben. Wenn man nicht ohnehin den vorgefertigten Code aus einer
Library verwendet. Für STM32 hat man da viel Auswahl: SPL, HAL,
libopencm3. Dazu noch die diveren IDE, die das auch alle enthalten.
Fuer die STM32F0 gab es, wenn mich recht entsinne, auch eine
"freie" Version eines kommerziellen Compilers.
Entweder wars von IAR oder von Keil.
Da musst Du mal bei ST und/oder hier im Forum mal nach suchen.
Setzt als Betriebssystem Windows voraus, erspart einem aber
am Anfang viele Klimmzuege.
Thread beobachten
Seitenaufteilung abschalten