Moin,
ich hab heute mal versucht ein Tutorail zu schreiben zum Thema STM32 und
Em::Blocks, weil diese anscheinende immer beliebter/gefragter werden
hier im Forum. Das ist natürlich erst der Anfang. Wie findet ihr das?
Wünsche, Verbesserungen?
http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks
Moritz
Mhm, geht es hier nur um die IDE oder um das Programmieren.
Bei letzterem würde mich der Aufwand etwas abschrecken, zumal es schon
sehr gute Tutorials gibt:
http://diller-technologies.de/stm32.htmlhttp://eliaselectronics.com/stm32f4-tutorials/
...
Hiermit habe ich es ohne weiteres geschaft (natülich mit den Beispielen
aus der STD lib) innerhalb von 2 Monaten komplett von AVR und PIC auf
STM32 umzusteigen, und auch auf verschiedenen Platformen sowie C und C++
zu programmieren...
Hauptsächlich erstmal um die IDE und die Grundlagen, sprich StdLib, DSP
Lib, und auch die USB Lib. Die "normale Peripherie" wird glaube ich
schon recht häufig thematisiert und sollte für Neueinsteiger nicht so
schwer sein. Außerdem noch so Sachen wie Programm aus dem RAM ausführen
und so. Vllt. auch noch Ethernet. Mal sehn wie schnell das Projekt so
voran geht.
Moritz
PS: Der Aufwand ist gar nicht so groß, wenn man einmal alle Sachen
runtergeladen hat und geordnet hat. Außerdem kann man in der Em::Blocks
IDE auch Projekte als Template speichern. Ich schaffes ohne Problem so
ein Grundgerüst wie im Tutorial in zwei Minuten zusammen zu kopieren.
Natürlich weis ich auch, dass das z.B. mit CooCox deutlich einfacher
ist, aber dort werden nicht alle STM32 Controller unterstützt und der
Code scheint mir immer etwas willkürlich zusammengewürfelt worden zu
sein, aus verschiedenen Projekten, teilweise auch von unterschiedlichen
ARM-Typen (Cortex M3 und M4). Außerdem habe ich noch kein Tutorial für
Em::Blocks und STM32 gefunden.
Moritz
Hallo,
ich bin auch gerade dabei mich in die STM32 Mikrocontroller mit
EM:Blocks einzuarbeiten. Ich finde es super, dass es mal erklärt wird
und ich bin gespannt auf weitere Beispielprojekte wie z.B. Timer, UART,
I2C, ... .
Gruß
Felix
>und ich bin gespannt auf weitere Beispielprojekte wie z.B. Timer, UART,>I2C, ... .
Die findest du in den beiden anderen Links.
Oder hier:
http://mikrocontroller.bplaced.net/wordpress/?page_id=744
Das hat mit der IDE an sich erst mal nichts zu tun.
Moritz M. schrieb:> ich hab heute mal versucht ein Tutorail zu schreiben zum Thema STM32 und> Em::Blocks, weil diese anscheinende immer beliebter/gefragter werden> hier im Forum.
Hallo Moritz
Da hast Du einen klasse Job gemacht. n1 :-)
Em:blocks sieht wirklich nice aus und Dein Tutorial erklärt viele
Details, die ich (auf den ersten Blick) im Tool selber nicht gesehen
hatte.
Eine Frage: Hast Du die Wizards gefunden ? Lt. Website soll man die
Erstellung neuer Projekte ja selbst skriptgesteuert machen können. Ich
habe eben aber nirgends die existieren Buildskripte finden können.
Dann könnte das kopieren Deines "Frameworks" durch den Wizard gemacht
werden.
Viele Grüße
Andreas
Hi vielen Dank für das Tutorial.
ich habe gerade zwei Tage lang versucht die demo-projekte für das
STM32F4Discovery auf Em::Blocks zum laufen zu bekommen, aber leider
immer noch nicht hinbekommen. Dein Tutorial ist da eine sehr angenehme
Alternative für den Einstieg.
Andreas H. schrieb:> Eine Frage: Hast Du die Wizards gefunden ? Lt. Website soll man die> Erstellung neuer Projekte ja selbst skriptgesteuert machen können.
Moin,
Von eigenen script-gesteuerten wizards habe ich nichts gelesen, nur
davon, dass man eigene Projekte als Template speichern kann. Das kommt
auch noch ins Tutorial, ist sehr einfach.
Moritz
Moritz,
bitte weitermachen. Die ARMs sind schon komplexer als AVRs. Ich habe
mich auch fuer EM::Blocks entschieden und erste Sachen zum laufen
gebracht. Allerdings war das ein ziemliches Herumsuchen... Mich wuerden
auch sehr Beispiele zu USB und Ethernet interessieren, da habe ich mich
noch garnicht herangetraut.
Hallo,
Schöner Artikel! Ich finde Em::Blocks auch prima. Gut, dass mal jemand
Werbung dafür macht ;).
Da es ja vornehmlich um die IDE geht:
Ich fand den Wechsel zwischen den Editor-Fenstern gewöhnungsbedürftig.
Bis ich auf die Einstellung "Environment settings/notebook
appearence/use stacked based tab-switching" gestoßen bin.
Beste Grüße
Tom
Hallo Moritz,
erstmal ein großes Lob an dich. Dein Artikel gefällt mir schon sehr gut
und ich finde es gut eine Alternative zu CooCox zu haben. Welche Themen
mich besonders interessieren würden ist die Integration von FPU und DSP.
Also schon mal ein dickes Danke.
Andreas H. schrieb:> Eine Frage: Hast Du die Wizards gefunden ? Lt. Website soll man die> Erstellung neuer Projekte ja selbst skriptgesteuert machen können. Ich> habe eben aber nirgends die existieren Buildskripte finden können.> Dann könnte das kopieren Deines "Frameworks" durch den Wizard gemacht> werden.
Ich hab grade was dazu entdeckt: Im Projekt-Dialog gibt es per Rechts
Klick auf einen Projekt-Typ die Möglichkeiten "Edit this script" und
"Edit global registration script". Aber ich denke ich werde mich damit
erstmal nicht beschäftigen, sondern erklären, wie es mit der "vanilla"
Version von Em::Blocks geht.
Moritz
Hey! Danke schön!
Deinen Artikel hätte ich vor einer Woche gut gebrauchen können.
Habe nämlich die gleiche Arbeit auch gemacht. Mir haben paar russische
Seiten geholfen. Funktioniert echt gut diese IDE. Habe mit codeblocks
gearbeitet und finde es gut. Läuft bei mir sowohl mit stlink als auch
mit jlink. Ist echt eine super Alternative zu coocox, zumal sehr
portabela, also ohne Installation ins System. Kann man gut auf USB-Stick
mitnehmen...
Man sollte entweder allen Komponenten der Struct einen Wert zuweisen
oder die Stuct vorher mit default Werten füllen. Dafür gibt's
x_StructInit.
z.b.
GPIO_InitTypeDef GPIO_InitStructure;
GPIO_StructInit(&GPIO_InitStructure);
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_15;
GPIO_Init(GPIOD, &GPIO_InitStructure);
Erst einmal ein großes DANKE an Moritz. Mein STM32F4 Discoboard wäre
sonst in der hintersten Schublade verstaubt.
Hab ein Problem mit der Taktfrequenz.
Deiner Anleitung zur Umstellung auf 168Mhz bin ich gefolgt.
Danach wollte ich das ganze mal testen und mal sehen, wie schnell der
Pin wackeln kann.
Erstaunen: 2,24MHz.
Kann (darf) nicht sein, wären ja arduinoale Zustände (digitalwrite..).
Also mal den PLL_M Wert verkleinert. Der µC macht bis PLL_M 5 mit, dann
steigt er aus. Funktioniert, zurück auf 8 gestellt.
Dann den HSE_VALUEvon 8 000 000 auf 25MHz gestellt: keine Änderung, egal
welcher Wert drin ist. Zuletzt den HSEWert in die main.c genommen und
dort verändert. Brachte auch nichts.
Ich vermute, dass der Prozessor weiter mit 53,76 MHz läuft.
Demnach braucht die unten stehende Routine 24 Zyklen um PD9 zu toggeln.
Eigentlich hätte ich da weniger Zyklen erwartet, weil das Disassembling
nur 8 Instruktionen pro Zyklus anzeigt.
Fragen:
1) warum bewirkt die Änderung von HSE_VALUE nichts, egal ob in der
main.c oder in der stm32f4xx.h
2) gibt es eine andere Möglichkeit herauszufinden, wie schnell der Takt
taktet.
3) in anderen Tutorien stand mal was davon, dass die Taktfrequenz der
Peripherie eingestellt werden kann, warum musste das hier nicht
erfolgen?
4) braucht ein toggeln wirklich 24 Taktzyklen?
markusDerBastler schrieb:> 1) warum bewirkt die Änderung von HSE_VALUE nichts, egal ob in der> main.c oder in der stm32f4xx.h
wahrscheinlich musst die "SystemInit()" noch aufgerufen werden
> 2) gibt es eine andere Möglichkeit herauszufinden, wie schnell der Takt> taktet.
du kannst entweder die eingestellte Clockfreq auslesen
"RCC_GetClocksFreq()" oder an einem MCO-Pin ausgeben lassen
> 3) in anderen Tutorien stand mal was davon, dass die Taktfrequenz der> Peripherie eingestellt werden kann, warum musste das hier nicht> erfolgen?
wurde wohl vergessen
> 4) braucht ein toggeln wirklich 24 Taktzyklen?
mit deinem Funktionsaufruf schon, mach mal
Uwe B. schrieb:> mit deinem Funktionsaufruf schon, mach mal> GPIOD->ODR ^= GPIO_Pin_9; // toggelt Pin PD9
Ok, danke.
Diese Var. benötigt pro Umschaltvorgang 8 Systicks, also 16 für 0->1 -
1->0.
Ich messe 6,45MHz. Macht ne komische Taktfrequenz von 103,2MHz.(??)Die
Hälfte wäre irgendwie logischer.
Uwe B. schrieb:> wahrscheinlich musst die "SystemInit()" noch aufgerufen werden
gibt Fehlermeldungen, da
1
externvoidSystemInit(void);
2
externvoidSystemCoreClockUpdate(void);
schon aus der system_stm32f4xx.h heraus aufgerufen werden.
Selbst wenn dieseFunktionsaufrufe auskommentiert werden und SystemInit()
aus main.c aufgerufen wird, ändert sich nichts.
Vlt. kann ja der Autor dieses Tutorials mal kurz darüber schauen.
markusDerBastler schrieb:> schon aus der system_stm32f4xx.h heraus aufgerufen werden.> Selbst wenn dieseFunktionsaufrufe auskommentiert werden und SystemInit()> aus main.c aufgerufen wird, ändert sich nichts.
nein in system_stm32f4xx.h werden die Funktionen deklariert.
Der Funktionsaufruf ist in startup_stm32f4xx.S
>#define CORE_SysTickEn() (*((u32*)0xE0001000)) = 0x40000001>#define CORE_SysTickDis() (*((u32*)0xE0001000)) = 0x40000000>#define CORE_GetSysTick() (*((u32*)0xE0001004))
die Adressen die du da definierst haben nichts mir Systick zu tun.
Die Base Addresse von Systick ist 0xE000E010.
Adresse 0xE0001000 ist DWT.
Wie es richtig geht steht u.a. hier:
http://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger
Gerade in einem Einsteiger Tutorial sollte man nichts ungeprüft irgendwo
her kopieren. Das stiftete nur unnötige Verwirrung.
Ich hatte eine SysTick Funktion eingabaut, diese aber hier nicht
kopiert. Die braucht ja selbst auch paat Takte für den Aufruf und zum
Berechnen selber, daher ist sie bezügl. des toggelns nicht sehr
aussagekräftig.
Moin,
hab eben mal weider bisschen am Tutorial rumgebastelt. Es gibt jetzt
auch ein Beispiel, wo der geviertelte Systemtakt am Pin MCO2 / PC9
ausgegeben wird. Bei mir kommen 41.98MHz raus (*4 = 167.92MHz). Könnt
ihr ja mal ausprobieren.
Außerdem hab die zurecht kritisierte Initialisierung des Pin im Kapitel
Standard Peripheral Library korrigiert.
Zur SystemInit();: diese wird eindeutig im Reset_Handler aufgerufen.
(Einzelschritt / startup_stm32f4xx.S)
Das define HSE_VALUE dient nur einigen Funktionen (wie z.B. der
RCC_GetClocksFreq()) die Taktfrequenzen aus den Registern zu BERECHNEN.
Der Werte sollte also ruhig immer mit angepasst werden.
GPIO_ToggleBits() benötig bei mir 39 Takt Zyklen. (siehe Test-Verfahren
bei der FPU.) Die Ausgeben der Taktzyklen dauert anscheinend 9 Takte.
Pin-Togglen in der while-Schleife komme ich auf eine Frequenz von
2.332MHz
Gemessen so:
Vielen Dank für das Tutorial!
Nur eins sollte man evtl. auch noch erwähnen:
Startup File und Linker Script.
Wie oben schon mal erwähnt, wird SystemInit() im Startup File
aufgerufen:
Zeile 212 im *.s:
Das ging aber schnell :-)
Ich finde den Artikel sehr gelungen.
Viele Einsteiger werden sehr froh darüber sein und sich eine Menge Zeit
sparen!
Warum hast Du denn den Artikel nicht schon vor 2 Monaten geschrieben :-)
Moritz M. schrieb:> GPIOC->ODR ^= GPIO_Pin_9;> braucht nur 11 Zyklen> und ergibt 6.99MHz in der while-Schleife.
An dieser Stelle hab ich irgendwie ein komisches Gefühl.
In allen ASM / C Kampftreads tönt es unentwegt, dass der C Compiler den
effektivsten Code generiert..bla bla blub.
Mein Atmega mit 16 MHz lässt den Pin mit 3,6 MHz in ASM toggeln.
Der STM32F4 mit 168 MHz schafft garade mal 7 Mhz?? DAS DOPPELTE???????
Mit hochgelobten supereffektiven C-Code??!!
Sagt dass das nicht wahr ist.
>GPIOC->ODR ^= GPIO_Pin_9;>>braucht nur 11 Zyklen>und ergibt 6.99MHz in der while-Schleife.
Gemessen sind das bei mir aber 11.9MHz -> 84ns.
Und so
while(1)
{
GPIOD->BSRRH = GPIO_Pin_13;
GPIOD->BSRRL = GPIO_Pin_13;
}
Sind es 33MHz.
>Der STM32F4 mit 168 MHz schafft garade mal 7 Mhz?? DAS DOPPELTE???????
Blablaballerballer
Ganz fein! Wenn ich mal diese Dinger nehmen will, werde ich zuerst dein
Tutorial lesen.
Hab es mal überfolgen und es macht einen sinnigen Eindruck.
Vielen Dank für deine Mühen!
15,26 MHz
Warum,weshalb, wieso? Keine Ahnung - noch nicht. Bin gespannt auf das
weitere Tutorium. Trotzdem mach "rumspielen" mit der Hardware vertraut.
Der eine mag eine blinkende LED, der andere mag's etwas flotter;-)
Faster schrieb:> Ein Überblick über die GPIO:> http://hertaville.com/2012/07/28/stm32f0-gpio-tutorial-part-1/>
Danke für den Link. Vlt eine gute Ergänzung.
Noch was.
Könnte man den mit dem Wissen wie Ausgangspins zu setzen und zu löschen
sind, schon ein Character-LCD konfigurieren?
Wäre ja mal eine schöne Übung zum Kennen lernen.
markusDerBastler schrieb:> Warum,weshalb, wieso? Keine Ahnung - noch nicht.
Hier wird das Register nur geschrieben und nicht vorher gelesen,
verknüpft ...
markusDerBastler schrieb:> Warum macht der Compiler das nicht auch so?
Das macht der Compiler doch, wenn du die richtigen Register angibst. ;-)
Mal ne Frage, wahrscheinlich recht einfach zu klären:
Wenn ich ein neues Projekt erstelle, den Haken bei "Ust STD_Periph_Lib"
drinne lasse, dann wird mir V1.0 mit in das Projekt eingebunden.
Ich ändere in der main.c nix, Build ist erfolgreich.
Nun dacht ich mir, ich ersetze im Projektordner die inc und src Dateien
mit denen aus Version 1.3.
Nun geht aber der Build nichtmehr, er meckert in der
SPL\src\stm32f4xx_cryp.c rum.
Wie lös ich das Problem?
Moin,
ich mach das so, dass ich die StdPeriphLib nicht über den Projekt Dialog
einbinde, sondern in das Projekt kopiere. Dann hat man auch gleich die
aktuelle Version (in den alten sind ein paar Bugs drin).
Moritz
Da kommt bei mir der gleiche Fehler:(
Bin so vorgegangen wie es im Wiki steht:
STM32F4xx_StdPeriph_Driver Ordner in meinen Projektordner kopiert.
stm32f4xx_conf.h in den inc Ordner des eben eingefügten Ordners einfügen
includepath auf den inc Ordner in den build options hinzugefügt
USE_STDPERIPH_DRIVER bei #defines eingefügt
die restlichen Dateien außer die jeweils 4 genannten hinzugefügt
Im anhang mal mein Projekt, vielleicht fällt euch was auf bzw. ihr könnt
testen ob der Fehler auch bei euch kommt.
Nach der Anleitung bin ich ja vorgegangen. Ich habe gemerkt, dass die
stm32f4xx_conf.h im Prjektbaum gefehlt hat. Aber nach dem Hinzufügen
ändert sich nichts an dem Fehler. Die "verbotenen" Dateien sind in
meinem Projekt auch nicht vorhanden.
Also für mich sieht das im Projekt oben so aus, das du versucht hast ein
Projekt zu erstellen und die StdPeriphLib über den Projekt-Dialog mit
einzubinden. Der Ordner cmsis müsste eig. nicht mehr da sein, wenn du
nach der Anleitung zum ersten Projekt
(http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks#Das_erste_Projekt_erstellen)
vorgegangen wärst. Außerdem müsste es ein zweiten globalen define geben
STM32F40_41xxx. Die Dateien stm32f4xx.h und system_stm32f4xx.c/.h sind
auch noch die alten.
Moritz
Hm das läuft bei mir durch, ich werde es nochmal probieren, vielleicht
finde ich den Fehler..danke...
Ev. mache ich ins Wiki noch ein paar Absätze bzw. Nummerierungen rein,
damit es übersichtlicher wird. Ein paar Fehler hatte ich schon
korrigiert.
So nun läuft es bei mir auch. Keine Ahnung woran es lag. Ev. kannst du
deinen "Grundrahmen" mit in das Wiki einbinden, so hat man ein
Vergleichsprojekt.
Die Absätze hast du ja auch schon geändert, danke dir.
Funktioniert es bei euch, EM::Blocks in mehreren Instanzen zu öffnen?
Ich hab das in den Einstellungen geändert, aber es geht trotzdem nur
eine Instanz.
Moritz M. schrieb:> Leider kann man nur max 50MB hochladen.>> Moritz
Mach vor dem zippen ein Clean, dann sind die ganze object files nicht
dabei. Das spart einiges.
>Mach vor dem zippen ein Clean, dann sind die ganze object files nicht>dabei. Das spart einiges.
Die Libraries aus CMSIS/lib mit über 100MB braucht auch nicht jeder;)
Das bringt viel mehr.
Das fand ich auch etwas abschreckend, erstmal zig Magebyten an Zeugs
runter laden zu müssen, nur um zum Einstieg ein paar LEDs zum Blinken zu
bringen. Kam auch nicht so richtig zu Rande damit und habe dann erstmal
wieder neu angefangen, und einfach eines der vielen CooCox-Beispiele
importiert und damit rumgespielt.
Hallo,
ersteinmal ganz großes DANKE für das Tutorial. Ich werde es auf
jedenfall weiterhin verfolgen. Endlich mal alle Infos an einem Platz ;)
Natürlich möchte auch ich etwas beisteuern, da gerade die Dinge mit den
Clocks am Anfang sehr verwirrend für mich waren. So wie ich oben so im
überflug mitbekommen habe ist das ja auch immernoch nicht ganz so
einfach. Ich bin allerdings auf ein Application Note von STM gestoßen
welches ich hier gern verlinken würde, da ich es gerade für Anfänger
sehr hilfreich finde.
http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1533/PF257927?s_searchtype=keyword#
Im unteren Teil gibt es eine Zip mit einer Excel Tabelle, welche die
"system_stm32f4xx.c" generiert. Gerade für Anfänger finde ich es
wirklich gut. eventuell willst du es ja verlinken oder so.
MFG
His
BlocksUser schrieb:> Gibt es die Möglichkeit, bei compilieren im Debug Ordner auch ein *.bin> oder *.hex File zu erzeugen?
Die Frage habe ich mir selber auch gestellt und folgende kurze Anleitung
geschrieben. Hier wird beschrieben, wie man aus der IDE heraus durch den
Kommandozeilenaufruf des ST-Link Tools das Programm (hex/bin) direkt in
den Controller übertragen kann.
Wo hast du den die alte Version vom ST-Link her? Mit der aktuellen
(v1.8.1) geht es nicht so wie beschrieben.
Musste es etwas abändern damit es mit der v1.8.1 geht.
-c SWD UR -P "${TARGET_OUTPUT_DIR}${TARGET_OUTPUT_BASENAME}.hex"
0x08000000 -V "after_programming" -Rst -Run
Michi schrieb:> Wo hast du den die alte Version vom ST-Link her? Mit der aktuellen> (v1.8.1) geht es nicht so wie beschrieben.
Bin STM32F4 User der ersten Stunde. Hatte bisher nie einen Grund das
Link Utility auf eine neue Version zu überprüfen. Habe es gerade mal
aktualisiert und auch die Firmware auf dem Discovery Board und kann
bestätigen, dass es erst nach der von dir genannten Anpassung geht. Der
-V befehl hat sich geändert.
indus
Moin. Während des debuggens kannst du eine Variable makieren und dann
rechts klick -> add watch. Unter dem Debugger neu gibt es einen Eintrag
debugging Windows und darunter das Fenster watches oder so ähnlich.
Moritz
Hallo Moritz!
Danke für das Tutorial!
Ich bin jetzt erst über EmBlocks gestolpert und bin begeistert.
Bisher habe ich immer mit EWARM (Iar) gearbeitet.
Schön finde ich auch die Registeransicht der Peripherals. Dazu muss das
passende SVD File geladen werden. Zu finden im Debug-Menü.
Auch das Mixed Assembly/C Debugging finde ich gut.
Folgendes habe ich zum Thema Listing File gefunden (allgemein GCC):
Q: How can I peek at the assembly code generated by GCC?
Q: How can I create a file where I can see the C code and its assembly
translation together?
A: Use the -S (note: capital S) switch to GCC, and it will emit the
assembly code to a file with a .s extension. For example, the following
command:
gcc -O2 -S -c foo.c
will leave the generated assembly code on the file foo.s.
If you want to see the C code together with the assembly it was
converted to, use a command line like this:
gcc -c -g -Wa,-a,-ad [other GCC options] foo.c > foo.lst
which will output the combined C/assembly listing to the file foo.lst.
If you need to both get the assembly code and to compile/link the
program, you can either give the -save-temps option to GCC (which will
leave all the temporary files including the .s file in the current
directory), or use the -Wa,-aln=foo.s option which instructs the
assembler to output the assembly translation of the C code (together
with the hex machine code and some additional info) to the file named
after the =.
Hallo,
danke schonmal für das tutorial.
Ich habe allerdings ein Problem mit den neuen libs. Diese sind seit
Februar neu geordnet in dem so genannten Stm32CUBE. Die standard
peripheral Treiber heißen nun zwar en etwa wie vorher, beinhalten jedoch
immer den Zusatz "_hal" im Namen.
Mir gelingt es leider seit Stunden nicht diese funktionierend in
EM::block einzubauen...
Hat jemand tips oder auch gerne eine englische Seite dazu?
Hallo,
ich habe eine recht banale aber vielleicht wichtige Frage zum Tutorial:
Wie werden die Pfade für Include angegeben? Die Stelle, wo ich sie
eintragen muss sind gut erklärt, aber manche Dateien werden immer noch
nicht gefunden. Müssen die Dateien relativ zum Ordner, in dem ich meine
Projekte gespiechert habe - der Ordner befindet sich unter Dokumente
auf der gleichen Hirarchieebene wie die Projektordner. Ich habe es
absolut (C:\...\inc) und relativ zum Stammordner, der die Projektordner
und den Ordner mit den Header-Dateien verbindet, versucht.
Ich habe da einen falschen Gedanken zwischen und einen Fehler. Könnt ihr
mir bitte bei der richten Lösung helfen?
Viele Grüße
Axel
Vielen Dank für das Tutorial, das hat mir den Einstieg in die STM32F4
Welt um einiges erleichtert!
Ich habe aber eine Frage bezüglich des System-Register Debugging, wenn
ich das Fenster öffne sehe ich in jedem Register nur den Wert 0x0000000.
(svd-File wurde laut Tut. erstellt)
Was hab ich übersehen?
lg Stefan
markusDerBastler schrieb:
> Autor:>> markusDerBastler (Gast)>>>>>>>> Datum: 10.02.2014 15:52
Nur so Neugierig, bist der Bruder vom berühmte Thomas der Bastler?
Weiter oben wurde ja nach STM32Cube gefragt.
Ich habe es in emblocks mit den Informationen aus folgendem Thread zum
Laufen bekommen.
Beitrag "STM32Cube & Eclipse & GCC"
Vielleicht ist das etwas, was noch ins Tutorial aufgenommen werden kann.
Hallo,
gibt es von dem tutorial auch eine etwas neuere Version z.B. mit dem
aktuellen stm32cubef4 release (1.3.0) und emblocks 2.3 ?
Ich versuche das nämlich gerade hinzubekommen.
Bis jetzt habe ich es geschaft die HAL driver zu verwenden, ABER was
nicht geht ist die BSP und HAL driver gleichzeitig verwenden z.B. um
BSP_LED_Init() nutzen zu können (man will das Rad ja nicht immer wieder
neu erfinden müssen). Das gibt in stm32f4_discovery.c immer Fehler mit
den I2C und SPI Methoden (typen und methoden nicht gefunden etc.) Gibts
dafür evtl. eine Lösung oder ist das eh pfui beides gleichzeitig
verwenden zu wollen?
Mein vorgehen war ein neues project mit emblocks zu ertellen, den ganzen
inhalt rauszuwerfen, ein project mit stm32cubemx zu ertstellen code
gegenieren lassen und dann die files wieder im emblock project
einbinden.
VG
Grobi
Vielen Dank! Hat mir super geholfen, erstmal einen Einstieg zu finden,
weil der Sprung von Arduino&Co. zu ARM development dann doch ganz schoen
gross ist...
Auf die im Artikel angekuendigte Forsetzung freue ich mich schon!
Beste Gruesse aus Neuseeland
J.
Hi,
Danke für das Tutorial, hat mir schon einiges geholfen.
Hat schön jemand Erfahrung mit dem Cortex M0/M0+ Kern?
Bin gerade dabei das Dicoveryboard mit dem STM32L053 Prozessor zu
testen, habe jedoch das Problem, dass das Debuggen nicht funktioniert.
Bei den Debugeinstellungen muss eine sogeannate SVD-Datei angeben.
Normalerweise sollte diese beim erstellen des Projektes mit generiert
werden
(http://www.powerloss.de/2013/12/vorstellung-emblocks-entwicklungsumgebung-fur-microcontroller/),
leider bei mir nicht und ich kann sie auch nirgends finden. Bitte um
eure Hilfe!
Kompilieren funktioniert ohne Ferhler und Warnungen.
Bin leider eher ein Programmieranfänger.
Danke für eure Antworten!
mfg Reinhard
Hi,
woher weiss der Linker denn dann wo das CCRAM liegt?
1. Eine neue Section im Linkerscript anlegen:
Sections:
{
...
.ccram :
{
*(.ccram)
} > CCRAM
...
}
Gruss,
Christian
Kaum drei (bzw zwei) Jahre später hab auch ich es (diesen
Thread bzw Wiki) gefunden.
Aber ich bin ja auch erst seit drei Tagen auf dem 32Bit Trip.
Danke für das Wiki.
Bleibt noch zu sagen dass das Wiki ja für Em::Blocks geschrieben
wurde, die IDE mittlerweile aber EmBitz heisst. Aber das wissen
ja sowieso alle ..... also was schreib ich hier für Langeweile.
Thread beobachten
Seitenaufteilung abschalten