Forum: Mikrocontroller und Digitale Elektronik Webseite für die Einarbeitung STM32 auf Deutsch


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

wie es schon oben Überschrift steht, suche ich eine deutschsprachige 
Webseite, die bei der Einarbeitung in die Cortex-M3 Reihe unterstützt. 
Am liebsten eine, die so ähnlich aufgebaut ist wie die avr-gcc Tutorial 
hier im mikrocontroller.net.

Die Recherche bei G**gle war nicht wirklich erfolgreich. Die meisten 
Webseiten die ich gefunden habe zeigen einige (wenige) Beispielcodes die 
auch teilweise erklärt sind, aber bei Weitem nicht so zusammenhängend 
wie hier im avr-gcc-Tutorial.

Kennt jemand was brauchbares? Oder wäre jemand von den Profis bereit 
eine solche Webseite zu erstellen?

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Würde mich auch mal interessieren...

von Dennis X. (debegr92)


Bewertung
0 lesenswert
nicht lesenswert
abo

würde mich auch interessieren...

von AVerr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also ich habe meinen STM32F4 Discovery jetzt seit 4 Tagen und muss 
sagen, dass der Einstieg auch ohne fremde Tutorials sehr einfach ist.
ST liefert bei der Periph Lib und der USB Lib auch sehr viele Beispiele 
mit.
Wenn man schon vorher etwas mit Controllern ( z.B. AVRs ) zu tun hatte, 
geht der Einstieg sehr schnell :)

Peripherie benutzen läuft ja immer gleich ab ... Clock einschalten, den 
InitStruct der Peripherie benutzen um selbige zu Initialisieren, dann 
noch mittels der Cmd Funktion aktivieren.
Gegebenenfalls noch Interrupts konfigurieren und schon läuft es :)

von Ernst B. (puravida)


Bewertung
0 lesenswert
nicht lesenswert
AVerr schrieb:

> Wenn man schon vorher etwas mit Controllern ( z.B. AVRs ) zu tun hatte,
> geht der Einstieg sehr schnell :)


Danke, das macht Hoffnung! Welche IDE verwendest Du?

Obwohl ich trotzdem an so einer Site interessiert wäre...

LG
Ernst

von AVerr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ernst B. schrieb:
> Welche IDE verwendest Du?

IAR EWARM

Ernst B. schrieb:
> Obwohl ich trotzdem an so einer Site interessiert wäre...

Also das wäre schon ein spannendes Projekt für das Wiki hier,
ein STM32-Tutorial aufzubauen.

von Ernst B. (puravida)


Bewertung
0 lesenswert
nicht lesenswert
AVerr schrieb:
> Ernst B. schrieb:
>> Welche IDE verwendest Du?
>
> IAR EWARM

Ich habe ja überlegt ob ich Atollic Truestudio nehmen soll. Soweit ich 
das bisher überflogen habe ist das noch die uneingeschränkteste 
Gratis-IDE die es für STM32 gibt.

Verwendest du eine Vollversion von IAR?


>
> Ernst B. schrieb:
>> Obwohl ich trotzdem an so einer Site interessiert wäre...
>
> Also das wäre schon ein spannendes Projekt für das Wiki hier,
> ein STM32-Tutorial aufzubauen.

Das habe ich mir vorher auch gedacht wie ich den Thread gelesen habe. So 
ein Tutorial wäre wirklich der Hit.

von AVerr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ernst B. schrieb:
> Ich habe ja überlegt ob ich Atollic Truestudio nehmen soll. Soweit ich
> das bisher überflogen habe ist das noch die uneingeschränkteste
> Gratis-IDE die es für STM32 gibt.
>
> Verwendest du eine Vollversion von IAR?

Die könnte ich mir vermutlich nicht leisten ... im Moment reicht mir die 
Kickstart Edition (32 KB Grenze ) vollkommen.
Sollte ich dennnoch an diese Grenze stoßen, werde ich wohl auf Atollic 
umsteigen.
C++ ist ganz schön, aber man könnte auch ohne leben.

von rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade mit dem STM32VLDiscovery am rummachen. Die CooCox IDE mit 
freiem WinARM ist ganz passabel, obwohl ich C zum Kotzen finde. Will 
halt schon mal die eine oder andere LED zum Blinken bringen, bevor 
mikroE mit den neuen C-, Basic- und Pascal-Compilern Ende Dezember 
rauskommt, die dann hoffentlich auch bald andere als die TI-Sterne 
(Stellaris) unterstützen.

