ARM-Einstieg: STM32 L0, F0, F3, F4?

[AVR-Bastler (Gast)]

Hallo,

bietet eine der STM32-Familien den besseren/leichteren Einstieg?
Oder umgekehrt: Hat eine der Familien besondere Tücken und Hürden für 
ARM-Anfänger?
Oder sind die alle "didaktisch" gleich?

Viele Grüße

[Horst (Gast)]

F0 kann weniger als F3/F4. Hier kannst du also erstmal nicht so viel 
übersehen wie bei den großen. Flash-Waitstates und damit verbunden die 
Notwendigkeit von Memory Barriers haben meine ich die F0's auch schon.
Allerdings kann F0 auch weniger an Debugging. Hardfaults sind dort zum 
Beispiel etwas weniger einfach debuggbar, weil es dort weniger 
Informationen (Statusregister) über die Ursache des Auftretens gibt.

[Gerd E. (robberknight)]

AVR-Bastler schrieb im Beitrag #4719993:
> bietet eine der STM32-Familien den besseren/leichteren Einstieg?

die STM32F1 sind die ältesten. Einige Peripherieteile, z.B. das I2C, 
sind dort noch etwas hakelig zu programmieren und haben Bugs (siehe 
Errata-Sheet). die F2 und F4 kamen danach und hatten z.B. beim I2C 
weiterhin die alten Teile, an anderen Stellen gab es schon updates.

Erst die F3 und die F0 haben die neue I2C-Peripherie. Die L0 und die F7 
haben sie auch.

Die L0 und F0 sind, wie Host schon geschrieben hat, beim Debugging nicht 
so schön wie die größeren Serien.

Von daher finde ich eigentlich die F3 nicht schlecht. Z.B. das 
STM32F3DISCOVERY ist gut geeignet für den Einstieg. Flash da am besten 
den STLink auch auf Segger um, dann ist das Debugging noch einfacher.

[Lothar (Gast)]

AVR-Bastler schrieb im Beitrag #4719993:
> STM32 L0, F0, F3, F4

Solange man nur die Libraries verwendet macht es keinen Unterschied.

Will man direkt programmieren oder 8-Bit Programme portieren sind die 
L0, F0 wegen Cortex M0 ohne Unaligned Access anfällig für Hardfault = 
Absturz was schwierig zu finden ist. Der Einstieg mit F4 macht somit 
mehr Sinn.

Abgesehen davon, auch wenn die STM32 hier sehr verbreitet sind, für den 
Einstieg sind ARM mit geradliniger Peripherie wie die LPC 800 / 1500 
deutlich einfacher, da macht dann sogar Assembler Spass. Die STM32 haben 
z.B. eine unsinnig komplizierte Clock, Flash Cache / Waitstates, und für 
Timer, IRQ, PWM etc. unnötig viele Parameter, ohne die erst mal gar 
nichts geht.

[Horst (Gast)]

Lothar schrieb:
> Will man direkt programmieren oder 8-Bit Programme portieren sind die
> L0, F0 wegen Cortex M0 ohne Unaligned Access anfällig für Hardfault =
> Absturz was schwierig zu finden ist. Der Einstieg mit F4 macht somit
> mehr Sinn.

Was aber nicht heißt, dass man aud F4s nicht mit dem gleichen Problem zu 
kämpfen hat (nur eben an anderer Stelle). Insbesondere mit der FPU kann 
es hier gerne mal zu einem Hardfault kommen, weil hier keine 
Unaligned-Unterstützung vorhanden ist.
Letztendlich ist es vielleicht auch garnicht so schlecht, wenn man über 
das Alignment früh genug Bescheid weiß. Hat man da noch nie was von 
gehört, wird man sich dumm und dämlich suchen, warum das Programm immer 
hängenbleibt, obwohl eigentlich alles gut ausschaut (ich habe da locker 
10 Stunden für gebraucht, bis ich das verstanden habe).

[Lothar (Gast)]

Horst schrieb:
> Was aber nicht heißt, dass man aud F4s nicht mit dem gleichen Problem zu
> kämpfen hat

Deswegen kommt man bei sicherheitskritischen Anwendungen auch nicht an 
den Cortex-R vorbei. Bei den Cortex-M ist das IRQ-Handling einfach 
Murks. Nur weil es unbedingt komplett in C gehen musste dieses 
Autostacking statt Registerbänke. Aber was soll man im Hardfault noch 
retten, wenn kein Stack mehr da ist.

> Letztendlich ist es vielleicht auch garnicht so schlecht, wenn man über
> das Alignment früh genug Bescheid weiß

Lustigerweise gibt es das Problem im 8-Bit Bereich auch. Habe grade 
einen High-Speed ADC mit 100 MHz 8051-Kern. Da hat der Flash Waitstates 
und es gibt einen 4-Byte-Cache. Das bedeutet nun aber, dass die 
IRQ-Latenz davon abhängt, an welcher Adresse man ist. Immerhin steht es 
fett im Manual. Die Lösung: ISR in Assembler und mit NOP dafür sorgen, 
dass alle da drin Befehle 4-Byte aligned sind :-)

