mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit STM32F0xx


Autor: Levia T. (levia_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 Moderator
Autor: Levia T. (levia_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja unter einen der häufigsten fehlermeldungen die ich hatte war das 
er uint32 nicht erkennen konnte trotz der vorhanden bibiothek "stdint.h"

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Levia T. (levia_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@W.S. Wie würdest du beginnen wen ein IDE der falsche Weg ist?

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Ohne die Libs für die Peripherials ist man bei STM32 aufgeschmissen,

Eigentlich nicht, es gibt ja das Datenblatt.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Levia T. (levia_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: W.S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Levia T. (levia_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.