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 ;)
Um auf die Ursprungsfrage nach einer deutschen Einstiegsseite zurück zu kommen: http://joe-c.de/pages/posts/einstieg_mikrocontroller_stm32f103_101.php
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.
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 :-)
Abgesehen von den Webseiten und PDFs: Gibt es eigentlich gute Literatur zu dem Thema - also altmodisch auf Papier in Buchform?
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.
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.