[Mehmet K. (mkmk)]

Habe kürzlich ein grösseres Projekt fertiggestellt, worin der L0 wegen 
seinem niedrigen Stromverbraucheine eine tragende Rolle hatte.
Für einen Neueinstieg würde ich aber einen STML0 keinem empfehlen.

[Jürgen (Gast)]

Zum Einstisg hab ich damals den F042 gewählt, klein, billig und mit 
Adapterboard gut Steckbrett tauglich.
Dazu noch übersichtlich in den Funktionen, vergleichbar mit den Mega8.
Danach denn F103, F476 und F746. Aktuell ist der F303 um ein wenig mit 
den DSP und DACs zu spielen.
Allerdings betreib ich das ganze auch nur als Hobby.

[aSma>> (Gast)]

Fang einfach an:
http://www.ebay.de/itm/272154524822?clk_rvr_id=1072252542425&rmvSB=true
http://www.ebay.de/itm/172113793450?clk_rvr_id=1071759884923&rmvSB=true
http://www.diller-technologies.de/stm32.html

[AVR-Bastler (Gast)]

Horst schrieb:
> garnicht so schlecht, wenn man über
> das Alignment früh genug Bescheid weiß. Hat man da noch nie was von
> gehört, wird man sich dumm und dämlich suchen

Genau das könnte mir passieren. Alignment kenne ich von Festplatten. Was 
es bei Mikrocontrollern bedeutet muss ich erst einmal nachschauen.

Jürgen schrieb:
> Allerdings betreib ich das ganze auch nur als Hobby.

Ich auch.

Die Reihenfolge easy -> mehr Tücken wäre also:
F3 -> F4/F2 -> F0/L0 -> F1

F4 Disco-Boards gibt's mit Display. Das wäre ja vielleicht auch ein 
Vorteil...

[Nico W. (nico_w)]

Lothar schrieb:
> Die STM32 haben
> z.B. eine unsinnig komplizierte Clock, Flash Cache / Waitstates, und für
> Timer, IRQ, PWM etc. unnötig viele Parameter, ohne die erst mal gar
> nichts geht.

Also mein STM32F411 braucht nicht wirklich viele Parameter. Wenn man 
sich mal den Code selbst schreibt und nicht die aufgeblasenen libs 
nutzt.

Timer:

void timer_init() {
  RCC->APB1ENR |= RCC_APB1ENR_TIM5EN;             // Turn on TIM5 power.

  TIM5->CCR1          = 100000;                   // Fire first after 1ms (100MHz)
  TIM5->CR1          |= TIM_CR1_CEN;              // Enable counter.

  NVIC_SetPriority(TIM5_IRQn, 0);           // Highest priority.
  NVIC_EnableIRQ(TIM5_IRQn);                // Enable interrupt generally.
}

void TIM5_IRQHandler() { 
  TIM5->SR = 0;      // Reset SR
  do_something();
  TIM5->CCR1 += next_time;
}

Der vom PWM ist nicht viel anders.

[W.S. (Gast)]

AVR-Bastler schrieb im Beitrag #4719993:
> ietet eine der STM32-Familien den besseren/leichteren Einstieg?
> Oder umgekehrt: Hat eine der Familien besondere Tücken und Hürden für
> ARM-Anfänger?
> Oder sind die alle "didaktisch" gleich?

Bist du derart fest auf STM32 festgelegt?

Ich sag's mal so: Es kommt eher nicht auf die Cortex-Familien an, 
sondern auf die Qualität der RefManuals. Da ist ST schon ganz 
ordentlich, aber NXP ist bei seinen LPC besser (und bei den zugekauften 
von Freescale deutlich schlechter).

Ansonsten würde ich aus anderen Gründen vorwiegend auf einen Cortex-M4F 
orientieren, also auf einen, der sowohl die DSP-Befehle kennt als auch 
Gleitkomma in Hardware kann. Grund: Diese Chips sind auch nicht 
wesentlich teurer als die anderen aber sie sind deutlich 
leistungsfähiger.

Tücken und Hürden gibt es entweder garnicht oder überall - je nachdem ob 
man gewillt ist, die Manuals der Hersteller und die von ARM wirklich mal 
zu lesen oder eben nicht. Leute, die sich als Überflieger befleißigen 
und vor dem Verstehen der Hardware-Basis schon ein lauffähiges µC-Linux 
oder dergleichen auf ihrem Chip haben wollen, fallen regelmäßig auf die 
Nase.

STM32 und LPC haben eines gemeinsam: einen fest eingebauten Bootlader. 
Das ist ein deutlicher Pluspunkt, auch wenn manche dies nicht verstehen.

W.S.

[Martin (Gast)]

Falls Du auch nur ansatzweise etwas in Richtung Regelung unternehmen 
willst, nimm einen mit Hardware-Fliesskommaunterstützung. 
Festkommarechnerei ist dabei einfach nur mühsam.