von Roland H. (batchman)


Bewertung
0 lesenswert
nicht lesenswert
Ernst B. schrieb:
> Ich habe ja überlegt ob ich Atollic Truestudio nehmen soll. Soweit ich
> das bisher überflogen habe ist das noch die uneingeschränkteste
> Gratis-IDE die es für STM32 gibt.

Du hast doch kürzlich auch noch ein paar atmegas ins Lager geholt :-), 
da könnte es sinnvoll sein, sich Gedanken zu machen, wie die beiden 
µC-Familien unter einen Hut gebracht werden. Früher oder später will 
auch das Discovery mit nrf funken, und ein paar Bibliotheken, die man in 
beiden Bereichen nutzen will, sammeln sich schnell an.

Deshalb bin ich bei Makefiles geblieben. Ich verwende also Emacs + make 
+ gcc + Flash tool. Sehr selten dann noch den gdb.

Die IDEs sind entweder limitiert (Code size) bzw. teuer, nicht immer 
unter Linux lauffähig oder scheitern an Makefile-Projekten. Hab's jetzt 
2x erfolglos mit Eclipse versucht (den ich ansonsten für Java den ganzen 
Tag verwende und sehr schätze).

AVerr schrieb:
> Die könnte ich mir vermutlich nicht leisten ... im Moment reicht mir die
> Kickstart Edition (32 KB Grenze ) vollkommen.

Das könnte bei reiner Codierung schon knapp werden, aber spätestens wenn 
Du die integrierte Audio-Peripherie mit PCM-Daten füttern willst, dann 
sprengst Du dieses Limit.

AVerr schrieb:
> C++ ist ganz schön, aber man könnte auch ohne leben.

Ich nicht. Wenn's denn schön ist, warum lebst Du dann mit dem "weniger 
schönen" :-) ?

von Ernst B. (puravida)


Bewertung
0 lesenswert
nicht lesenswert
Hi Roland!

Roland H. schrieb:
> Du hast doch kürzlich auch noch ein paar atmegas ins Lager geholt :-),
> da könnte es sinnvoll sein, sich Gedanken zu machen, wie die beiden
> µC-Familien unter einen Hut gebracht werden. Früher oder später will
> auch das Discovery mit nrf funken, und ein paar Bibliotheken, die man in
> beiden Bereichen nutzen will, sammeln sich schnell an.

Ja genau, der bin ich :-))

Das ist ein guter Punkt den Du da ansprichst, daran habe ich noch gar 
nicht gedacht.

>
> Deshalb bin ich bei Makefiles geblieben. Ich verwende also Emacs + make
> + gcc + Flash tool. Sehr selten dann noch den gdb.

Und da haben wir den Salat. Obwohl ich sehr zufrieden bin mit meinen 
Fortschritten die ich mache bin ich doch nur ein Anfänger in dem 
Bereich. Habe ja gerade mal vor 2 Monaten angefangen C zu lernen und 
mich mit µC zu beschäftigen.

Ich bin also noch nicht sehr in die Tiefe vorgedrungen und bin für die 
einfache Funktionalität des AVR-Studios sehr dankbar weil ich mich mit 
Makefiles etc. nur sehr oberflächlich auskenne. So kann ich dem was Du 
da gerade schreibst in Wirklichkeit gar nicht wirklich folgen. gg Hast 
Du bei Deiner Entwicklungsumgebung zum Beispiel dieses Intellisense zur 
Verfügung? Das mag ich schon sehr...

>
> Die IDEs sind entweder limitiert (Code size) bzw. teuer, nicht immer
> unter Linux lauffähig oder scheitern an Makefile-Projekten. Hab's jetzt
> 2x erfolglos mit Eclipse versucht (den ich ansonsten für Java den ganzen
> Tag verwende und sehr schätze).

Ja, die Preise treiben einem die Tränen in die Augen...

LG
Ernst

von Roland H. (batchman)


Bewertung
0 lesenswert
nicht lesenswert
Ernst B. schrieb:
> Und da haben wir den Salat.

Daran bin ich auch noch schuld :-)

Ernst B. schrieb:
> bin ich doch nur ein Anfänger in dem Bereich

Nur keine falsche Bescheidenheit, Du bist der nrf-Pionier hier :-)

