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?
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 :)
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
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.
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.
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.
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.
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" :-) ?
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
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.
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.
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
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
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++.
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.
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.
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 ;)
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
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.
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.
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
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.
1
CPPFLAGS += -fno-rtti
2
CPPFLAGS += -fno-exceptions
C bekam zusätzlich
1
CFLAGS += -std=gnu99
2
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 :-)
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.
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.
