Hallo, ich muss hier leider mal ein bischen Frust von der Seele schreiben... vielleicht geht es ja jemandem genauso und vielleicht hat jemand meine Phase gerade hinter sich gebracht und kann mit Rat und Tat zur Seite stehen... Arbeite mich gerade in die STMicro Controller STM32F4 ein und wechsele munter zwischen Projektansätzen mit der Cube Software und solchen mit nativem leeren Projekt in der SW4STM32 hin und her... Problem ist dabei irgendwie: Kein einziges Projekt läuft wirklihch ansatzfrei vom Compilieren weg... Dauernd fehlen irgendwelche Projektverzeichnisse oder sie sind falsch eingerichtet, Compilerpfade sind nicht gesetzt und so weiter und so fort. Kein einziges Beispielprojekt läuft ohne Comilerfehler vom Stapel weg... Mache ich irgendetwas grundlegendes falsch? Selbst die durchweg gute Webeite von dem U.Becker weist durchweg veraltete Bibliotheken auf, die nur noch mit HAL-Treibern des Jahres ~2013 arbeiten, neu erzeugte Projekte können mit den Bibliotheken schon garnichts mehr anfangen... Suche ich an den falschen stellen, oder welche Beispiele könnt ihr vielleicht empfehlen?
Ich bin ein konservativer alter Knacker und benutze deswegen Coocox 1.7.7 mit Std.Peri.Lib. Coocox bastelt einem ein recht ansehnliches Projektverzeichnis zusammen, wenn man weiss, was man möchte (also z.B. nur GPIO, oder den ADC, usw.) so das ein Projekt nur ein paar Minuten bis zur ersten Blink LED braucht. Cube ist bestimmt toll, aber für so eine kleine MC Kiste mir persönlich schon zu abstrahiert - das ist ja kein 3D Spiel für Windows, sondern nur ein MC :-P Mit der o.a. IDE lassen sich z.B. auch Uwe B.s Libraries ohne Probleme bauen und benutzen. Das Durcheinander bei den IDE für STM32 ist schon recht ansehnlich, von Keil und Konsorten mal ganz abgesehen - deswegen halte ich mich da auch raus.
:
Bearbeitet durch User
ST schrieb: > Kein einziges Beispielprojekt läuft ohne Comilerfehler vom Stapel weg Das ist bei den LPC ARM deutlich anders hier kommt jedes Eval Board mit 100 Beispielen für Eclipse/GCC und KEIL und IAR die sofort laufen: http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/software-tools/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES
Hallo ST, bisher hatte ich solche Probleme noch nicht. Du hast 2 Möglichkeiten die STD Lib oder die HAL Lib zu nutzen. Beide haben wenn du die komplette bei ST runter lädst einige Beispiele für diverse IDEs enthalten. Ich nutze den IAR zu Hause in der 32k begrenzten Version. Mittlerweile baue ich mir die Projekte selbst zusammen und orientiere mich an den Beispielen aus der Lib. Was bisher auch immer funktioniert hatte war ein Grundprojekt mit dem CubeMx für IAR zu erzeugen, wo je nach tiefe einiges initalisiert wird und gleich funktionierte. Welche IDE nutzt du denn?
ich nutze die SW4STM32 von AC6. Das ist, soweit ich es überblicke, die einzige IDE, die tatsächhlich 100% Freeware ist und offiziell von ST unterstützt wird.
ST schrieb: > Problem ist dabei irgendwie: > Kein einziges Projekt läuft wirklihch ansatzfrei vom Compilieren weg... Schau Dir mal die wordclock24 hier im Forum an. Toll strukturiertes, gut kommentiertes Projekt mit vielen Facetten für STM32 ... und ließ sich nach dem Download sofort problemlos compilieren.
ST schrieb: > ich nutze die SW4STM32 von AC6. Das ist sehr vernünftig. Zusammen mit STM32CubeMX eine gute Sache. Bin auch gerade dabei für ein Nucleo F7 alle Hardware in kleinen Einzelprojekten zu erforschen. LED, Taste, RS232 und selbst Webserver mit CGI und SSI lassen sich in kurzer Zeit bedienen. Wenn man sich an ein paar Grundlagen hält kann man auch später noch einmal CubeMX aufrufen und so beliebig alle kleinen Projekte kombinieren. Code Begrenzung ist nicht das was man dabei will.
Matthias S. schrieb: > Ich bin ein konservativer alter Knacker Gibt ältere. Aber interessant, dass du auch ARM dran bist.?
Vielleicht noch eine kleine Frage zu dieser Antwort:
>Du hast 2 Möglichkeiten die STD Lib oder die HAL Lib zu nutzen.
Ist das eine strikte entweder oder Frage, oder werden die beiden
Librarys auch kombiniert genutzt und worin unterscheiden sie sich?
In beiden Fällen soll doch derselbe Controller programmiert werden,
warum also werden dann zwei unterschiedliche Librarys ins Spiel
gebracht?
mfg
Die HAL ist einfach abstrakter als die STD. Wenn Du mal eine HAL Funktion verfolgst, wirst Du auf die gleichen Befehle stossen. HAL hat einfach nur den Vorteil das man "meist" auch die STM32 Familie wechseln kann ohne gross etwas anzupassen.
ST schrieb: > Kein einziges Beispielprojekt läuft ohne Comilerfehler vom Stapel weg... > > Mache ich irgendetwas grundlegendes falsch? Ja. Jedenfalls mMn. Du tingelst zwischen dem Benutzen diverser mehr oder weniger schlecht vorgekauter Beispiele, aufgebauschter HAL-Libs und anderem Zeugs herum, ohne tatsächlich einen eigenen Plan zu haben, was du tatsächlich tun willst. Beispiele sind allenfalls zum verstehenden Lesen da, aber nicht zum direkten Benutzen. Oftmals sind sie jedoch nicht wirklich verständlich und noch öfter sind sie einfach nur da, um den Leuten irgendwelche verquaasten Libs anzudrehen. Wer nicht gelernt hat, sienen Chip selbst aufzusetzen und sich stattdessen auf Cube oder St-Lib oder CMSIS oder sonstwelchen Strunz einläßt, der ist anschließend mit beiden Ohren dort angenagelt. Gleiches gilt für Leute, die zu doof sind, die zugrunde liegende Hardware und deren Register zu verstehen und direkt zu programmieren oder wenigstens das winzige bissel an ARM-Assembler zu lernen, was man braucht, um sich seinen Startupcode selber aufzusetzen - und die genau deshalb das Großmaul herauskehren "sowas hat man heutzutage ja nicht nötig".."dazu hat man ja die XYZ_InitStructure".."sowas macht doch Cube für mich viel besser" und so weiter. Es ist das Unverständnis, was so spricht. Mein Rat wäre, zu allererst das richtige Benutzen der eigentlichen Tools zu erlernen, also Compiler bis Linker. Wenn du das kannst, dann relativiert sich die Not, den Overhead einer IDE bedienen zu müssen. Als nächstes wäre das Verzichten auf Nachäffen von Beispielen dran. Denk dir deine eigenen Projekte aus und ziehe sie ohne irgendwelche HAL's und dergleichen durch. Nur so wirst du potent mit der Zeit. Nochwas: Ich mache mir für jedes Projekt ein separates Verzeichnis - und dort kommt alles hinein, was man zum Projekt braucht - und zwar plain, also keine weiteren Unterverzeichnisse. Das ergibt Includes ohne Pfad-Getingel und entkoppelt das Projekt vom Rest der Welt. Sowas macht die Sache viel einfacher als irgendwelche verzwickten Verzeichnisstrukturen, zu denen eigentlich alle IDE's neigen. W.S.
ST schrieb: >>Du hast 2 Möglichkeiten die STD Lib oder die HAL Lib zu nutzen. > > Ist das eine strikte entweder oder Frage, oder werden die beiden > Librarys auch kombiniert genutzt und worin unterscheiden sie sich? tertium datur. Man kann auch beide NICHT benutzen. Darin unterscheiden sie sich nicht. W.S.
W.S. schrieb: > Man kann auch beide NICHT benutzen. Man kann sich auch das Leben unnötig schwer machen. Jeder nach seinem Gusto.
Als Entwicklungsumgebung ist jetzt auch Atollic True Studio frei verfügbar. Das funktioniert normalerweise "out of the box". Mit den STM32Cube Treibern (HAL) kann man arbeiten, muss aber nicht. Teilweise macht man sich damit das Leben schwer, manchmal ist es nützlich... Wenn du dir von ST die STM32Cube-Library runter lädst, sind da schon sehr viele fertige Beispiel-Projekte drinnen.
Ich habe mir die Bare Metal Variante von openSTM32 ins Eclipse integriert. Läuft einwandfrei. Am Anfang kann man auswählen ob man STD oder HAL Lib nutzen will. Dann sind bereits alle notwendigen Includes im Projekt vorhanden.
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.