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.html http://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.
holger schrieb: > 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 Danke! So etwas habe ich schon lange gesucht. Gruß
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.
So wie es aussieht ist das ganze nur für windows?? wie siehts aus mit Linux???
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...
Schade. Da der Upload leider auf 50MB beschränkt ist, kann ich keine Beispiele mehr hochlanden. :( Moritz
1 | GPIO_InitTypeDef GPIOD_InitStructure; |
2 | GPIOD_InitStructure.GPIO_Mode = GPIO_Mode_OUT; |
3 | GPIOD_InitStructure.GPIO_Pin = GPIO_Pin_15; |
4 | GPIO_Init(GPIOD, &GPIOD_InitStructure); |
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?
1 | #include "stm32f4xx.h" |
2 | #define HSE_VALUE ((uint32_t)8000000)
|
3 | int main(void) |
4 | {
|
5 | RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE); |
6 | |
7 | GPIO_InitTypeDef GPIOD_InitStructure; |
8 | GPIOD_InitStructure.GPIO_Mode = GPIO_Mode_OUT; |
9 | GPIOD_InitStructure.GPIO_Pin = GPIO_Pin_9; |
10 | GPIO_Init(GPIOD, &GPIOD_InitStructure); |
11 | |
12 | while(1) |
13 | {
|
14 | GPIO_WriteBit(GPIOD, GPIO_Pin_9, Bit_SET); |
15 | GPIO_WriteBit(GPIOD, GPIO_Pin_9, Bit_RESET); |
16 | }
|
17 | }
|
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
1 | GPIOD->ODR ^= GPIO_Pin_9; // toggelt Pin PD9 |
Uwe
:
Bearbeitet durch User
Hallo,ich stell nachher nochmal ein Testprogramm rein, wo der systemtakt auf dem mco-pin ausgegeben wird. Moritz
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 | extern void SystemInit(void); |
2 | extern void SystemCoreClockUpdate(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
Dieser Code toggelt dagegen mit 15,26MHz.
1 | while(1) // Endlos Schleife |
2 | {
|
3 | GPIOD->BSRRH = 0xF000; // Alle LED's aus |
4 | GPIOD->BSRRL = 0x1000; // LED 1 ein |
5 | }
|
Warum?
>#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:
1 | #include "stm32f4xx.h" |
2 | |
3 | #define CORE_SysTickEn() (*((u32*)0xE0001000)) = 0x40000001
|
4 | #define CORE_SysTickDis() (*((u32*)0xE0001000)) = 0x40000000
|
5 | #define CORE_GetSysTick() (*((u32*)0xE0001004))
|
6 | |
7 | uint32_t t1, t2, dt; |
8 | |
9 | int main(void) |
10 | {
|
11 | |
12 | RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC, ENABLE); |
13 | |
14 | GPIO_InitTypeDef GPIOC_InitStructure; |
15 | GPIOC_InitStructure.GPIO_Mode = GPIO_Mode_OUT; |
16 | GPIOC_InitStructure.GPIO_OType = GPIO_OType_PP; |
17 | GPIOC_InitStructure.GPIO_Pin = GPIO_Pin_9; |
18 | GPIOC_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL; |
19 | GPIOC_InitStructure.GPIO_Speed = GPIO_Speed_100MHz; |
20 | GPIO_Init(GPIOC, &GPIOC_InitStructure); |
21 | |
22 | //-----------------------------------------------------------------
|
23 | |
24 | CORE_SysTickEn(); |
25 | t1 = CORE_GetSysTick(); |
26 | t2 = CORE_GetSysTick(); |
27 | CORE_SysTickDis(); |
28 | |
29 | dt = t2 - t1; |
30 | |
31 | //-----------------------------------------------------------------
|
32 | |
33 | CORE_SysTickEn(); |
34 | t1 = CORE_GetSysTick(); |
35 | |
36 | GPIO_ToggleBits(GPIOC, GPIO_Pin_9); |
37 | |
38 | t2 = CORE_GetSysTick(); |
39 | CORE_SysTickDis(); |
40 | |
41 | |
42 | dt = t2 - t1; |
43 | |
44 | //-----------------------------------------------------------------
|
45 | |
46 | |
47 | while(1) |
48 | {
|
49 | GPIO_ToggleBits(GPIOC, GPIO_Pin_9); |
50 | }
|
51 | }
|
Moritz
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:
1 | #ifndef __NO_SYSTEM_INIT |
2 | ldr r0, =SystemInit |
3 | blx r0 |
4 | #endif |
PS:
1 | GPIOC->BSRRL |= GPIO_BSRR_BS_9; |
braucht nur 13 Zyklen.
1 | GPIOC->ODR ^= GPIO_Pin_9; |
braucht nur 11 Zyklen und ergibt 6.99MHz in der while-Schleife. Moritz
:
Bearbeitet durch User
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.
markusDerBastler schrieb: > Sagt dass das nicht wahr ist. Es ist nicht war. Nimm die richtigen Register und alles wird gut: BSRR und BRR. Ein Überblick über die GPIO: http://hertaville.com/2012/07/28/stm32f0-gpio-tutorial-part-1/
>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!
oder so:
1 | for (;;) |
2 | {
|
3 | GPIOD->BSRRH = 0x1000; // LED grün PD12 ein |
4 | |
5 | GPIOD->BSRRL = 0x1000; // LED grün PD12 aus |
6 | }
|
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.
Holger war schneller. Trotzdem nicht 33. Naja. Warum macht der Compiler das nicht auch so?
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. ;-)
Gerade die USB (Abseits von VCP) und DSP Libraries mit vielen Beispielen wären gut. Dazu findet man noch sehr wenige Tutorials.
Moin, DSP ist schon drin. USB und Ethernet muss ich mich selbst noch ein bisschen mehr einarbeiten. Dauert also noch ein bisschen. Moritz
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?
1 | ||=== test3, Debug ===| |
2 | SPL\src\stm32f4xx_cryp.c||In function 'CRYP_PhaseConfig':| |
3 | SPL\src\stm32f4xx_cryp.c|376|error: 'CRYP_CR_GCM_CCMPH' undeclared (first use in this function)| |
4 | SPL\src\stm32f4xx_cryp.c|376|note: each undeclared identifier is reported only once for each function it appears in| |
5 | SPL\src\stm32f4xx_cryp.c||In function 'CRYP_SaveContext':| |
6 | SPL\src\stm32f4xx_cryp.c|541|error: 'CRYP_CR_GCM_CCMPH' undeclared (first use in this function)| |
7 | SPL\src\stm32f4xx_cryp.c|564|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM0R'| |
8 | SPL\src\stm32f4xx_cryp.c|565|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM1R'| |
9 | SPL\src\stm32f4xx_cryp.c|566|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM2R'| |
10 | SPL\src\stm32f4xx_cryp.c|567|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM3R'| |
11 | SPL\src\stm32f4xx_cryp.c|568|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM4R'| |
12 | SPL\src\stm32f4xx_cryp.c|569|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM5R'| |
13 | SPL\src\stm32f4xx_cryp.c|570|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM6R'| |
14 | SPL\src\stm32f4xx_cryp.c|571|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM7R'| |
15 | SPL\src\stm32f4xx_cryp.c|573|error: 'CRYP_TypeDef' has no member named 'CSGCM0R'| |
16 | SPL\src\stm32f4xx_cryp.c|574|error: 'CRYP_TypeDef' has no member named 'CSGCM1R'| |
17 | SPL\src\stm32f4xx_cryp.c|575|error: 'CRYP_TypeDef' has no member named 'CSGCM2R'| |
18 | SPL\src\stm32f4xx_cryp.c|576|error: 'CRYP_TypeDef' has no member named 'CSGCM3R'| |
19 | SPL\src\stm32f4xx_cryp.c|577|error: 'CRYP_TypeDef' has no member named 'CSGCM4R'| |
20 | SPL\src\stm32f4xx_cryp.c|578|error: 'CRYP_TypeDef' has no member named 'CSGCM5R'| |
21 | SPL\src\stm32f4xx_cryp.c|579|error: 'CRYP_TypeDef' has no member named 'CSGCM6R'| |
22 | SPL\src\stm32f4xx_cryp.c|580|error: 'CRYP_TypeDef' has no member named 'CSGCM7R'| |
23 | SPL\src\stm32f4xx_cryp.c||In function 'CRYP_RestoreContext':| |
24 | SPL\src\stm32f4xx_cryp.c|625|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM0R'| |
25 | SPL\src\stm32f4xx_cryp.c|626|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM1R'| |
26 | SPL\src\stm32f4xx_cryp.c|627|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM2R'| |
27 | SPL\src\stm32f4xx_cryp.c|628|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM3R'| |
28 | SPL\src\stm32f4xx_cryp.c|629|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM4R'| |
29 | SPL\src\stm32f4xx_cryp.c|630|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM5R'| |
30 | SPL\src\stm32f4xx_cryp.c|631|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM6R'| |
31 | SPL\src\stm32f4xx_cryp.c|632|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM7R'| |
32 | SPL\src\stm32f4xx_cryp.c|634|error: 'CRYP_TypeDef' has no member named 'CSGCM0R'| |
33 | SPL\src\stm32f4xx_cryp.c|635|error: 'CRYP_TypeDef' has no member named 'CSGCM1R'| |
34 | SPL\src\stm32f4xx_cryp.c|636|error: 'CRYP_TypeDef' has no member named 'CSGCM2R'| |
35 | SPL\src\stm32f4xx_cryp.c|637|error: 'CRYP_TypeDef' has no member named 'CSGCM3R'| |
36 | SPL\src\stm32f4xx_cryp.c|638|error: 'CRYP_TypeDef' has no member named 'CSGCM4R'| |
37 | SPL\src\stm32f4xx_cryp.c|639|error: 'CRYP_TypeDef' has no member named 'CSGCM5R'| |
38 | SPL\src\stm32f4xx_cryp.c|640|error: 'CRYP_TypeDef' has no member named 'CSGCM6R'| |
39 | SPL\src\stm32f4xx_cryp.c|641|error: 'CRYP_TypeDef' has no member named 'CSGCM7R'| |
40 | ||=== Build finished: 35 errors, 0 warnings (0 minutes, 0 seconds) ===| |
41 | SPL\src\stm32f4xx_cryp_aes.c||In function 'CRYP_AES_GCM':| |
42 | SPL\src\stm32f4xx_cryp_aes.c|786|error: 'CRYP_CR_GCM_CCMPH_0' undeclared (first use in this function)| |
43 | SPL\src\stm32f4xx_cryp_aes.c|786|note: each undeclared identifier is reported only once for each function it appears in| |
44 | SPL\src\stm32f4xx_cryp_aes.c|834|error: 'CRYP_CR_GCM_CCMPH_1' undeclared (first use in this function)| |
45 | SPL\src\stm32f4xx_cryp_aes.c|896|error: 'CRYP_CR_GCM_CCMPH' undeclared (first use in this function)| |
46 | SPL\src\stm32f4xx_cryp_aes.c||In function 'CRYP_AES_CCM':| |
47 | SPL\src\stm32f4xx_cryp_aes.c|1342|error: 'CRYP_CR_GCM_CCMPH_0' undeclared (first use in this function)| |
48 | SPL\src\stm32f4xx_cryp_aes.c|1390|error: 'CRYP_CR_GCM_CCMPH_1' undeclared (first use in this function)| |
49 | SPL\src\stm32f4xx_cryp_aes.c|1453|error: 'CRYP_CR_GCM_CCMPH' undeclared (first use in this function)| |
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.
Ok, les dir am besten das Kapitel http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks#Das_erste_Projekt_erstellen durch. Das einbinden der StdPeriphLib basiert darauf. Einige Dateien darf du auch gar nich mit in das Projekt rein nehmen z.B. ltdc.c/c usw. Moritz
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
So müsste das aussehen, wenn man nach der gesamten Anleitung vorgeht. 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.
:
Bearbeitet durch User
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.
Dein Beispiel oben mit RAR gepackt ist bei mir nur ~20MB groß, das dürfte doch reichen oder?
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
:
Bearbeitet durch User
Gibt es die Möglichkeit, bei compilieren im Debug Ordner auch ein *.bin oder *.hex File zu erzeugen?
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
Gibt es unter em blocks auf debug Möglichkeiten wie kleine Ausgaben zum Pc oder Wert einer Variable am Pc abfragen, oder wie macht man das sonst?
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
Wie kann man beim compilieren lst Dateien erzeugen? Ich würde gerne sehen, welche FPU/DSP Instruktionen genutzt werden.
Es gibt auch ein Disassambler Fenster beim Debuggen. eventuell da. Sonst weiß ich das grade auch nicht so richtig. 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.
:
Bearbeitet durch User
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.
Eine plattform-unabhängige Einführung wäre besser. EmBitz ist für Windows, aber es gibt nicht nur Windows.
Beitrag #5135209 wurde von einem Moderator gelöscht.
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.