> weil ich mich mit Makefiles etc. nur sehr oberflächlich auskenne.
> So kann ich dem was Du
> da gerade schreibst in Wirklichkeit gar nicht wirklich folgen.

In der Tat ist der Einstieg etwas mühselig. Die Frage ist allerdings, 
wann oder wo Du investierst. Entweder hast Du doppelten Sourcecode, 
eine teure IDE (wenn es denn eine gibt, die das gut abbildet) oder Du 
lässt das Discovery im Schrank liegen (theoretisch "investierst" Du dann 
aber in Atmel AVR 8-Bit und musst mit ggf. vorhandenen Beschränkungen 
dieses Lieferanten oder Architektur auskommen).

Ich habe es so organisiert, dass z. B. Hauptprogramme komplett 
HW-neutral sind. Gewisse Bibliothken wie printf, CRC-Berechnung oder 
Ring-Puffer-Verwaltung sind eh HW-unabhängig. Für GPIO, ADC, ... gibt es 
halt eine Schnittstelle und mehrere Implementierungen. Die Makefiles 
führen dies dann zusammen, da die Dateien in einer Verzeichnissstruktur 
verteilt sind. Eclipse wurde damit nicht glücklich.

Ein immer wieder überraschender Effekt: Programme werden dadurch m. E. 
besser: Durch die "erzwungene" Trennung von Logik und HW-Zugriff.

> Hast Du bei Deiner Entwicklungsumgebung zum Beispiel dieses Intellisense
> zur Verfügung?

Nein. Das ist der Punkt, weshalb ich 2x Richtung Eclipse aufgebrochen 
bin. Eclipse ist aber auch ein Stück weit genau daran gescheitert, weil 
es z. B. nie so recht wusste, welche header files relevant sind - die 
jetzt von AVR atmega32 oder atxmega256 oder die von STM32f1 oder von 
STM32f4 ...

Dateinamenergänzung beim habe ich dann wg. der verteilten Dateien 
manuell nachgerüstet, das wurde arg lästig. Der Rest (Funktionsnamen 
etc.) geht dann ganz gut im Kopf, da die HW-spezfischen Dinge eh gut 
"weggekapselt" sind. Es gäbe auch noch diverse Erweiterungen für Emacs, 
habe ich noch nicht probiert, da diese Not nicht besonders groß ist.

von Dennis H. (c-logic)


Bewertung
0 lesenswert
nicht lesenswert
Hat hier schonmal jemand im Wiki mit Cortex-M3 angefangen ?
Ich könnte ja jetzt ne Buchempfehlung dazu aussprechen, aber die ist 
englischsprachig, dafür aber sehr hilfreich.
"The Definitive Guide to the Arm Cortex-M3" von Joseph Yiu.

von Alex B. (tecnologic) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Roland H. schrieb:
> Nein. Das ist der Punkt, weshalb ich 2x Richtung Eclipse aufgebrochen
> bin. Eclipse ist aber auch ein Stück weit genau daran gescheitert, weil
> es z. B. nie so recht wusste, welche header files relevant sind - die
> jetzt von AVR atmega32 oder atxmega256 oder die von STM32f1 oder von
> STM32f4 ...

Moin Zusammen.

Roland dein Konzept mit der HAL ist ja nicht ganz neu und es wird immer 
beliebter. Was mich aber interessiert: Hast du dein Projekt als Makefile 
Projekt importiert. Oder Eclipse ver sucht für das Projekt einzustellen.
Ich exerziere das gerade auch durch mit Eclipse und Makefiles.

Ich bin dafür nach den Guides von ChiBiOS vorgegangen. Das Funktionierte 
mir dem Index nicht richtig da Eclipse für den Index nur in 
Projektpfaden sucht und du den rest im GUI einstellen musst und er das 
allem anschein nach nicht aus der Makefile zieht. Deshalb habe ich 
testweise alle Dateien der Libs und des OS in das Projekt Verzeichnis 
gelegt. Makefile anpassen und schon kann Eclipse damit was anfangen und 
meckert keine Fehler an die nicht da sind. Vllt hilft dir das.

Eigentlich will ich auch Cpp benutzen, bin aber noch der Auffassung das 
ich mir da noch Probleme einhandele, wesshalb ich an so einem STM32 BSP 
in CPP interessiert wäre.

Mfg Tec

