[S] Start-Paket für ST ARM M0/M0+/M3 Controller

STM32 sind dieses Jahr fast gar nicht zu bekommen. Vergiss es.

Mein Vorschlag:

https://www.ti.com/tool/EK-TM4C123GXL
https://www.amazon.de/dp/B01HPH24NQ

Das ist TI TIVA. Auf dem Board ist bereits ein Debugger drauf, d.h. für 
den Einstieg brauchst Du sonst gar nicht.

Du brauchst den TI Code Composer Studio:
https://software-dl.ti.com/ccs/esd/documents/ccs_downloads.html

und die Treiberbibliothek TIVAWARE:
https://www.ti.com/tool/SW-TM4C

Bei Bedarf das TI-RTOS:
https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/index.html

fchk

Da finde ich die Nucleo Boards von ST ganz passend. Ein ST-Link 
(Programmieradapter) ist auf dem Board bereits integriert (abtrennbar). 
Der Preis hält sich m.E. auch im Rahmen, siehe z.B.:

https://www.reichelt.de/nucleo-64-arm-cortex-m3-stm32-f1-serie-nucleo-f103rb-p154270.html

Als IDE bietet sich für den Einstieg wohl STM32CubeIDE (kostenlos) an.

Von ST gibt es Nucleo-Boards und Developer-Boards ohne Ende, auch 
lieferbar und meist für kleines Geld.

Neben dem Board und einem USB-Kabel braucht man nur PC und kostenlose 
Software.

Das Nucleo-Board sieht wirklich recht interessant aus. Kann das Ding 
wirklich keinen UART mehr? Das wäre das einzige Manko, was ich beim 
schnellen Überfliegen gesehen habe, ich bastel noch recht gerne mit dem 
UART, auch wenn man irgendwann auf irgendwas SPI-basiertes wechseln 
müssen wird.

Weiß jemand, ob der M3-Programmer vom Nucleo auch mit den M0/M0+ 
klarkommt?

Irgendwelche anderen Controllerfamilien wie das Beispiel TI Tiva möchte 
ich eigentlich nicht. Ich liebäugle schon länger mit dem ARM Cortex, sie 
sind in vielen Projekten eingesetzt, die mich interessieren und 
letztendlich sollte der Chipmangel auch irgendwann überwunden sein.

Ben B. schrieb:
> Weiß jemand, ob der M3-Programmer vom Nucleo auch mit den M0/M0+
> klarkommt?

Der ST-LinkV2 kommt mit so gut wie allen ST µC zurecht, Ausnahme bilden 
hier meine richtig dicke Controller Richtung H7. Ich bin mir nicht 
sicher, ob sie dafür Support nachgereich haben, ich bin auf den V3 
umgestiegen und habe mich daher nicht mehr damit beschäftigt. Auf den 
neueren NUCLEOs sind aber auch ST-LinkV3 mit drauf.

Ben B. schrieb:
> Kann das Ding
> wirklich keinen UART mehr?

Was meinst du damit? Der hat einen UART fix auf dem VCP am ST-Link 
liegen und ansonsten hast du je nach µC noch reichlich auf den 
IO-Headern liegen

Z.B. der STM32G030F6P6 mit dem man wirklich schon eine Menge machen kann 
ist verfügbar bei Mouser. Und TSSOP20 kann man sogar noch ganz gut mit 
Hausmitteln löten.

Aber für die anderen STM32 sieht's wirklich schlecht aus.

Ben B. schrieb:

> Irgendwelche anderen Controllerfamilien wie das Beispiel TI Tiva möchte
> ich eigentlich nicht. Ich liebäugle schon länger mit dem ARM Cortex, sie
> sind in vielen Projekten eingesetzt, die mich interessieren und
> letztendlich sollte der Chipmangel auch irgendwann überwunden sein.

Ähm... TI TIVA ist ein ARM Cortex. Es gibt sie von diversen Herstellern, 
und CPU, Interruptcontroller, Systick und Debuginterface ist immer von 
ARM und damit eine Konstante. Nur die Peripherie ist hersteller- und 
modellspezifisch und auch innerhalb eines Herstellers nicht 
notwendigerweise konstant - auch bei STM32 nicht.

fchk

Gut, dann war das unglücklich ausgedrückt. Ich weiß, daß die Dinger 
"überall" und mit ständig wechselnder Peripherie drin sind, aber ich 
weiß nicht erschöpfend wo überall und in welchen Varianten. Dann muß ich 
schreiben, daß ich (zumindest vorerst) gerne bei der STM32 Produktlinie 
bleiben würde und ich muß auch noch fragen, ob mich jemand über die 
gröbsten Fallstricke schlau machen kann, die man beim Neubeginn mit 
diesen Controllern hat.

Ben B. schrieb:
> Gut, dann war das unglücklich ausgedrückt. Ich weiß, daß die Dinger
> "überall" und mit ständig wechselnder Peripherie drin sind, aber ich
> weiß nicht erschöpfend wo überall und in welchen Varianten. Dann muß ich
> schreiben, daß ich (zumindest vorerst) gerne bei der STM32 Produktlinie
> bleiben würde und ich muß auch noch fragen, ob mich jemand über die
> gröbsten Fallstricke schlau machen kann, die man beim Neubeginn mit
> diesen Controllern hat.

Wenn Du ein fertiges Eval-Board nimmst hast Du eigentlich keine großen 
Fallstricke. Mit CUBE (wenn Du es denn benutzt) und der HAL hast Du 
relativ schnell Erfolge.

Wichtig ist die korrekte Initialisierung des Takteinheit, so dass Dein 
Controller mit der gewünschten Frequenz läuft. Und dass Du jeweils die 
benötigte Peripherie auch aktivierst. Grundsätzlich ist auf den STM32 
Controllern nach einem Kaltstart erst einmal jegliche Peripherie 
deaktiviert.

Wenn Du selbst etwas auf einem Breadboard aufbaust, schaue Dir am besten 
das "Getting Started" zu dem jeweiligen Controller an, da ist die 
Basisbeschaltung angegeben.

Markus M. schrieb:
> Wichtig ist die korrekte Initialisierung des Takteinheit, so dass Dein
> Controller mit der gewünschten Frequenz läuft.

Allerdings muss man sich zu Anfang überhaupt nicht darum kümmern. 
Praktisch alle STM32 starten mit einem internen Oszillator mit 2 bis 16 
MHz. Damit sie zum Strom sparen langsamer laufen, muss nur ein einziges 
Register programmiert werden.

Nur wer einen ganz bestimmten CPU-Takt braucht, muss sich mit den 
Feinheiten beschäftigen. Wobei das auch nicht so oft nötig ist wie bei 
8-Bit CPUs. Die STM32-UARTs z.B. funktionieren mit jeder Taktfrequenz.

> Mit CUBE (wenn Du es denn benutzt) und der HAL hast Du
> relativ schnell Erfolge.

Ben B. schrieb:
> Ich liebe eigentlich die Assembler-Programmierung

Assembler-Programmier brauchen kein HAL. Und CubeMX auch nur, um die 
Pin-Funktionen zu sortieren, also für eigene Schaltungen. Na gut, auch 
noch für die Verbindung PC <-> Nucleo.

Assembler und Compiler gibt es hier:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/downloads

und hier die Header Dateien mit den Hardware-Definitionen:
https://github.com/STMicroelectronics/STM32Cube_MCU_Overall_Offer