STM32F0 Discovery welche Library wird genutzt (HAL oder SPL)?

vs schrieb:
> benötige ich das Reference Manual /
> Programming Manual wenn ich die HAL nutze?

Ja!

Vor allem als Anfänger empfehle ich dir die SPL zu nutzen.

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:
> 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.

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.

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?

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.

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.

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.

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

./. 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.

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.