Hallo allerseits Ich möchte in die Welt der STM32 Prozessoren einsteigen. Mir ist klar das es bestimmt schon der 1000enste Beitrag dazu ist, aber es gibt da so viele sachen, dass ich langsam keinen Durchblick mehr habe. Erfahrung in sachen Programmierung und AVR-Prozessoren ist bereits vorhanden. Nun habe ich mal folgendes Entwicklungsboard ins Auge gefasst: http://de.aliexpress.com/item/Development-board-RedDragon407-STM32F4-4-3-TFT-LCD-Module-Optoelectronic-Displays-IC-Cortex-M4/1555755007.html Als nächstet: welches Programmiergerät brauche ich dazu ? reicht dieses: http://de.aliexpress.com/item/Free-shipping-ST-Link-V2-automatic-upgrade-Perfect-support-STM8-STM32-downloader-programmer-simulator/1827010981.html oder braucht es doch so eins: http://de.aliexpress.com/item/ARM-Emulator-supports-ARM7-ARM9-ARM11-Cortex-M3-core-ADS-IAR-STM32-JTAG-interface-Double-buffered/32262558292.html oder doch beide falsch ? Zur Programmierung: Als bevorzugtes System wäre OSX. Als Programmiersprache BASIC oder C. Da gibt es jedoch auch wieder x-1000 verschiedene Software, welche brauche ich nun ? Gibt es nicht einfach 1-einzige Software mit der man programmiert, compiliert und flasht ?
Ich würde dir eher das STM32F4 Discovery Board empfehlen. Da ist schon Programmer und alles mit drin. Oder wenn du was mit Display machen möchtest das STM32F429 Discovery Board. Hat aber nicht so viel Peripherie wie das von dir verlinkte Board. Zur Programmierung mit BASIC kann ich nichts sagen. Programmieren in C geht natürlich. Mit den verschiedenen IDEs bin ich auch nicht so richtig warm geworden. CooCox ist in meinen Augen ziemlich schlecht, da es sehr langsam ist und häufig abstürzt. Fürs erste Projekt um überhaupt erstmal eine LED zum blinken zu kriegen aber hilfreich. Momentan nutze ich einfach einen normalen Texteditor und habe mir ein Makefile geschrieben.
:
Bearbeitet durch User
Ich würde dir das STM32F0 Discovery Board und die Keil IDE empfehlen. Damit hast Du alles was Du brauchst...
Peter schrieb: > und die Keil IDE empfehlen. > Damit hast Du alles was Du brauchst... ...vor allem eine leere Brieftasche :-( Schau dir em::Blocks an. Ist kostenlos und komplett sofort zum Loslegen. http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks http://www.emblocks.org/ http://www.emblocks.org/wiki/tutorials/f401_f429_disco/getting_started
Peter schrieb: > Keil IDE empfehlen sieht sehr gut aus. Peter schrieb: > STM32F0 Discovery Board Das reddragon board mit stm32f4 würde mir jedoch besser passen, da schon alle Peripherie drauf ist. Mir ist klar das ich anfangs auch mit LED blinken beginnen muss, danach möchte ich mich aber früher oder später auch mit dem display, USB und LAN beschäftigen.
> ...vor allem eine leere Brieftasche :-(
Nee - ist für den M0 kostenlos ;)
Peter schrieb: > @?!? > Für die F0 Serie ist Keil kostenlos Aber auch nur für den F0. Wenn man dann mal irgendeinen anderen (größeren) STM32 benutzen will, darf man sich auf eine neue IDE umstellen (oder eben teuer Geld an Keil bezahlen). Wenn ich einmal eine Programmierumgebung nutze, will ich sie auch mit anderen µC des Herstellers nutzen. Das wäre ja so, als wenn ich bei Atmel eine IDE istalliere, damit ich einen Tiny programmieren kann. Wenn ich dann einen größeren AVR benutzen will (ATmega z.B.) muß ich eine andere IDE installieren (und lernen). Allerdings wenn man dann später sowieso mit Keil arbeiten möchte, kann man diesen kostenlosen Einstieg schon nutzen.
?!? schrieb: > Schau dir em::Blocks an. Habe ich mal kurzerhand installiert, gefällt mir sehr gut. und vor allem für alle Prozessoren. besten Dank für den link ! nochmals zurück zum programmieradapter. welchen der beiden brauche ich für das reddragon board ? gehen beide, oder kann auch direkt über einen der microUSB Anschlüsse am board programmiert werden ?
Michael L. schrieb: > nochmals zurück zum programmieradapter. welchen der beiden brauche ich > für das reddragon board ? gehen beide, oder kann auch direkt über einen > der microUSB Anschlüsse am board programmiert werden ? der stlink-clone sollte es tun. aber was ich an diesem board für sehr kritisch für den einstieg halte: du weißt nicht wie gut oder ob überhaupt das teil dokumentiert ist. steht zwar was von dokumentation auf cd dabei, aber gerade sowas ist oft nicht die stärke der chinesen. nachher musst du raten oder mühsam durchklingeln wie das teil intern verdrahtet ist. gerade beim einstieg ist man sich oft nicht sicher ob das problem an seinem unverständnis, falschem code oder einem fehlerhaften board liegt. schlechte doku macht das nicht einfacher... ich würde daher auch lieber zu nem stm32f4discovery raten. da gibts ne vollständige doku dazu und der stlink ist auch gleich mit drauf. und wenn du dann noch irgendwelche peripherie anschliessen möchtest, kannst du das ganz einfach über die pinleisten am rand machen.
Und es gibt die extrem geilen Libs direkt lauffähig auf dem Disco von Uwe :)
Ich schrieb: > Ist der 2. Programmer ein segger Clone? Die drucken sogar das Segger-Logo drauf für unschlagbare €8,94: http://i01.i.aliimg.com/img/pb/353/042/836/836042353_632.jpg ist das dreist. Ob das durch den Zoll geht? Und obs wohl überhaupt funktioniert mit der Segger-Software?
Michael L. schrieb: > http://de.aliexpress.... Ich würde mir keine China-Clones von teuren Markengeräten kaufen, noch dazu mit dreist gefälschten Logos draufgedruckt. Für 50€ bekommst Du von Segger den J-Link EDU. Der einzige Pferdefuß ist daß Du ihn nicht kommerziell verwenden darfst (das kontrolliert zwar keiner, also könntest Du theoretisch bescheißen, aber Du handelst ja eh nicht gewerblich also ist alles OK). Die Software und Hardware von Segger ist erstklassig und Du wirst den Kauf keine Sekunde lang bereuen. Die Unterstützung in Eclipse ist ebenfalls erstklassig, Du bekommst also für 50€ plus Zeit für Installation und Einarbeitung eine komplette professionelle Umgebung: arm-none-eabi-gcc + Eclipse + CDT + gnuarm-Plugin + Segger (50€) + Zeit + Geduld => Sehr gute Lösung + einiges gelernt (unbezahlbar) Viel günstiger wirds kaum noch gehen. Die andere Alternative ist du gehst erstmal die ersten Schritte mit einem der STM32-Demo-Boards (Discovery oder Nucleo), auch hier gilt: gcc + Eclipse + CDT + gnuarm-plugin + Demo-Board + openocd + Zeit + Geduld => Exzellente Umgebung + Wissenserwerb
:
Bearbeitet durch User
Gerd E. schrieb: > du weißt nicht wie gut oder ob überhaupt das teil dokumentiert ist. da hast du völlig recht. für die ersten schritte kaufe ich mir wie vorgeschlagen das stm32f4discovery. kostet ja fast nix. und der Prozessor ist ist auch ein f4, was für meine spätere ziel-anwendung hoffentlich reicht.
Michael L. schrieb: > was für meine spätere ziel-anwendung > hoffentlich reicht Was soll es dennn werden, ein Rasberry "M"?
?!? schrieb: ECLIPSE ist extrem aufwendig in der Einrichtung! > Schau dir em::Blocks an. Ist kostenlos und komplett sofort zum Loslegen. > http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks Aber NICHT mit dieser Anleitung, die schon veraltet ist und so auch nicht funktioniert. Man sollte sich schon einen neuen Button "SDRAM Debug" erzeugen usw. "Das Sorglos-Rundum-Paket" kostet wie überall im Leben auch hier Geld und das nicht zu knapp. Rowley Crossworks ist auch einen Spitzen IDE, die weit mehr bietet als CooCox und EmBlocks nur eben für 150 Euro in der Student Version". CooCox empfehle ich gar nicht, vor allem wegen der Internet Abhängigkeit, Langsamkeit und völlig undurchdachten / abgespeckten IDE V2. 2 Abende Zeit muss man sich nehmen um die EmBlocks zu verstehen, einzurichten und sich das Template zu bauen bzw 3 Stück! Ich lade das extra auch hier nicht als Projektfile hoch, denn die Arbeit muss sich jeder machen so wie sich jedr Jedi-Schüler sein eigenes Lichtschwert bauen muss :-)
Christian J. schrieb: > ECLIPSE ist extrem aufwendig in der Einrichtung! Das ist maßlos übertrieben, Du bist wahrscheinlich voreingenommen. Löse Dich davon. Das Gnuarm-Plugin bündelt alles was man braucht: http://gnuarmeclipse.livius.net/blog/install/ die Installation dieses Rundum-Sorglos-Pakets ist geradlinig und einfach, gut dokumentiert und verläuft ohne irgendwelche Überraschungen.
Angehängte Dateien:
-
Unbenannt.PNG
66 KB
Bernd K. schrieb: > Das ist maßlos übertrieben, Du bist wahrscheinlich voreingenommen. Löse > Dich davon. Noch Fragen? Unter Linux ist das aufwendig, darum habe ich mir notgedrungen Win 7 gekauft, die meisten Tools wie ST-Link V2 und der Flasher sind auch dafür, da STM kein Linux unterstützt. Unter Windows hatte ich bei Exclipse Probleme das Plugin zu installieren, es kamen Fehler vom Repo Server die nicht weg gingen. Schien ein Bug zu sein, stand auch in vielen Foren was drüber. http://myavr.chkronline.de/html_stm32/stm32_eclipse_tut05.html Eclipse ist universal für alles. Andere hier vorgestellte Lösungen sind bereits auf Cortexe eingestellt worden, wie EmBlocks. Leider verwendet EmBlocks sehr veraltete Libraries von CMSIS und StdPeriphLib. Mit der CubeMx Sache habe ich mich noch nicht anfreunden können, da das meiste im Netz auf den StdPeriphLibs basiert. So ist es bei mir: CMSIS + StdPeriphLibs + TIlen Majerle Libs als Middleware. Und schon ist Programmieren ein Spass ohne Ärger :-)
Christian J. schrieb: > Noch Fragen? Unter Linux ist das aufwendig Erstaunlich. Gerade unter Linux sind solche Sachen wie make und die anderen GNU-Tools bereits vorhanden, gcc kommt ebenfalls bequem über den Paketmanager, openocd spricht problemlos mit dem ST-link-v2.1, gerade für die STM32 Boards ist die Einrichtung einer Umgebung unter Linux gefühlt nur halb so Aufwendig wie unter Windows. Ich hab meins angestöpselt, die Software installiert (gnuarm-Plugin und openocd) und alles hat sofort funktioniert (und mit sofort meine ich es hat wirklich sofort funktioniert, nicht erst nach ner halben Stunde rumgebastel sondern augenblicklich!). STM32 ist extrem easy unter Linux und wird dort exzellent unterstützt. Ob das früher anders war weiß ich nicht, aber heute ist es jedanfalls so, vielleicht solltest Du nach all der Zeit mal erneut einen Blick drauf werfen. Andere Hersteller (z.B. Freescale mit ihrem ClosedSDA-Krampf) sind da schon weitaus sperriger.
Bernd K. schrieb: > Ich hab meins angestöpselt, die Software installiert (gnuarm-Plugin und > openocd) und alles hat sofort funktioniert (und mit sofort meine ich es > hat wirklich sofort funktioniert, nicht erst nach ner halben Stunde > rumgebastel sondern augenblicklich!) Ok ;-) Vielleicht war ich damals zu blöd es unter Linux ans Laufen zu bekommen. OpenOcd kannte ich noch nicht, habe mich mit Texane herum geschlagen und noch so einem Flash Tools, was aber nie wirklich funktionierte. Und dann alles in die Ecke gefeuert und nach 2 Bier dann "Kaufe Windows 7" in der Buicht geklickt und den PC damit verunstaltet. Zudem auch der Eprommer Win 7 braucht und kein XP mehr, was nur noch mit H-Kennzeichen zu fahren ist. In 1/2h kriegst du bei EmBlocks jedenfalls nichts hin. Ich habe 3 tage gefrickelt, bis ich genau "MeinTemplate (tm)" hatte, auf dem alle Projekte basieren und mit 1-Klick über ST-CLI flashbar ist. Also Em::Blocks for President!
Christian J. schrieb: > Und dann alles in die Ecke gefeuert und nach 2 Bier dann > "Kaufe Windows 7" in der Buicht geklickt Ich hab gleich am nächsten Tag versucht mein positives STM/OpenOCD/Linux-Erlebnis auf nem Windows7 Rechner zu wiederholen und habe mehr als einen Tag verschwendet um herauszufinden daß es dort im USB-Host-Adapter-Treiber einen Bug gibt der verhindert daß OpenOCD an einer blauen USB-Buchse funktioniert. Als ichs dann endlich umgestöpselt habe hat auch unter Windows alles funktioniert. Was mir an em::blocks nicht gefällt ist daß die es geschafft haben eine cross-Platform IDE zu nehmen, das "Cross-Platform" zu entfernen und Windows-Only draus zu machen. Und dann zusätzlich noch daß ich mich noch nie so recht mit code::blocks anfreunden konnte, mehrmals versucht, immer wieder zu Eclipse zurück, aber das ist wahrscheinlich Geschmackssache. Was die STM32 Cube HAL-Treiber angeht das hab ich probiert: Das ist die reinste Hölle, so einen zutiefst verschwurbelten Krampf hab ich schon lange nicht mehr gesehen! Die Programmierer dort ziehen sich anscheinend die Hosen mit glühenden Beißzangen an, anders kann ich mir das nicht erklären. Mittlerweile verwende ich auf allen ARM Controllern nur noch die jeweils aktuellen CMSIS-Header mit den Registerdefinitionen und arbeite direkt mit den Registern und dem jeweiligen Reference Manual, genau wie zu guten alten AVR-Zeiten, im Vergleich zu meinen ersten Versuchen mit den Libraries empfinde ich das als sehr befreiend, so muss ich nur noch das Reference manual lesen und nicht noch zusätzlich dazu eine mindestens genauso umfangreiche API-Dokumentation. Bei vielen geht die Angst um oder die irrige Vorstellung man könne die Periphgeriegeräte nicht mehr ohne umfangreiche Library beherrschen, aber dem ist nicht so, bei Lichte betrachtet ist es auch nicht viel anders als bei den kleinen 8-Bit Controllern, man hat für jedes Gerät eine Handvoll Register, die sind alle ausführlich dokumentiert und auch nicht wesentlich komplizierter als früher, manchmal sogar einfacher oder logischer aufgebaut als man es erwartet hätte, wenn man von früher noch weiß wie man grundsätzlich so eine Registerdokumentation liest und sowas schonmal gemacht hat dann werden einem alle Konzepte und manchmal sogar die Namen der einzelnen Bits in den Registern irgendwie sehr vertraut vorkommen und gar nicht mehr erschreckend und man kommt erstaunlich gut und schnell voran.
Bernd K. schrieb: > bei Lichte betrachtet ist es auch nicht viel anders > als bei den kleinen 8-Bit Controllern, man hat für jedes Gerät eine > Handvoll Register ??? Was sollte den anders und komplizierter sein? Egal welchen gängigen Controller man nimmt, es ist überall so.
Hiltrud schrieb: > ??? > Was sollte den anders und komplizierter sein? Egal welchen gängigen > Controller man nimmt, es ist überall so. Ja eben. Aber schau Dich doch mal um was teilweise geschrieben wird in den Foren, erst gestern musste ich hier wieder lesen es wäre vollkommen abwegig und unpraktikabel für den professionellen Einsatz das Reference Manual studieren zu müssen! Da greif ich mir doch an den Kopf!
Bernd K. schrieb: > Aber schau Dich doch mal um was teilweise geschrieben wird Ja, da wird ein 6-beiniger mit nur einem Timer, einem Port und einem 1/2 AD-Wandler mit einem 100-Pin Cortex M4 inkl. FPU verglichen. :-(
Michael L. schrieb: > Zur Programmierung: Als bevorzugtes System wäre OSX. Ah ja. Also, was du garantiert brauchen wirst, sind die eigentlichen Tools, also Compiler, Linker, Assembler und deren Libs (für die Interna, die der Compiler benutzt). Und diese Tools mußt du eben für dein bevorzugtes OS besorgen. Geht nicht, gibt's nicht? Dann ist der Wechsel des OS angesagt, sonst kommst du eben NICHT zu Potte. Punkt. Was du überhaupt nicht wirklich brauchst, ist irgend eine IDE. Sowas kann man benutzen, aber brauchen tut man's nicht wirklich. Dann such dir einen Chip aus, der sich möglichst umstandsarm brennen läßt. Die LPC von NXP und die STM von ST haben m.W. alle einen fest eingebauten Bootlader drin, mit dem man sie per serieller Schnittstelle programmieren kann. Das kann ne originale COMx sein, es geht aber genauso gut irgend ein billiger USB-Seriell-Adapter. Wenn du mal bei Ebay suchst, findest du sowas mit direkten TTL-kompatiblen Pins auf der seriellen Seite. Das ist für o.g. Zwecke ideal. Manche (ausgewählten) LPC von NXP haben auch einen USB-Bootlader drin. Das ist eine noch bequemere Art, den Code in den Chip zu kriegen. Und es ist weitgehend OS-unabhängig. Der Chip erscheint als Massenspeicher, wo man seine selbst geschriebene Firmware bloß hinzukopieren braucht. Wenn du hingegen Streß suchst oder debuggen willst, dann mußt du dir nen JTAG/SWD-Adapter anschaffen und die zugehörige Software eben wieder mal für dein OS passend besorgen. Viel Spaß dabei. Also: vergiß die üblichen Eval-Boards erstmal, kümmere dich um das eigentlich Wichtige und sieh dich dann erst nach dem passenden Prozessor um. W.S.
W.S. schrieb: > Wenn du hingegen Streß suchst oder debuggen willst, dann mußt du dir nen > JTAG/SWD-Adapter anschaffen und die zugehörige Software eben wieder mal > für dein OS passend besorgen. Viel Spaß dabei. > > Also: vergiß die üblichen Eval-Boards erstmal, kümmere dich um das > eigentlich Wichtige und sieh dich dann erst nach dem passenden > Prozessor um. Ist mir immer noch nicht klar, warum du davon so felsenfest überzeugt bist, dass Debugger Teufelszeug für Anfänger sind. Gerade die bekannten wie ST-Link V2, Segger J-Link und CMSIS-DAP-kompatible sind sehr gut unterstützt und einfach zu benutzen. Und vor allem herstellerübergreifend nützlich (guck dir mal die Kompatibilitätsliste vom J-Link an). Andererseits braucht man z.B. für den UART-Bootloader meistens eine herstellerspezifische, entsprechende Software, die auf dem OS der Wahl läuft. TL;DR ein STM32 Discovery nutzen ist völlig okay, keine Ahnung was W.S. hier reitet.
W.S. schrieb: > Michael L. schrieb: >> Zur Programmierung: Als bevorzugtes System wäre OSX. Wäre schön, muss aber nicht sein. Auf dem Mac OSX habe ich natürlich auch die allseits bekannte Software "Parallels Desktop" und somit kann ich auch jedes andere OS laufen lasen.... W.S. schrieb: > Dann such dir einen Chip aus, der sich möglichst umstandsarm brennen > läßt. Zurück zum Anfang, einen Prozessor wähle ich nicht nach der IDE die auf einem bestimmten OS läuft aus, sondern ob er gewisse Anforderungen erfüllt. Also Schnittstellen, Leistung, usw. Wenn ich nur ein paar LEDs blinken lassen will, kann ich bei den AVR bleiben. Die STM haben weiter den Vorteil, dass diese weit verbreitet sind, es x-1000 Beispiele und Tutorials gibt. Ob letztendlich die IDE auf Windows, linux oder Mac läuft ist mir egal.
Bernd K. schrieb: > bei Lichte betrachtet ist es auch nicht viel anders > als bei den kleinen 8-Bit Controllern, man hat für jedes Gerät eine > Handvoll Register, die sind alle ausführlich dokumentiert und auch nicht > wesentlich komplizierter als früher, manchmal sogar einfacher oder > logischer aufgebaut als man es erwartet hätte, wenn man von früher noch > weiß wie man grundsätzlich so eine Registerdokumentation liest Ähm, also .... das mit der "Handvoll" musste mir mal erklären. Beim Cortex M4 hat jeder Timer so gefühlt 3 Dutzend Register a 32 Steuerbits, deren Sinn sich nicht unbedingt aus deren Namen ergibt. Und dann muss man ja auch noch die Pins an die Timer anschliessen, Takt versorgen, DMA vielleicht noch und das Ganze artet in ein Ratespiel aus und hundertfaches Neu Flashen um zu gucken ob das Ding funktioniert. Ich denke mir allerdings dass da Typen sitzen, die den ganzen Tag darüber nachdenken, wie sie noch irgendwas Neues in die Dinger quetschen können. Nicht weil es gebraucht wird, sondern weil es keinen Stillstand geben darf denn dann wären sie ja arbeitslos.
OpenOCD ist in Verbindung mit dem ST-Link V2 und einem Discovery Board für "Hochstrom" Anwendungen nicht zu empfehlen. Ich hatte mit diversen Motorsteuerungen, die aus kostengründen nicht galvanisch getrennt wurden, große Probleme mit Verbindungsabbrüchen und ähnlichem. Ein J-Link Segger kam sowohl via SWD, als auch via JTAG damit zurecht.
Christian J. schrieb: > und das Ganze artet in ein Ratespiel aus und > hundertfaches Neu Flashen um zu gucken ob das Ding funktioniert. Aber das wird besser mit der Zeit, sehr schnell sogar. Und bei jedem Peripheriegerät das Du ohne Sauerstoffmaske bezwungen hast kommen am Ende ein paar kleine wiederverwendbare Codeschnipsel raus und Notizen die man sich gemacht hat die einem beim nächsten Projekt 99% dieser Arbeit ersparen werden.
Thread beobachten
Seitenaufteilung abschalten
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.