Hallo, ich habe mir einen STM32F4 Discovery mit dem LCD Bildschirm geholt. Danach habe ich mir das Atollic Studio heruntergeladen und das entsprechende Projekt mit dem passenden Device angelegt. Meine Frage wäre nun folgende: Wie programmiert man das Teil? Welche Dokumentationen benötige ich dafür? Was gibt es als Anfänger zu beachten? MfG
Schon Erfahrung mit µ-controller ? (Arduino, Atmel 8-bit..). Diese STM32 F4 ist nicht so einfach, das hilft wen sie schon C / C++ Kentnisse habe. Eigenlich braucht sie nur ein usb-kabel, eine compiler IDE wie Atollic und die sie konnen anfangen ! Was genau wollen sie erreichen ?
RP6conrad schrieb: > Schon Erfahrung mit µ-controller ? Ja habe ich. Ich habe etwas AVR und PSoC5 Kenntnisse. Ich will halt den Einstieg in die STM Welt schaffen. Gibt es eine Übersicht der Headderfiles, die man in sein Projekt einbinden kann? Dort könnte ich mir mal die ganzen Funktionen anschauen. Ich will noch nichts spezielles machen, einfach nur herum experimentieren. MfG
Kommt drauf an, ob du einen HAL verwenden willst oder direkt auf Registerebene arbeiten willst. Der HAL ist ein Abstrahierungslayer, der es einfacher macht die Hardware zu nutzen und normalerweise von der IDE eingebunden werden kann. Der HAL hat funktionen für alle Peripherals (I2C, SPI,...). Falls du mit dem HAL programmieren möchtest, solltest du dir CubeMX ansehen, das ist eine Software von ST, mit der auf Graphische weise die Peripherals konfiguriert werden. Persönlich nutze ich den HAL nicht, weil ich gerne möglichst Hardwarenahe programmiere und wenn ich die Register schreibe, weiß ich genau was der Code macht. Als Referenz für Code sind das ReferenceManual für den Mikrocontroller (für die Peripherals) sowie das ProgrammingManual (für Core-componenten, z.B. Interrupt-controller). Sonst hilft es oft sich die Sourcen der HAL bzw. StdPeriph library anzusehen wenn etwas nicht so funktioniert wie man möchte.
Beitrag #5532954 wurde von einem Moderator gelöscht.
Das ist der offizielle YouTube-Kanal zu Atollic. Da wird alles von Anfang an erklärt. https://www.youtube.com/channel/UCZ5tf8T8odmacEAOpw68guA
Die Basis Library für alle ARM Controller ist die CMSIS. Mal abgesehen von eine ganz kleinen Menge Funktionen beinhaltet die CMSIS eigentlich nur die Definitionen für die ganzen Register. Da jeder Chip Hersteller as andere um den ARM Kern herum baut, musst du die CMSIS Header Dateien folglich bei den Chip-Herstellern suchen. Bei ST habe ich leider keinen entsprechenden Download gefunden. Aber: In dem "STM32Cube MCU Package for STM32F4 series" Paket ist sie enthalten, und zwar im Unterverzeichnis Drivers/CMSIS. Für den Anfang brauchst du nur die beiden Verzeichnisse "Include" und "Drivers" (das ist der CMSIS Core). Alles andere sind optionale Erweiterungen, die auf dem CMSIS Core aufbauen. Der schwierigere Part ist das Erstellen des Linker Scriptes, des Interrupt-Vektor Tabelle und des Startup-Codes in Assembler. Die System Workbench konnte diese Files automatisch anlegen, wenn man ein "No Firmware" Projekt startete. Das Atollic Studio kann das leider nicht. Ich würde Dir daher raten, lieber die System Workbench zu benutzen. Oder du erzeugst mit Cube MX ein Projekt mit HAL und schmeißt den ganzen HAL Kram wieder raus, so dass nur noch die CMSIS übrig bleibt. Es sei denn, du möchtest die HAL benutzen. Dann bleibt sie natürlich drin. Was die Doku angeht: Du brauchst für den Anfang drei Dokumente: 1) Das Reference Manual der STM32F4 Serie. Es beschreibt die ganzen Periphierie-Einheiten und Register. 2) Das Datenblatt des konkreten STM32Fxxx Chips. Es beschriebt, welche Peripherie (aus dem Reference Maunual) tatsächlich vorhanden ist, die elektrischen Eigenschaften und die Pinbelegung. 3) Das Errata Sheet für deinen STM32Fxxx Chip. Es beschreibt Fehler und empfiehlt Workarounds. Wenn du die Cube HAL Verwendest, brauchst du auch die Dokumentation davon. Aber bevor du dich durch diese tausenden Seiten durcharbeitest, wäre ein kleines Tutorial mit LED Blinker sicher nicht falsch. Falls du erwägst, die HAL zu verwenden, dann bedenke, dass diese ausschließlich für STM32 Controller existiert. Du kannst Code, der die HAL verwendet, nicht leicht auf ARM Controller anderer Hersteller portieren.
Weitere Doku: Application Notes von ST: https://www.st.com/content/st_com/en/support/resources/resource-selector.html?querycriteria=productId=CL1734$$resourceCategory=technical_literature$$resourceType=application_note The Definitive Guide To The ARM Cortex-M3 von Joseph Yiu https://www.eecs.umich.edu/courses/eecs373/labs/refs/M3%20Guide.pdf ARM Cortex M3 Technical Reference Manual von ARM http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337h/DDI0337H_cortex_m3_r2p0_trm.pdf
Ich habe Dir mal mit der System Workbench ein nacktes Projekt für STM32F4xxRB angelegt. Das Atollic Studio kann dieses Projekt öffnen. Dort kannst du die beiden oben genannten CMSIS Verzeichnisse hinzufügen. Die Vorgehensweise ist hier (für STM32F1) beschrieben, müsste bei Dir theoretisch genau so gehen: http://stefanfrings.de/stm32/index.html#cmsis
Mir ist noch etwas eingefallen (kommt so kleckerweise hoch): Wenn du nach Tutorials für das Discovery Board suchst, wirst du warscheinlich auf die Standard Peripheral Library (SPL, StdPeriphLib) stoßen. Die war nämlich damals noch aktuell, als die Discovery Boards neu waren. Halte dich davon fern. Diese Library ist veraltet und wurde schon vor einigen Jahren durch die Cube HAL ersetzt.
Ich verwende Eclipse CDT mit "GNU MCU Eclipse"-Plugin Bei der Projekterstellung kann man seinen STM-Controller auswählen und es wird C-Startup-Code dafür erstellt. (Anders als die Binar-Blobs welche die KEIL-IDE dazu linkt) CMSIS und (leider auch) Cube-HAL werden auch automatisch eingebunden. Schmeiße ich beides danach immer raus, und binde mit dann nur die CMSIS, wie schon oben erwähnt, aus dem CubeMX Archiv manuell ein.
Stefanus F. schrieb: > Noch Fragen oder bist du am Lesen? :-) Ich bin schön am Lesen. Vielen Dank für die vielen Infos. Damit habe ich jetzt nicht gerechnet. Da ist ja eine ganze Menge. @Stefanus Ist das deine Homepage? Wenn ja, hast du eine Menge Arbeit reingesteckt. http://stefanfrings.de/stm32/index.html#cmsis Danke für den Link :) MfG
Stefanus F. schrieb: > Der schwierigere Part ist das Erstellen des Linker Scriptes, des > Interrupt-Vektor Tabelle und des Startup-Codes in Assembler. Es ist absolut unnötig den Startup-Code in Assembler zu schreiben. Auch wenn man das häufig antrifft, vor allem wenn es die IDEs wie Keil, Segger und Rowley mitbringen. Bei Atollic weiss ich es nicht. Aber ich will hier keine Unruhe stiften, gleich kommen wieder 20 Leute die behaupten man muss vom Startup nichts verstehen. Ist ja bei PIC und AVR schließlich auch so....
Wenn es dein Ziel ist, die Interna der MPU mit all ihren schmutzigen Details genau zu verstehen und Zeit keine Rolle spielt, mach es wie Stefan es beschrieben hat. Wenn du eine konkrete Anwendung realisieren willst, und auch in vertretbarer Zeit Erfolgserlebnisse haben willst, nutz CubeMX und HAL! Vor allem, wenn du dich nicht auf eine MCU-Familie (STM32F1xx, STM32F4xx usw.) beschränken, und das Rad jedes mal neu erfinden willst, nutz CubeMX! Code, den du damit einmal geschrieben hast, kann man in den meisten Fällen nahezu 1:1 für alle Familienmitglieder nutzen. Und laß dich von den leuten, die hier so vehement davon abraten nicht verrückt machen! Die selben Leute schreiben meist im Nachsatz, daß sie es "kurz" damit versucht haben, und nicht klar gekommen sind... -was der Bauer nicht kennt frisst er nicht- Du fängst eh bei Null an, und da wird dir CubeMX schneller zum Erfolgserlebnis verhelfen. Dann ist man auch wesentlich motivierter, sich mit den zahllosen Details zu beschäftigen, denn am Studium des umfangreichen Referenz-Manual führt auch mit CubeMX kein Weg vorbei. Und nein! Du musst keinen Startup-Code in Assembler, keine Interrupt-Vector-Tabellen, und auch kein Linker-Script von Hand codieren, so lange du nicht etwas sehr spezielles (eigenen Bootloader z.B.) damit machen willst. Den Job erledigt CubeMX für dich. Mit diesen Tutorials hast du nach max. 2h deine erste blinkende LED, und die grundlegenden Dinge gelernt, um mit deinem Projekt starten zu können: https://www.youtube.com/channel/UCZ5tf8T8odmacEAOpw68guA
:
Bearbeitet durch User
Harry L. schrieb: > Wenn du eine konkrete Anwendung realisieren willst, und auch in > vertretbarer Zeit Erfolgserlebnisse haben willst, nutz CubeMX und HAL! > .... langer Text Genau. Und wenn dann die LED das erste mal blinkt kann man sich stolz auf die Schulter klopfen und sich freuen die Welt der µCs zu beherrschen. Am besten gleich bei einer Zeitarbeitsfirma anheuern und Airbagsteuerungen entwickeln... Ich frage mich wozu jemand einen STM32F4 einsetzen will ohne auch nur annähernd zu wissen was da wie abläuft. Das ist so als wenn ein angehender Architekt eine Autobahnbrücke in Genua konstruieren will, und sich auch dazu in der Lage fühlt, weil er schon mal 3 Schaufeln Sand, eine Schaufel Zement und etwas Wasser zu sowas ähnlichen wie Beton zusammen gerührt hat. Beim ersten Problem kommen dann hier die dämlichsten Fragen und man beschwert sich auch noch über die, die dann genervte Kommentare dazu ablassen. Es ist leider nicht wie auf dem PC wo es ein Betriebssystem gibt, dass einem im gewissen Umfang davon befreit den Unterbau zu verstehen. Das kann die HAL aber bei weiten nicht leisten, zumal sie auch noch absolut schlecht dokumentiert ist. Ohne das Manual vom Controller versteht man die HAL auch bloss nicht. Im Nachbarthread beschert sich gerade einer, dass der die Klammerung in C nicht versteht und es doch so abartig kompliziert ist. Aber das scheint jetzt die Generation zu sein, die ein Leben lang als Prinz oder Prinzessin behandelt wurden, keinerlei Schranken kennen und glauben sie sind zu allem fähig.
Die STM32 lassen sich alle über SWD programmieren. Die größeren auch über JTAG. Ich würde SWD nehmen. Jetzt brauchst du noch eine Programmier-Software, die kommt mit der Entwicklungsumgebung. Dieser Part ist relativ entfach. Wenn es dir nicht nur ums programmieren geht, sondern auch noch ums entwickeln, wird es etwas komplizierter.
Wenn man tatsächlich verstehen will, wie der µC auf Registerebene funktioniert und den vielleicht auch noch mit Assembler programmieren will (Fängt man nicht so an? Haben wir zumindest gemacht), dann rate ich davon ab, mit den STMs anzufangen. Für die empfehle ich klar die HAL. Wenn man tiefer gehen will, kann man ja immer noch den Source dafür anguggen oder auch über die LL-APIs gehen.
Dein Board hat den Programmer schon mit drauf (SWD). Musst du an den richtigen USB anstecken, den ST-Treiber installieren lassen und fertig ist die Sache. Eventuell noch Brücken richtig stecken, das wars dann. Du hast dann einen vollwertigen Debugger. Der auch - mittels Stiftleiste - für deine eigenen Platinen taugt. Für ALLE Platinen mit STM32. Und das für rund 10€. Das ist DAS Killerfeatuere der STM32 für Bastler, und das sage ich als überzeugter PIC-Verwender.
Harry L. schrieb: > Vor allem, wenn du dich nicht auf eine MCU-Familie (STM32F1xx, STM32F4xx > usw.) beschränken, und das Rad jedes mal neu erfinden willst, nutz > CubeMX! > > Code, den du damit einmal geschrieben hast, kann man in den meisten > Fällen nahezu 1:1 für alle Familienmitglieder nutzen. Das gleiche gilt auch für Code auf Register-level. Da die Peripherals zwischen den Familien ziemlich gleich sind, zumindest die vorhandenen. Aber ich will CubeMX hier nicht schlecht reden, ich persönlich verwende es nicht, aber das liegt hauptsächlich daran, dass ich von AVR gekommen bin und dort auch immer direkt auf Register level gearbeitet habe. Die startup files lasse ich mir zwar auch immer von SystemWorkbench erstellen, den HAL schmeiße ich aber raus. Noch ein Tipp, falls plötzlich die Programmgröße einen riesen Sprung macht, verwende mit -specs=nano.specs in den linker flags die newlib-nano. Die braucht deutlich weniger flash als die vollständige newlib. STM32 kann man auch ohne Probleme in c++ mit der standard template library (vector, array, usw.) verwenden. Nur die interrupts müssen so als extern "C" deklariert werden.
Die Nucleos haben nicht nur die Debughardware drauf, sie melden sich beim USB anstecken auch als Massenspeicher an. Da ist üblicherweise ein Link zu https://os.mbed.com/ drauf und man kann ohne etwas zu installieren mit einem Online Compiler loslegen. Das fertige .bin wird heruntergeladen und auf das USB Laufwerk kopiert, fertig. Auf der Hardwareseite zu den Boards https://os.mbed.com/platforms/ ist für die Nucleos auch ein Video Tutorial zu finden. Sehe gerade es ging um ein Discovery, aber auch die sind grösstenteils mbed enabled.
STM = (S)tudent (T)rifft (M)ikrocontroller schrieb: > Ich habe etwas AVR und PSoC5 Kenntnisse. Ich will halt den > Einstieg in die STM Welt schaffen. Setze dir nicht freiwillig so eine Scheuklappe auf. Wenn du tatsächlich Erfahrungen mit den PSOC5 hast - also nicht bloß mal im Psocdesigner (oder wie diese IDE heißt) herumgedaddelt hast - dann hast du eigentlich auch ausreichende Erfahrungen für die ARM-Cortex-Chips. Eigentlich. Was mich stutzig macht ist, daß du hier so eine Frage stellst. So, und was ist deiner Meinung nach der Einstieg in die STM-Welt? ST ist nur einer von mehreren Produzenten von Cortex-Controllern. Und die Chips der Anderen sind zum guten Teil schöner und besser als die STM32. Grund: Bei den STM32 trifft man noch immer einen großen Teil an Peripherie an, die nur 16 bittig ist. Klar, man kommt ja damit zurecht, aber echte 32 Bit Peripherie ist an vielen Stellen einfach angenehmer. Ich will dich hier nicht von den STM32 weglotsen, ich benutze von denen ja auch einige (weil die beim Chinesen so angenehm billig sind). Aber dir sage ich, daß du gut daran tust, auch die anderen Hersteller dir anzuschauen und dich besser NICHT allzu fest an ST anketten zu lassen. Das betrifft vor allem sowas wie Cube, HAL und sowas. Wer sich auf dieses ST-Zeugs einläßt und sich von dem eigentlichen Chip fernhält, hat schon den Fuß an der Kette von ST. Also was brauchst du: - eine Programmiermöglichkeit. So ein ST-Link ist nicht die einzige Wahl, es geht auch per eingebautem Bootlader, aber darüber kanst du nicht debuggen und das scheint mir bei allen Anfängern ein schier unüberwindliches Problem zu sein. - eine Toolchain. Hakelig und an manchen Stellen echt problematisch, dafür aber kostenlos und ohne Codegrößenbegrenzung wäre der GCC. Nicht hakelig und unproblematisch und kostenlos, dafür aber auf 32K Code beschränkt wären der Keil und der IAR. Es gibt wohl noch andere, aber da sollen sich mal deren Benutzer zu Wort melden. - die Dokumentation zum Chip, das Familien-Referenzmanual zum Chip, evtl. noch die CPU-Dokumentation von ARM dazu. Und das will zuvörderst gelesen sein. - das Erlernen, wie du deine Toolchain selber aufrufst, um vom Quellcode zum Hexfile zu kommen. Das war's, alles Andere ist eher fakultativ. W.S.
W.S. schrieb: > Es gibt wohl noch andere, aber da > sollen sich mal deren Benutzer zu Wort melden. Dürfen sich auch die Hersteller zu Wort melden? ;-) Wenn es GCC sein soll dann könnte Embedded Studio eine gute Wahl sein: https://www.segger.com/products/development-tools/embedded-studio/ Genauso einfach zu bedienen wir IAR und Keil aber deutlich günstiger bzw. für nicht kommerziell komplett kostenlos. Man braucht natürlich einen J-Link: https://www.segger.com/products/debug-probes/j-link/ Oder man flasht den onboard ST-Link auf einem Discovey/Nucleo Board um: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
Til S. schrieb: > Oder man flasht den onboard ST-Link auf einem Discovey/Nucleo Board um: Das haben wir doch schon durchgekaut dass die Discovery Boards einen ST-Link v2.0 repräsentieren (und nicht v2.1) und damit nicht "um-flash-bar" sind. Nur auf den Nucleo Boards funktioniert es. Als Mitarbeiter von Segger solltest du dich dieser Correctness schon unterwerfen.
Upp Sala schrieb: > Das haben wir doch schon durchgekaut dass die Discovery Boards > einen ST-Link v2.0 repräsentieren (und nicht v2.1) und damit > nicht "um-flash-bar" sind. Bitte erst mal ausprobieren, bevor Du solche Aussagen rtiffst,. Es klappt nämlich
Angehängte Dateien:
-
IMG_2679.JPG
170 KB
Upp Sala schrieb: > Das haben wir doch schon durchgekaut dass die Discovery Boards > einen ST-Link v2.0 repräsentieren (und nicht v2.1) und damit > nicht "um-flash-bar" sind. Wo hast du diese Weisheit her? Ich habe hier ein stm32f4-discovery welches zum j-link geflasht wurde. Das stm32F334-discovery geht auch.
Upp Sala schrieb: > Das haben wir doch schon durchgekaut dass die Discovery Boards > einen ST-Link v2.0 repräsentieren (und nicht v2.1) und damit > nicht "um-flash-bar" sind. > > Nur auf den Nucleo Boards funktioniert es. > Schau mal bitte hier ganz unten: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ Dort findest du eine Liste von Boards, mit denen das Umflashen funktioniert (bzw. die wir getestet haben, geht wahrscheinlich mit noch mehr Boards). Da sind auch viele Discovery Boards dabei. > Als Mitarbeiter von Segger solltest du dich dieser Correctness > schon unterwerfen. Nö, unterwerfen ist nicht so mein Ding ;-). Aber klar, ich kann mich natürlich auch mal vertun.
Mein Erfahrung als Anfänger zum Thema CubeMX vs. Register-Coden (CMSIS): Mich hat CubeMX, bzw. der erzeugte QuellCode erstmal hauptsächlich verwirrt und mental erschlagen. Ich hab mich dann darauf beschränkt, die Register direkt zu befüllen und auszulesen und mich so Schritt für Schritt an den uC (STM32F411RE nucleo-64) rangetastet. Nachdem ich nun (nach einigen Wochen) so weit gekommen bin, dass ich LEDs blinken lassen, via I2C Sensorwerte einlesen und mittels PWM Servos ansteuern kann, beginne ich ganz langsam zu erahnen, was es mit HAL, bzw. dem von CubeMX erzeugten Code auf sich haben könnte. Bei mir kommt allerdings einschränkend dazu,, dass ich die "fixe Idee" habe, dass ich den uC mit C++ programmieren möchte. Da eignet sich CubeMX eh nicht so recht, weil es nur C-Code zu erzeugen scheint. Ich benutze Eclipse mit dem ARM-MCU-plugin bzw. die ARM-GCC-Toolchain. Das funktioniert aus meiner Sicht unproblematisch.
Wolfgang E. schrieb: > Ich benutze Eclipse mit dem ARM-MCU-plugin bzw. die ARM-GCC-Toolchain. > Das funktioniert aus meiner Sicht unproblematisch. Der generierte Code ist C++-safe und kann problemlos mit eigenen C++-Modulen verlinkt werden. Alle HAL-Header beginnen mit:
1 | #ifdef __cplusplus
|
2 | extern "C" { |
3 | #endif
|
Wolfgang E. schrieb: > Mich hat CubeMX, bzw. der erzeugte QuellCode erstmal hauptsächlich > verwirrt und mental erschlagen. > > Ich hab mich dann darauf beschränkt, die Register direkt zu befüllen und > auszulesen und mich so Schritt für Schritt an den uC (STM32F411RE > nucleo-64) rangetastet. Ja, sure, das ist besonders für Anfänger geeignet. Da kann man so viel bei der Init-Routinen falsch machen bzw. vergessen, dass es einfach lachhaft ist, den Anfängern von CubeMX abzuraten. Irgendwann mal später, wenn man sich mit STM bekannt gemacht hat, kann man von Cube weggehen, aber warum gleich am Anfang ? Lass dir doch von Cube zeigen, was du alles bei der Initialisation machen musst, nachher ein Blick ins DaBla um zu verstehen warum, danach ein ' aha, so geht das also ' usw.
:
Bearbeitet durch User
Marc V. schrieb: > Irgendwann mal später, wenn man sich mit STM bekannt gemacht hat, > kann man von Cube weggehen, aber warum gleich am Anfang ? Ich meide den generierten Code, weil ich ihn noch nicht durchblicke. Er verleitet mich dazu, mal eben schnell etwas hinzusauen bis es irgendwie funktioniert und dann nicht weiter zu lernen. Auch ich befasse mich lieber mit den Registern und dem Referenzhandbuch. Damit fühle ich mich sicherer. Der Zeitaufwand und die Anzahl der Fehlschläge ist für mich kein Hindernis, da es nur ein Hobby ist.
Harry L. schrieb: > Der generierte Code ist C++-safe und kann problemlos mit eigenen > C++-Modulen verlinkt werden. Ja klar. Was ich meinte, ist der Anwendungs-Code, den CubeMX generiert. Das scheint mir C zu sein. D.h. wenn ich das "out of the box" so verwenden möchte, wie es von CubeMX generiert wird, dann muss ich C programmieren (und an den markierten Stellen meinen Code einfügen) und eine der IDEs verwenden, für die CubeMX Code erzeugt. Natürlich kann man theoretisch auch generierte Code-Teile nehmen und in eigenen C++-Code integrieren. Für mich war das aber nicht praktikabel, weil ich zu wenig verstanden hab, was da genau generiert wird und welchen Sinn das alles hat. Wie geschrieben, nachdem ich nun schon Erfahrungen mit meinem eigenen Vorgehen gesammelt hab, beginne ich so langsam zu erahnen, was man sich bei ST eventuell gedacht haben könnte, als man den HAL designed und implementiert hat. Es kommt eben auch immer darauf an, warum man so einen uC programmiert und welches Vorwissen man hat. Ich mach das, um die Innereien eines uC kennen zu lernen und eine Spielwiese für "embedded C++" zu haben. Ich will eben nicht den HAL lernen oder möglichst schell eine LED zum Blinken bringen. Für solche pragmatischen Anforderungen hab ich meinen Brotjob ;-)
Mein Tip: Stell CubeMX so ein, daß für die Funktionen separate .c- und .h-Dateien generiert werden. Das macht die Sache übersichtlicher.
@Marc V. Für mich ist es genau, wie Stafanus F. geschrieben hat. Für mich wird eben umgekehrt ein Schuh draus. Den ganzen Initialisierungkram übernimmt meine IDE. Das macht Eclipse, bzw. das ARM-plugin für mich. Da leg ich fest, dass ich Code für nen STM32F411RE schreiben will und die IDE erledigt den Rest. Alles andere mach ich erst mal lieber selbst. Ich habs ja zuallererst mit CubeMX probiert. Das schien mir erst mal das sinnvollste zu sein. Dann hab ich allerdings Stunden und Tage damit verbracht, das mit meiner Entwicklungsumgebung zu "verheiraten". Ich musste C programmieren wenn ich reibungslos zwischen CubeMX hin- und herwechseln wollte und ich bin in dem erzeugten Code und den verschiedenen Stellen, an denen ich meinen eigenen Code einfügen sollte, ohne dass ich wirklich verstanden hab, was da alles passiert, schlicht untergegangen. Seit ich die Register selber setze und auslese und weiß, was wo passiert, kann ich viel gezielter untersuchen, warum es nicht so läuft, wie ich mir das vorgestellt hab und komm wesentlich schneller zu Erfolgserlebnissen, als das mit CubeMX der Fall war .... auch wenn die CubeMX-Evangelisten mir immer das Gegenteil erzählen ... ;)
Harry L. schrieb: > Mein Tip: > Stell CubeMX so ein, daß für die Funktionen separate .c- und .h-Dateien > generiert werden. > Das macht die Sache übersichtlicher. hab ich gemacht, ist auch tatsächlich übersichtlicher, aber für mich eben nicht übersichtlich genug ...
Man kann sich das leben auch selber schwer machen.... Warum benutzt du nicht Atollic? Das ist auch Eclipse, aber CubeMX-Projekte funktionieren uot-of-the-box.
Harry L. schrieb: > Warum benutzt du nicht Atollic? Mich stört bei dem Programm, dass es beim erzeugen neuer Projekte immer die alte StdPeriphLib einbindet. Ich möchte aber bare-metal Projekte, wo nur der ARM Kern initialisiert wird. Das erledigen normalerweise ein paar wenige Zeilen Assembler Code. Ansonsten ist das Atollic TrueStudio sicher nicht übel.
Stefanus F. schrieb: > Mich stört bei dem Programm, dass es beim erzeugen neuer Projekte immer > die alte StdPeriphLib einbindet. Wie kommst du denn darauf? Das ist Blödsinn! Was eingebunden wird, als Schicht unter HAL ist CMSIS - sonst nichts!
:
Bearbeitet durch User
Harry L. schrieb: > Stefanus F. schrieb: >> Mich stört bei dem Programm, dass es beim erzeugen neuer Projekte >> immer die alte StdPeriphLib einbindet. > Das ist Blödsinn! Helfe mir mal bitte. Welche Bedienfolge erzeugt ein Projekt ohne HAL und ohne StdPeriphLib? Ich will nur CMSIS drin haben (oder gar keine Libraries).
Stefanus F. schrieb: > Helfe mir mal bitte. Welche Bedienfolge erzeugt ein Projekt ohne HAL und > ohne StdPeriphLib? Ich will nur CMSIS drin haben (oder gar keine > Libraries). File->New->C Project->CMSIS C/C++-Project
Harry L. schrieb: > File->New->C Project->CMSIS C/C++-Project Bei "Select Device" ist bei mir die Liste leer. Weiß nicht ob es ein Bug ist...
Christopher J. schrieb: > Harry L. schrieb: >> File->New->C Project->CMSIS C/C++-Project > > Bei "Select Device" ist bei mir die Liste leer. Weiß nicht ob es ein Bug > ist... Ja, und scheinbar nicht der Einzige (zumindest unter Linux) Da wird mir als Target exe angezeigt. Ich muß aber auch gestehen, daß ich das bisher nie genutzt hab, aber evtl. muß man dazu weitere Komponenten installieren.
Die Lösung: File->New->C Project->Embedded C Projekt In den folgenden Dialogen alles abwählen, was man nicht braucht.
HAL bzw. StdPeriphLib kann man bei Atollic nicht abwählen. Das ist schon so wie Stefan sagt. Bei SW4STM32 kann man wählen ob man HAL oder PeriphLib oder nichts von beidem möchte.
Beitrag #5545957 wurde von einem Moderator gelöscht.
Christopher J. schrieb: > HAL bzw. StdPeriphLib kann man bei Atollic nicht abwählen. Das ist schon > so wie Stefan sagt. Bei SW4STM32 kann man wählen ob man HAL oder > PeriphLib oder nichts von beidem möchte. Das stimmt so nicht! Es geht auch ganz Ohne. Die StdPeriph-Header werden zwar vom Template ins Projekt kopiert, aber nicht genutzt. Ausserdem kann man genauso bei 0 starten.
Harry L. schrieb: > Man kann sich das leben auch selber schwer machen.... > > Warum benutzt du nicht Atollic? > Das ist auch Eclipse, aber CubeMX-Projekte funktionieren uot-of-the-box. Weil ich auch noch was anderes mach, als STM32 zu programmieren. Außerdem gibt es Atollic nicht für Mac OSX. Das ist genau ein Punkt, der mich an dem ganzen „Paket“ stört. Ich möchte mir nicht vorschreiben lassen, mit welchem Betriebssystem und welchen Tools ich einen Mikroprozessor programmiere. Ich will mir das selbst aussuchen. Wenn ich Lust hab, dann will ich das auch auf nem Raspberry Pi mit nem vi machen können. Das hat mit „sich das Leben selbst schwer machen“ IMHO nichts zu tun. Auch da wird für mich umgekehrt ein Schuh draus. Schon mittelfristig macht sich das Leben derjenige selber schwer, der sich von den proprietären Produkten einzelner Hersteller abhängig macht. Und abgesehen davon, auch wenn Du es Dir nicht vorstellen kannst: Für mich sind CubeMX und HAL eben gerade nicht einfacher. Für mich ist es kompliziert und verwirrend und brauch deutlich länger, zu dem zu kommen, was ich erreichen will (falls mir das überhaupt gelingt). Warum sollte ich mir das Leben selbst schwer machen und mich wochenlang mit einem undurchsichtigen Wirrwar rumärgern, das mir eine bestimmte Entwicklungsumgebung aufzwingt, wenn ich ohne diesen Hemmschuh innerhalb von ein paar Tagen mit den Tools meiner Wahl zu den gewünschten Ergebnissen komme?
Ich habe gerade ein Minimalprojekt zwangsweise mit StdPeriphLib erstellt. Da hat er aber eine ganze Menge davon auch benutzt, dass müsste ich erst mühsam wieder heraus fummeln. Gefällt mir so nicht, das haben die Leute von der System Workbench schöner gelöst.
Stefanus F. schrieb: > Gefällt mir so nicht, das haben die Leute von der System Workbench > schöner gelöst. Sehe ich auch so. Außerdem finde ich es ein wenig unglücklich, dass bei manchen Serien die StdPeriphLib und bei anderen wiederum HAL genutzt wird. Wenn schon, dann sollen sie doch einfach überall die HAL-Libs reinhauen. An anderer Stelle (z.B. fault-Analyzer) gefällt mir Atollic aber ganz gut.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.