Hi! Ich bin auf der Suche nach einem Einsteiger-Paket in die ARM Cortex Controller. Interessant sind für mich die M0/M0+ und M3, gibt es einen Programmier-Adapter, der diese beherrscht oder braucht man für jede Familie einen eigenen Programmer? Die Controller, auf die ich es im Moment "abgesehen" habe, sind beispielsweise die STM32F100 oder STM32G03, später evtl, auch "dickere" M3. Wenn jemand ein entsprechendes Start-Paket mit Programmer und einer brauchbaren Toolchain abgeben kann, wäre ich sehr an einem Kauf interessiert. Wenn ein paar Hallo-Welt-Beispiele vorhanden sind, wäre das auch klasse. Ich liebe eigentlich die Assembler-Programmierung, aber bei diesen Controllern wäre es möglich, daß C aufgrund ihrer größeren Komplexität gegenüber z.B. AVRs nun wirklich die bessere Wahl ist. Danke!
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
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.