von Lapapp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt schon 2x die Toolchain für STM32F1xxx (Eclipse, OpenOCD, 
Gcc, OlimexJtag) unter Linux eingerichtet.
Beides mal ging ein ganzer Nachmittag drauf.
Weil es mit Indigo nicht geht. Mit Helios aber.
Weil OpenOCD die Parameterreihenfolge nicht so nahm wie OpenOCD 4
Weil es mit den proprietären FTDI Treibern ging, mit den freien jedoch 
nicht.
weil weil weil ..

Es gibt leider so viele Varianten. Auch wenn ich die Tutorials hier auf 
mikrocontroller.net (zb: AVR) sehe, dann sind viele Einträge schon 2 
Jahre alt und gerade bei Linux ist alles recht schnelllebig.

Ich wollt das Leid nur klagen. Weiss aber selbst nicht, wie man es 
besser machen kann, außer dass viele User mit unterschiedlichen 
Entwicklungsumgebungen und Boards sich daran beteiligen und das auch 
regelmäßig gepflegt wird.

Lapapp

von Roland H. (batchman)


Bewertung
0 lesenswert
nicht lesenswert
Tec Nologic schrieb:
> Hast du dein Projekt als Makefile
> Projekt importiert.

Ja, das war der Ansatz. Die bestehende Makefile-Struktur wollte ich 
nicht auflösen. Wie in Java mit ant + Exclipse, wollte ich auch für µC 
das klar "sowohl als auch" beibehalten, da beides seine Berechtigung 
hat.

Tec Nologic schrieb:
> Deshalb habe ich
> testweise alle Dateien der Libs und des OS in das Projekt Verzeichnis
> gelegt.

Das ist bei meinem Ansatz nicht praktikabel: Das Projekt ist jeweils nur 
eine Hülle mit einem Verweise auf die HW-neutrale Applikation (als 
Eclipse-Projekt) und weiteren Verweisen auf Libs (ebenfalls 
Eclipse-Projekte). Das Projekt definiert eigentlich nur ein paar 
#defines (hauptsächlich die CPU).

Tec Nologic schrieb:
> und du den rest im GUI einstellen musst

Ja, und es war für mich ein zu großer Aufwand alle Pfade und #defines 
pro CPU in die GUI einzupflegen. Je nach CPU-Auswahl hängen da zig 
andere #defines "dran". Schlussendlich war es in den Makefile 
übersichtlicher, da man in Makefiles auch mal ein "ifeq" verwenden kann, 
was dann viele Einträge in den Eclipse-Tabellen spart.

Ich behaupte aber keinesfalls, dass mein Ansatz ultimativ und perfekt 
ist.

Danke für die Hinweise, habe mir diese für das nächste Mal notiert.

Tec Nologic schrieb:
> Eigentlich will ich auch Cpp benutzen, bin aber noch der Auffassung das
> ich mir da noch Probleme einhandele, wesshalb ich an so einem STM32 BSP
> in CPP interessiert wäre.

Welche Probleme?

Der pragmatische Ansatz: Alles von .c nach .cpp und von .h nach .hpp 
umbenennen. Jede ISR mit /extern "C"/ versehen. Fertig. Fast. Der 
C++-Compiler meldet viel mehr Stellen an, die der C-Compiler 
"durchliess".

Danach habe ich Schritt für Schritt struct mit den zugehörigen 
Funktionen nach class gewandelt, viele const eingefügt, #defines 
nach enum gewandelt (das geht auch mit reinem C, aber mit C++ wird das 
richtig geprüft, und C++ kann damit auch richtig optimieren). Es gibt 
also noch viel reines C im C++-Mäntelchen. Beim jeweilig nächsten 
Anfassen wird's halt umgestellt. Neues nur noch in C++.

von Roland H. (batchman)


Bewertung
0 lesenswert
nicht lesenswert
Lapapp schrieb:
> Ich habe jetzt schon 2x die Toolchain für STM32F1xxx (Eclipse, OpenOCD,
> Gcc, OlimexJtag) unter Linux eingerichtet.
> Beides mal ging ein ganzer Nachmittag drauf.
> Weil es mit Indigo nicht geht. Mit Helios aber.
> Weil OpenOCD die Parameterreihenfolge nicht so nahm wie OpenOCD 4
> Weil es mit den proprietären FTDI Treibern ging, mit den freien jedoch
> nicht.

