Hallo ich bin noch ein totaler Anfänger was das programmieren von Mikrocontrollern angeht und versuche seit 2 Wochen das einfache "BLINKY"-Projekt zulaufen zu kriegen. Hierfür habe ich mir eine Anleitung geholt, von: http://bartteunissen.com/blog/programming-and-debugging-a-stm32f0-discovery-with-eclipse/ Jedoch habe ich das Projekt nicht zum laufen bekommen, da zum einem die Bibliotheken sich nicht einbinden lassen wollten trotz und ständig die Fehlermeldung: make: *** [Tuer.elf] Fehler 1 kommt. Meine Frage jetzt, ob jemand zufällig ein ganz banales Projekt hat das unter Eclipse funktioniert, an dem ich in main.c paar Ein- und Ausgänge des STM32F051R8T6 (STM32F0DISCOVERY-BORDS) belegen und beschalten kann und nicht die ganze Zeit am suchen bin warum das ganze Gedöns drumherum mir ein Strichdurch die Rechnung macht. Das wichtigste währe für mich, das ich endlich meine erste Erfolge mit dem Bord verzeichnen kann. Von der verwendeten SW hab ich mich an die Anleitung gehalten. MfG Levia Thany
:
Verschoben durch User
Achja unter einen der häufigsten fehlermeldungen die ich hatte war das er uint32 nicht erkennen konnte trotz der vorhanden bibiothek "stdint.h"
Levia T. schrieb: > Meine Frage jetzt, ob jemand zufällig ein ganz banales Projekt hat das > unter Eclipse funktioniert, an dem ich in main.c paar Ein- und Ausgänge > des STM32F051R8T6 (STM32F0DISCOVERY-BORDS) belegen und beschalten kann > und nicht die ganze Zeit am suchen bin warum das ganze Gedöns drumherum > mir ein Strichdurch die Rechnung macht. Das ist eigentlich der allerfalscheste Weg, den man einschlagen kann. Zu allererst: Wenn du partout eine IDE wie Eclipse (zu deutsch: Verdüsterung..) benutzen willst, dann mußt du dich eben auch zu allererst mit den 1000 Befindlichkeiten so einer aufgeblasenen IDE befassen, bevor du überhaupt dazu kommst, dich mit den eigentlichen Übersetzungswerkzeugen (Compiler, Assembler, Linker usw.) zu befassen. Und erst wenn du beides hingekriegt hast, kommst du zu deinem eigentlichen Ziel, dich mit dem Mikrocontroller zu befassen. Dabei wirst du feststellen, daß du deinen tollen Code ja auch in den Flash des Controllers bringen mußt, also mußt du dich auch noch mit Programmier- (Brenn-) Utilities befassen. Bei so einem fertigen Evalboard ist zumeist ein JTAG-Brenner mit drauf, aber für den gibt es wiederum selten ein handliches Standalone-Brenn-Programm, also mußt du nochmal Kehrt machen und dich mit der Brenn-Unterstützung der IDE befassen, bevor du zu deinem eigentlichen Chip kommst. Jetzt bist du Anfänger und glaubst, daß eine IDE dir den Weg erleichtern würde - und du bist damit angeschmiert, denn das Gegenteil ist der Fall, wie man aus deinen Zeilen ersehen kann. Ich weiß nicht, ob ich dir überhaupt einen Rat geben kann, der dich nicht sofort überfordert. Aber ich würde völlig anders herangehen: erstens das RefManual des Chips lesen oder wenigstens überfliegen, um einen Begriff davon zu bekomme, was da wie abgeht und wie man den Chip überhaupt konfiguriert. Dann würde ich mich um ein Headerfile für dessen Hardware-Register bemühen oder mir ein solches aus dem RefMan selber zusammenstellen. Jaja, das übt! Dann würde ich mir eine Toolchain aufsetzen und üben, bis ich selbige per Batchdatei (oder für Makefans eben per Makefile) fehlerfrei aufrufen kann und mit einem simpelst gehaltenen main tatsächlich ein Hexfile bekomme. Dann versuchen, eben dieses Hexfile in den Chip zu bekommen. Wenn das alles soweit steht, beginnt der eigentliche Anfang. ...hmm denkst du jetzt, da kommt ja weder eine IDE noch der Debugger vor. - tja, eben. Was man viel eher als nen Debugger braucht, ist ein billiges Oszilloskop und ne serielle Schnittstelle am PC und am µC. Der Glaube, daß der Debugger und ein vorgekautes Projekt das eigene Einarbeiten und Denken ersetzen oder wenigstens erleichtern könnte, ist ein Fehlglaube. Sowas klingt wie der Ruf nach dem Schlaraffenland. Aber das gibt es nicht. W.S.
Levia T. schrieb: > Achja unter einen der häufigsten fehlermeldungen die ich hatte war das > er uint32 nicht erkennen konnte trotz der vorhanden bibiothek "stdint.h" Kann er nicht kennen, der standard Typ heisst "uint32_t". Levia T. schrieb: > Jedoch habe ich das Projekt nicht zum laufen bekommen, da zum einem die > Bibliotheken sich nicht einbinden lassen wollte Ich vermisse hier eine aussagekräftige Fehlermeldung... Ohne die Libs für die Peripherials ist man bei STM32 aufgeschmissen, denn Du brauchst ja z.B. den Startup Code mit der Vector Table. Ach ja: Die Anleitung ist von 2013, da hat sich sicherlich auch einiges in der beteiligten Software getan.
Jim M. schrieb: > Ohne die Libs für die Peripherials ist man bei STM32 aufgeschmissen, Eigentlich nicht, es gibt ja das Datenblatt.
Nop schrieb: > Jim M. schrieb: >> Ohne die Libs für die Peripherials ist man bei STM32 aufgeschmissen, > > Eigentlich nicht, es gibt ja das Datenblatt. Da steht nicht drin wie der C Startup auszusehen hat. Der ist vom verwendeten Compiler (und dessen LibC) abhängig. Ich verwende hier selber Eclipse, das ist als Anfänger aber nicht "mal eben" aufgesetzt. Man kann da verdammt viel falsch machen. Das fängt übrigens bei Leerzeichen im Pfad (zum Compiler,Libs, Projekt) an, die bringen da oft was durcheinander - und in Windoof sind die teilweise Vorgabe des Systems.
Ich habe mir die Bibliotheken über den CubeMX erzeugen lassen. @Jim Mega Wenn du ebenfalls Eclipse benutzt. Vielleicht hast du sonst noch paar Tipps für mich?
:
Bearbeitet durch User
Levia T. schrieb: > Wie würdest du beginnen wen ein IDE der falsche Weg ist? Hab ich das nicht bereits umrissen? Also nochmal das Ganze: 1. du solltest einen Texteditor haben, mit dem du umgehen kannst. Notfalls Notepad bei Windows. (Falls du Windows nicht benutzt, dann such dir was Passendes für dein OS) 2. du solltest eine funktionierende Toolchain haben. Ich benutze den Keil. Den GCC habe ich auch mal benutzt, siehe Lernbetty hier im Forum (bei Bedarf Forumsuche benutzen). Bei der Lernbetty kannst du auch sehen, wie z.B. Quellcode für dessen Arm-Assembler geschrieben werden muß, damit dieses Teil ihn versteht, oder wie man den GCC per Batchdatei aufruft. Aber für mein Gefühl ist der GCC eklig und hakelig. Deshalb rate ich dir zumindest für den Anfang zum Keil. Der ist frei bis 32 K benutzbar und das reicht ganz schön weit, wenn man sich nicht oberdepp anstellt. 3. du solltest dir ein Programmiergeschirre zulegen. Für die STM32Fxxx kann man das Programmieren per eingebautem Bootlader über UART1 erledigen. Das kostet nix und reicht erstmal völlig aus, um den Maschinencode in den Flash zu bekommen. Ein passendes Programm dazu findest du ebenfalls hier im Forum bei Projekte+Code. Falls du jedoch zuviel Geld besitzt, dann leg dir einen J-Link-Edu zu. Mittlerweile gibt es bei der Seggerschen Software dazu ein JFlash-Lite, womit man den Code in den Chip kriegt. Allen anderen Kram wie ULink1 und 2, STLink, FTDI via OpenOCD und so weiter kannst du getrost links liegen lassen, es ist alles Müll, mit dem man sich bloß herumärgert. 4. du solltest einen kleinen Grundstock an Quellen haben, mit deren Hilfe du so einigermaßen flott bei einem neuen Projekt zu Potte kommst. Ich hänge dir mal eine kleine Auswahl hier dran. ABER: das ist alles kein Zeugs für gedankenloses copy&paste, sondern du mußt einiges dir zuvor einrichten. Dazu zählen der konkrete Startupcode, der projektspezifische Code in config.c, die beiden Kommandozeilen-Extensionen (*.xcl), der in den Vektoren anzupassende Code in serial.c und usb.c sowie die Erweiterung von cmd.c um Kommandos, die du haben willst sowie main.c - das Vorliegende hab ich für einen STM32F302 eingerichtet und dein STM32F0xx ist eben kein M4. Also geh auch STM32F302xB.h anhand des RefManuals durch, da werden sich einige Kleinigkeiten ändern, aber im Großen und Ganzen findest du bei deinem µC gewiß einen sehr ähnlichen Satz an HW-Registern unf Peripherie-Cores. So, ich denke, das reicht aus, um dir die Herangehensweise klar zu machen, mit der man mit einem µC flott kommt. W.S.
Jim M. schrieb: > Da steht nicht drin wie der C Startup auszusehen hat. Der ist vom > verwendeten Compiler (und dessen LibC) abhängig. Und hat somit nichts mit den Libs für die Peripherals zu tun.
W.S. schrieb: > 1. du solltest einen Texteditor haben, mit dem du umgehen kannst. > Notfalls Notepad bei Windows. (Falls du Windows nicht benutzt, dann > such dir was Passendes für dein OS) Notepad++ ist ziemlich genial (Windows). > Aber für mein Gefühl ist der GCC eklig und hakelig. Kann ich in keiner Weise bestätigen. Ist doch alles dokumentiert, und es gibt haufenweise Beispiele. Ich hatte beispielsweise kein Problem, vorhandene Linkerscripte anzupassen und so abzuändern, daß z.B. der Stack ins core coupled memory reingelinkt wurde. Zudem gibt's GCC, anders als Keil, plattformübergreifend, und zwar in beiderlei Sinn. Man kann GCC auf so ziemlich jeder verbreiteten Plattform laufen lassen, und er kann für so ziemlich jede verbreitete Plattform Code erzeugen. Und er hat, anders als Keil, die ziemlich genialen Sanitiser-Features, mit dem man bei einer vernünftigen Schichtenarchitektur jedenfalls den Applikationsteil auf einem Linuxrechner durchprüfen kann. Was bei GCC ein gewisser Haken ist, das ist die clib, die nunmal nicht für embedded entwickelt wurde. Es gibt die newlib und die nanolib, mit denen ist es nicht mehr soo schlimm, aber sowohl Code- als auch RAM-Größe sind damit deutlich höher als bei Keil. Wenn man sie denn benutzt, was man normalerweise embedded sowieso nicht braucht. Das reine C-Compilat ist Keil eher überlegen. > Deshalb rate ich dir > zumindest für den Anfang zum Keil. Ein Rat, dem ich widerspreche - wieso sollte man sich einen vendor-lock-in bauen, wenn es nicht notwendig ist? > Allen anderen Kram wie ULink1 und 2, STLink, FTDI > via OpenOCD und so weiter kannst du getrost links liegen lassen, es ist > alles Müll, mit dem man sich bloß herumärgert. Ich hab den ARM-JTAG-Coocox von Olimex für 25 Euro. Geht super. Im Normalfall nutze ich den allerdings nur zum Flashen, obwohl man damit auch debuggen könnte.
Vielen Dank für die Ratschläge. Ich werde mich nun weiter damit beschäftigen und wen fragen auftreten noch mal melden. @W.S. Dir noch mal vielen Dank
Nop schrieb: > Jim M. schrieb: >> Da steht nicht drin wie der C Startup auszusehen hat. Der ist vom >> verwendeten Compiler (und dessen LibC) abhängig. > > Und hat somit nichts mit den Libs für die Peripherals zu tun. Richtig. Denn der ist Teil von CMSIS und gehört nicht zur Standard Peripheral Library oder HAL.
TriHexagon schrieb: > Richtig. Denn der ist Teil von CMSIS und gehört nicht zur Standard > Peripheral Library oder HAL. Halb-Falsch. Es werden zwar von allen möglichen Anbietern diverse Startupcodes geliefert, aber im Grunde gehört ein Startupcode zu einem Projekt oder zumindest zu einem ganz konkreten Chip-Typ und eigentlich NUR zu diesem - und man kann ihn sich so zurechtmachen, daß er für die eigenen Zwecke optimal ist. Niemand ist drauf angewiesen, sowas von CMSIS, ST-Lib, HAL, oder sonstigen Herkünften zu übernehmen. Allerdings ist meine Erfahrung, daß eigentlich alle IDE's es einem so schwer wie möglich machen, seinen eigenen Startupcode zu benutzen. Da wird man mehr auf irgend eine Schiene gedrängelt, als es einem lieb ist. Und das verkompliziert die Dinge merklich, denn fast immer steht im Hintergrund, die Benutzer einer IDE oder einer vom Hersteller gelieferten Software oder Brenn/Debug-HW eben auf den betreffenden Hersteller festzulegen - man sieht dies recht deutlich daran, wie hier die Leute nach Lösungen für STM32Fxyz nachfragen. Nop schrieb: >> Aber für mein Gefühl ist der GCC eklig und hakelig. > > Kann ich in keiner Weise bestätigen. Ist doch alles dokumentiert, und es > gibt haufenweise Beispiele. Sehe ich nicht so. Und dokumentiert ist beileibe nicht wirklich alles. Stattdessen muß man sich oftmals halb tot suchen. Siehe der elendigliche Workaround bei .thumb mit .thumbfunc - aber hier ist nicht der Ort, um das zu vertiefen. Mein Rat zum Keil bleibt bestehen, der funktioniert ohne Verrenkungen, er kann mehr als GCC und macht obendrein auch noch besseren Maschinencode in speed und size. Ich hatte das bei der Lernbetty erschöpfend ausprobiert. Bis 32K ist der Keil auch bastlergeeignet und nur drüberhinaus oder bei inkompatiblem OS muß man sich Gedanken über GCC machen, da der Keil eben ein kommerzielles Produkt ist. Bei einigen Chips - wie dem hier diskutierten STM32F0xx und dem STM32L0xx ist der Keil sogar komplett frei. Ich hab jetzt aber nicht ausprobiert, ob er unter wine läuft. Ansonsten sehe ich keinerlei Grund, mit Bemerkungen wie "vendor-lock-in" ideologische Bedenken zu äußern. W.S.
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.