STM32, ST-Library oder Registerarbeit?

Es gibt dazu verschiedene Ansichten. Mir sind in den meisten Fällen die 
Register lieber, weil ich dafür nur eine Doku brauche statt zwei, und 
nicht noch Fehler der Lib einplanen muss. Viele verwenden jedoch die 
Lib.

Wirklich portable sind nur die Funktionen vom CMSIS, also diejenigen, 
die Teil des Cortex M Cores ansprechen, wie NVIC und Systick. Die 
anderen sind nicht einmal innerhalb der STM32 Familie ganz einheitlich 
(F1/F2/F4).

Hallo Mike

Was willst du erreichen?

Ist dies eine einmalige Geschichte, wo es dir eher auf das Verstehen des 
internen Ausbaus ankommt. Keiner wird dies weiter verwenden, geschweige 
denn auf einen ähnlichen Prozessor portieren? -> dann kann man sich das 
alles selbst erarbeiten und muss nicht unbedingt die vorgefertigen Dinge 
verwenden. Ein wenig Geschwindigkeit kann man damit evtl. auch 
herausholen (was normalerweise völlig unwichtig ist...).

Oder soll damit nochmal jemand etwas anfangen können?

Gruß Klaus

Zu beginn würde ich eher zur Library tendieren, denn alle ST Demos sind 
darauf aufgebaut.

Wenn man sich ein wenig rein gearbeitet hat, dann kann man auch direkt 
die Register verwenden.

Die meisten Library-Befehle für die Initialisierung sind auch nur ein 
wenig Bits hin und her schieben, das bekommt man auch mit Register 
selbst hin.

Ich verwende gerne z.B. für die Initialisierung der GPIO Pins die 
Library, hingegen für das Bit-EA die GPIOx->... Register direkt.

Man kann Problemlos mischen.

Schlussendlich ist es Geschmackssache.


PS: Auch in der ST-Lib gibt es zwischen STM32F1xx und F2xx/F4xx 
Unterschiede.
(Andere PLL Berechnung, GPIO ist neu am AHB nicht mehr am APB)

zwischen F2xx und F4xx gibt es kaum einen Unterschied.

Mike schrieb:
> Hallo,
>
> vielen Dank für Eure Antworten.
>
> Mit dem STM32 möchte ich neben dem AVR eine Alternative für höhere
> Anforderungen auf Lager haben. Zur Zeit arbeite ich in erster Linie mit
> AVR, kam in letzter Zeit jedoch ein paar Mal an dessen Grenzen. Entweder
> aufgrund des Speichers oder aufgrund seiner Taktung/Rechenleistung.

Warum dann nicht AVR32 UC3? Da gäbe es mit dem AVR Software Framework 
auch entsprechende Libraries die neben den AVR32 UC3s auch die megaAVRs 
und XMEGAs unterstützen