Das sind aber Eclipse-Probleme, OpenOCD-Probleme und nur im letzen Fall 
ein Linux-(Kernel)-Problem. Bisher hatte ich mit den standardmäßig 
vorhandenen FTDI-Treibern noch nie ein Problem gehabt, was konkret lief 
da nicht?

Im allgemeinen kann ich aber gut nachvollziehen, dass das keinen Spaß 
macht.

Lapapp schrieb:
> Es gibt leider so viele Varianten.

... und bei einem Eclipse-Update kann es auch mal passieren, dass die 
vielen tausend Einstellungen beim Update wiederholt werden wollen.

Aus dem Grund hänge ich sowohl für Java (ant) oder C++ (make) an den 
Konzepten fest, welche in Versionskontrollsysteme einpflegbar sind. Und 
sich sofort auf einem neuen Rechner nach "checkout" kompilieren 
lassen.

Lapapp schrieb:
> Weiss aber selbst nicht, wie man es besser machen kann

Wenn es gelingt, Eclipse "on top" auf make aufzubauen, wie oben 
beschrieben, wäre das eine gute Lösung. Ohne make kettet man sich an die 
IDE.

Die Problematik mit den IDEs ist, dass man die Vorgehensweise eigentlich 
nur mit einem Video gut vermitteln kann. Und mit jeder neuen Version ist 
das hinfällig.

Meine Erfahrung mit make besteht darin, dass Versionssprünge nicht 
spürbar sind. D. h. einmal Zeit investiert, dann hat man Ruhe.

von Der Weise (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kann das sein, dass man das STM32F4 Discovery nicht unter Linux 
programmieren kann, weil man dazu das eingebaute ST-Link/V2 verwenden 
muss, für welchen es keinen Treiber/Programmiersoftware gibt? Man könnte 
einen USB->RAM Bootloader schreiben und für diesen einen Linux Treiber 
basteln, aber Debuggen könnte man damit auch nicht.

von M. K. (avr-frickler) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Der Weise schrieb:
> Kann das sein, dass man das STM32F4 Discovery nicht unter Linux
> programmieren kann, weil man dazu das eingebaute ST-Link/V2 verwenden
> muss, für welchen es keinen Treiber/Programmiersoftware gibt? Man könnte
> einen USB->RAM Bootloader schreiben und für diesen einen Linux Treiber
> basteln, aber Debuggen könnte man damit auch nicht.

Schau mal hier http://code.google.com/p/arm-utilities

Schön das ich hier nicht der einzige bin der gerade ein wenig Probleme 
hat mit dem Einstieg in den STM32.

Kurz zu meinem Vorhaben:
Bisher habe ich nur AVRs programmiert als IDE habe ich dazu CodeBlocks 
und AVR-GCC verwendet. Wenn für PC was gebraucht wurde meist Java mit 
Netbeans.

Mittlerweile werden die Dinge aber komplexer und ich hätte gerne alles 
in einer IDE. So bin ich dann zu Eclipse gekommen hier kann ich 
Java(EE), AVR, STM32 und ggf. Qt in einer IDE verwenden.
Eclipse hat auch noch den Vorteil das ich unabhängig vom Betriebssystem 
bin. Ich arbeite zuhause zwar mit Linux, es kommt aber schon mal vor das 
ich auch was mit zur Arbeit nehme und dort muss das ganze dann unter 
Windows laufen.

AVR-GCC, Qt und JavaEE habe ich bereits mit Eclipse ans laufen gebracht. 
Nun bin ich gerade dabei CodeSourcery einzubinden. Das ist mir heute 
auch schon geglückt.
Allerdings verzweifel ich gerade etwas daran ein simples Beispiel zu 
finden was ich kurz kompilieren kann um sehen ob auch alles klappt.

Das Problem ist das die Projekte meist für Windows sind und sich im 
makefile irgendwelche Pfade verstecken die dann halt nicht für Linux 
eignen. Eclipse verwendet zwar make, änderungen am makefile werden 
allerdings komplett ignoriert habe ich das Gefühl :/

@Roland du scheinst mir mit den makefiles etwas fitter zu sein, evtl 
kannst du mir ja helfen ein kleines Projekt zu machen was sich einfach 
kompilieren lässt? Es muss noch nicht einmal was sinnvolles machen.
Ich kann gleich mal die 2 Projekte raussuchen mit denen ich es gerade 
versuche.

Ein Wiki-Artikel währe echt was feines, ich habe auf meiner 
Benutzerseite Benutzer:Avr-frickler mal angefangen Links und Artikel 
zu STM32 und Linux/Eclipse zusammen zu tragen.
Ich habe noch die nächsten 2 Wochen Urlaub währe doch die Gelegenheit 
mal was sinnvolles anzufangen ;)

von Matthias K. (matthiask)


Bewertung
0 lesenswert
nicht lesenswert
Um auf die Ursprungsfrage nach einer deutschen Einstiegsseite zurück zu 
kommen:

http://joe-c.de/pages/posts/einstieg_mikrocontroller_stm32f103_101.php

von M. K. (avr-frickler) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Der Artikel STM32F10x Standard Peripherals Library ist auch 
lesenswert für den Einstieg.

Hab gesehen dort gibt es einen Link zum Artikel 
STM32 LEDBlinken AtollicTrueStudio der evtl. auch mit Eclipse 
funktionieren sollte, habe ihn bisher nur ignoriert weil da 
AtollicTrueStudio steht.

von Alex B. (tecnologic) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Roland H. schrieb:
> Der pragmatische Ansatz: Alles von .c nach .cpp und von .h nach .hpp
> umbenennen. Jede ISR mit /extern "C"/ versehen. Fertig. Fast. Der
> C++-Compiler meldet viel mehr Stellen an, die der C-Compiler
> "durchliess".
>
> Danach habe ich Schritt für Schritt struct mit den zugehörigen
> Funktionen nach class gewandelt, viele const eingefügt, #defines
> nach enum gewandelt (das geht auch mit reinem C, aber mit C++ wird das
> richtig geprüft, und C++ kann damit auch richtig optimieren). Es gibt
> also noch viel reines C im C++-Mäntelchen. Beim jeweilig nächsten
> Anfassen wird's halt umgestellt. Neues nur noch in C++.

Dieser pragmatische Ansatz war mit bisher anscheind zu pragmatisch :) 
hab ich nicht dran gedacht. Was ich aber mit Problemen meinte war die 
Geschichte mit Exeptions und RTTI. Ich weiß das es da Direktiven für den 
Compiler gibt die das Abschalten. Habs aber noch nie Probiert. Ich denke 
mal mein erstes Projekt für den F4 ist dann mal Opfer für meine ersten 
Cpp ernstgemeinten Versuche auf dem µC. Vllt interessierts wenn ich will 
das Discovery mit USB-HID an Matlab Simulink anbinden. Für Hardware in 
the loop Geschichten.
Wer da Anregungen und Tips für mich hat, nur zu.:)

Das der Cpp Compiler mehr meckert ist mit bewusst und recht so. So macht 
man weniger Fehler.

Mfg Tec

von Roland H. (batchman)


Bewertung
0 lesenswert
nicht lesenswert
Der Weise schrieb:
> Kann das sein, dass man das STM32F4 Discovery nicht unter Linux
> programmieren kann, weil man dazu das eingebaute ST-Link/V2 verwenden
> muss, für welchen es keinen Treiber/Programmiersoftware gibt? Man könnte
> einen USB->RAM Bootloader schreiben und für diesen einen Linux Treiber
> basteln, aber Debuggen könnte man damit auch nicht.

Funktioniert perfekt unter Linux.

M. K. schrieb:
> Schau mal hier http://code.google.com/p/arm-utilities

Die arm-utilities sind m. W. älter, diese habe ich für das alte 
stm32vldiscovery eingesetzt (stlink v1). Hatte zwei arge Bugs.

Für das stm32f4discovery verwende ich:

https://github.com/texane/stlink

welches auch stlinkv2 unterstützt.

von Roland H. (batchman)


Bewertung
0 lesenswert
nicht lesenswert
Tec Nologic schrieb:
> Dieser pragmatische Ansatz war mit bisher anscheind zu pragmatisch :)
> hab ich nicht dran gedacht. Was ich aber mit Problemen meinte war die
> Geschichte mit Exeptions und RTTI. Ich weiß das es da Direktiven für den
> Compiler gibt die das Abschalten.

Jawoll, abschalten.

Tec Nologic schrieb:
> Ich denke
> mal mein erstes Projekt für den F4 ist dann mal Opfer für meine ersten
> Cpp ernstgemeinten Versuche auf dem µC.

Geht auch mit den 2k-Flash-Winzlingen. Warum auch nicht? C++ kann besser 
optimieren als C.
Aber das F4 hat schön viel RAM, so dass man hier auch mit virtuellen 
Funktionen arbeiten kann. Selbst das setze ich momentan nicht ein, um 
mir den Rückweg zu den atmegas nicht zu versperren.

Tec Nologic schrieb:
> Vllt interessierts wenn ich will
> das Discovery mit USB-HID an Matlab Simulink anbinden. Für Hardware in
> the loop Geschichten.

Hört sich gut an, hab's aber leider nicht verstanden :-)

Tec Nologic schrieb:
> Das der Cpp Compiler mehr meckert ist mit bewusst und recht so. So macht
> man weniger Fehler.

Ja, und erst hat meistens Recht.

von Alex B. (tecnologic) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Moin, Roland,

Damit kann ich reale Hardware z.B. Sensoren in meine Simulationen mit 
einbinden. Das Hilft bei der Visulaisierung und optimierung komplexer 
Regelungen.

Weißt du zufällig wo ich die Cpp bezüglichen Einstellungen für den GCC 
nachlesen kann? Ich würde mit gern ein genaueres Bild machen was ich 
Abschalten kann und was ich muss/sollte und was nicht.

MfG

Tec

von Roland H. (batchman)


Bewertung
0 lesenswert
nicht lesenswert
Tec Nologic schrieb:
> Weißt du zufällig wo ich die Cpp bezüglichen Einstellungen für den GCC
> nachlesen kann? Ich würde mit gern ein genaueres Bild machen was ich
> Abschalten kann und was ich muss/sollte und was nicht.
CPPFLAGS += -fno-rtti
CPPFLAGS += -fno-exceptions

C bekam zusätzlich
CFLAGS += -std=gnu99
CFLAGS += -Wstrict-prototypes

aber das ist ja in C++ "all inclusive".

Das sind die einzigen C bzw. C++-spezifischen Schalter. Der Rest ist 
gleich für C und C++.

Quelle? Weiß ich nicht mehr.

Tec Nologic schrieb:
> Was ich aber mit Problemen meinte war die
> Geschichte mit Exeptions und RTTI.

So ein Zufall :-)

von PuraVida (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Abgesehen von den Webseiten und PDFs: Gibt es eigentlich gute Literatur 
zu dem Thema - also altmodisch auf Papier in Buchform?

von Roland H. (batchman)


Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> du scheinst mir mit den makefiles etwas fitter zu sein, evtl
> kannst du mir ja helfen ein kleines Projekt zu machen was sich einfach
> kompilieren lässt? Es muss noch nicht einmal was sinnvolles machen.
> Ich kann gleich mal die 2 Projekte raussuchen mit denen ich es gerade
> versuche.

Will ich gerne machen, wenn sich bitte der eine oder andere Freiwillige 
dahingehend engagiert, hier im Forum eine Wiki-Seite für 
"stm32f4discovery" aufzumachen: Inhalte: Bezugsquellen, Download + 
Installation der Tools von https://github.com/texane/stlink (zum 
Programmieren und gdb-Anbindung) unter Linux, dazu arm-none-eabi-gcc. 
Dann packe ich das Programm dazu (GPIO, UART, Timer für Delay).
Gerne auch ergänzt um eine Vorgehensweise für Windows. Und einer IDE.

Ziel dieser Wiki-Seite: Das Discovery in einer Stunde zum Blinken zu 
bringen.

von M. K. (avr-frickler) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Roland H. schrieb:
> Inhalte: Bezugsquellen, Download +
> Installation der Tools von https://github.com/texane/stlink (zum
> Programmieren und gdb-Anbindung) unter Linux, dazu arm-none-eabi-gcc

Genauso hatte ich mir das gedacht. Als IDE dachte ich an Eclipse denn 
dort habe ich bereits arm-none-eabi-gcc zum laufen gebracht.GDB habe ich 
aber bisher noch nichts gemacht.

Das Beispiel für das AtollicTrueStudio konnte ich bereits mit kleinen 
Anpoassungen mit Eclipse und Codesourcery kompilieren. Allerdings lief 
es auf dem Controller noch nicht. Liegt wahrscheinlich an der Meldung 
das ihm die Adresse für den Reset-Vektor fehlt. :P

Ich werde mal morgen ein Beispiel für den STM32F4 versuchen, ich kann 
dann auch schon mal mit dem Wikiartikel anfangen.

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.