mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Neues STM32 Tutorial


Autor: Moritz M. (avrprogger)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Patrick B. (p51d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Felix L. (flex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Felix L. (flex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ben (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Moritz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe L. (ul5255)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: STMUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vilex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wie es aussieht ist das ganze nur für windows??
wie siehts aus mit Linux???

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Zurzeit wird nur Windows von Em::Blocks unterstützt.

Moritz

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Endlich! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade. Da der Upload leider auf 50MB beschränkt ist, kann ich keine 
Beispiele mehr hochlanden. :(

Moritz

Autor: Michi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
    GPIO_InitTypeDef GPIOD_InitStructure;
    GPIOD_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
    GPIOD_InitStructure.GPIO_Pin = GPIO_Pin_15;
    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);

Autor: markusDerBastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

#include "stm32f4xx.h"
#define HSE_VALUE    ((uint32_t)8000000)
int main(void)
{
    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

    GPIO_InitTypeDef GPIOD_InitStructure;
    GPIOD_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
    GPIOD_InitStructure.GPIO_Pin = GPIO_Pin_9;
    GPIO_Init(GPIOD, &GPIOD_InitStructure);
    
    while(1)
    {
    GPIO_WriteBit(GPIOD, GPIO_Pin_9, Bit_SET);
    GPIO_WriteBit(GPIOD, GPIO_Pin_9, Bit_RESET);
    }
}

Autor: Uwe B. (derexponent)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
GPIOD->ODR ^= GPIO_Pin_9; // toggelt Pin PD9

Uwe

: Bearbeitet durch User
Autor: Moritz-avrprogger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,ich stell nachher nochmal ein Testprogramm rein, wo der systemtakt 
auf dem mco-pin ausgegeben wird.

Moritz

Autor: markusDerBastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
extern void SystemInit(void);
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.

Autor: Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: markusDerBastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieser Code toggelt dagegen mit 15,26MHz.
while(1) // Endlos Schleife
    {
        GPIOD->BSRRH = 0xF000; // Alle LED's aus
        GPIOD->BSRRL = 0x1000; // LED 1 ein
    }

Warum?

Autor: Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>#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.

Autor: markusDerBastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
#include "stm32f4xx.h"

#define CORE_SysTickEn()    (*((u32*)0xE0001000)) = 0x40000001
#define CORE_SysTickDis()   (*((u32*)0xE0001000)) = 0x40000000
#define CORE_GetSysTick()   (*((u32*)0xE0001004))

uint32_t t1, t2, dt;

int main(void)
{

    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC, ENABLE);

    GPIO_InitTypeDef GPIOC_InitStructure;
    GPIOC_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
    GPIOC_InitStructure.GPIO_OType = GPIO_OType_PP;
    GPIOC_InitStructure.GPIO_Pin = GPIO_Pin_9;
    GPIOC_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
    GPIOC_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
    GPIO_Init(GPIOC, &GPIOC_InitStructure);

    //-----------------------------------------------------------------

    CORE_SysTickEn();
    t1 = CORE_GetSysTick();
    t2 = CORE_GetSysTick();
    CORE_SysTickDis();

    dt = t2 - t1;

    //-----------------------------------------------------------------

    CORE_SysTickEn();
    t1 = CORE_GetSysTick();

    GPIO_ToggleBits(GPIOC, GPIO_Pin_9);

    t2 = CORE_GetSysTick();
    CORE_SysTickDis();


    dt = t2 - t1;

    //-----------------------------------------------------------------


    while(1)
    {
        GPIO_ToggleBits(GPIOC, GPIO_Pin_9);
    }
}


Moritz

Autor: Sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
#ifndef __NO_SYSTEM_INIT
    ldr    r0, =SystemInit
    blx    r0
#endif

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS:
GPIOC->BSRRL |= GPIO_BSRR_BS_9;
braucht nur 13 Zyklen.

GPIOC->ODR ^= GPIO_Pin_9;
braucht nur 11 Zyklen
und ergibt 6.99MHz in der while-Schleife.

Moritz

: Bearbeitet durch User
Autor: Sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: markusDerBastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Faster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: markusDerBastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder so:
 for (;;)
    {
        GPIOD->BSRRH = 0x1000; // LED grün PD12 ein

        GPIOD->BSRRL = 0x1000; // LED grün PD12 aus
    }

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.

Autor: markusDerBastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger war schneller.
Trotzdem nicht 33. Naja. Warum macht der Compiler das nicht auch so?

Autor: markusDerBastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Faster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Gibts N. (schneeblau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerade die USB (Abseits von VCP) und DSP Libraries mit vielen Beispielen 
wären gut. Dazu findet man noch sehr wenige Tutorials.

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

DSP ist schon drin. USB und Ethernet muss ich mich selbst noch ein 
bisschen mehr einarbeiten. Dauert also noch ein bisschen.

Moritz

Autor: Gibts N. (schneeblau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?
||=== test3, Debug ===|
SPL\src\stm32f4xx_cryp.c||In function 'CRYP_PhaseConfig':|
SPL\src\stm32f4xx_cryp.c|376|error: 'CRYP_CR_GCM_CCMPH' undeclared (first use in this function)|
SPL\src\stm32f4xx_cryp.c|376|note: each undeclared identifier is reported only once for each function it appears in|
SPL\src\stm32f4xx_cryp.c||In function 'CRYP_SaveContext':|
SPL\src\stm32f4xx_cryp.c|541|error: 'CRYP_CR_GCM_CCMPH' undeclared (first use in this function)|
SPL\src\stm32f4xx_cryp.c|564|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM0R'|
SPL\src\stm32f4xx_cryp.c|565|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM1R'|
SPL\src\stm32f4xx_cryp.c|566|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM2R'|
SPL\src\stm32f4xx_cryp.c|567|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM3R'|
SPL\src\stm32f4xx_cryp.c|568|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM4R'|
SPL\src\stm32f4xx_cryp.c|569|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM5R'|
SPL\src\stm32f4xx_cryp.c|570|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM6R'|
SPL\src\stm32f4xx_cryp.c|571|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM7R'|
SPL\src\stm32f4xx_cryp.c|573|error: 'CRYP_TypeDef' has no member named 'CSGCM0R'|
SPL\src\stm32f4xx_cryp.c|574|error: 'CRYP_TypeDef' has no member named 'CSGCM1R'|
SPL\src\stm32f4xx_cryp.c|575|error: 'CRYP_TypeDef' has no member named 'CSGCM2R'|
SPL\src\stm32f4xx_cryp.c|576|error: 'CRYP_TypeDef' has no member named 'CSGCM3R'|
SPL\src\stm32f4xx_cryp.c|577|error: 'CRYP_TypeDef' has no member named 'CSGCM4R'|
SPL\src\stm32f4xx_cryp.c|578|error: 'CRYP_TypeDef' has no member named 'CSGCM5R'|
SPL\src\stm32f4xx_cryp.c|579|error: 'CRYP_TypeDef' has no member named 'CSGCM6R'|
SPL\src\stm32f4xx_cryp.c|580|error: 'CRYP_TypeDef' has no member named 'CSGCM7R'|
SPL\src\stm32f4xx_cryp.c||In function 'CRYP_RestoreContext':|
SPL\src\stm32f4xx_cryp.c|625|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM0R'|
SPL\src\stm32f4xx_cryp.c|626|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM1R'|
SPL\src\stm32f4xx_cryp.c|627|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM2R'|
SPL\src\stm32f4xx_cryp.c|628|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM3R'|
SPL\src\stm32f4xx_cryp.c|629|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM4R'|
SPL\src\stm32f4xx_cryp.c|630|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM5R'|
SPL\src\stm32f4xx_cryp.c|631|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM6R'|
SPL\src\stm32f4xx_cryp.c|632|error: 'CRYP_TypeDef' has no member named 'CSGCMCCM7R'|
SPL\src\stm32f4xx_cryp.c|634|error: 'CRYP_TypeDef' has no member named 'CSGCM0R'|
SPL\src\stm32f4xx_cryp.c|635|error: 'CRYP_TypeDef' has no member named 'CSGCM1R'|
SPL\src\stm32f4xx_cryp.c|636|error: 'CRYP_TypeDef' has no member named 'CSGCM2R'|
SPL\src\stm32f4xx_cryp.c|637|error: 'CRYP_TypeDef' has no member named 'CSGCM3R'|
SPL\src\stm32f4xx_cryp.c|638|error: 'CRYP_TypeDef' has no member named 'CSGCM4R'|
SPL\src\stm32f4xx_cryp.c|639|error: 'CRYP_TypeDef' has no member named 'CSGCM5R'|
SPL\src\stm32f4xx_cryp.c|640|error: 'CRYP_TypeDef' has no member named 'CSGCM6R'|
SPL\src\stm32f4xx_cryp.c|641|error: 'CRYP_TypeDef' has no member named 'CSGCM7R'|
||=== Build finished: 35 errors, 0 warnings (0 minutes, 0 seconds) ===|
SPL\src\stm32f4xx_cryp_aes.c||In function 'CRYP_AES_GCM':|
SPL\src\stm32f4xx_cryp_aes.c|786|error: 'CRYP_CR_GCM_CCMPH_0' undeclared (first use in this function)|
SPL\src\stm32f4xx_cryp_aes.c|786|note: each undeclared identifier is reported only once for each function it appears in|
SPL\src\stm32f4xx_cryp_aes.c|834|error: 'CRYP_CR_GCM_CCMPH_1' undeclared (first use in this function)|
SPL\src\stm32f4xx_cryp_aes.c|896|error: 'CRYP_CR_GCM_CCMPH' undeclared (first use in this function)|
SPL\src\stm32f4xx_cryp_aes.c||In function 'CRYP_AES_CCM':|
SPL\src\stm32f4xx_cryp_aes.c|1342|error: 'CRYP_CR_GCM_CCMPH_0' undeclared (first use in this function)|
SPL\src\stm32f4xx_cryp_aes.c|1390|error: 'CRYP_CR_GCM_CCMPH_1' undeclared (first use in this function)|
SPL\src\stm32f4xx_cryp_aes.c|1453|error: 'CRYP_CR_GCM_CCMPH' undeclared (first use in this function)|

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gibts N. (schneeblau)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gibts N. (schneeblau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Moritz M. (avrprogger)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So müsste das aussehen, wenn man nach der gesamten Anleitung vorgeht.

Moritz

Autor: Gibts N. (schneeblau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Gibts N. (schneeblau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider kann man nur max 50MB hochladen.

Moritz

Autor: Gibts N. (schneeblau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Beispiel oben mit RAR gepackt ist bei mir nur ~20MB groß, das 
dürfte doch reichen oder?

Autor: Michael G. (teslazwerg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: kai m. (hiswif)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: BlocksUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es die Möglichkeit, bei compilieren im Debug Ordner auch ein *.bin 
oder *.hex File zu erzeugen?

Autor: In d. (indus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: In d. (indus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Semi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Semi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
???

Autor: Moritz-avrprogger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Maxn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kann man beim compilieren lst Dateien erzeugen? Ich würde gerne 
sehen, welche FPU/DSP Instruktionen genutzt werden.

Autor: Moritz M. (avrprogger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch ein Disassambler Fenster beim Debuggen. eventuell da. Sonst 
weiß ich das grade auch nicht so richtig.

Moritz

Autor: Christian C. (christian_c27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 =.

Autor: Gerald_G (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Josep (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
markusDerBastler schrieb:
> Autor:
>
>         markusDerBastler (Gast)
>
>
>
>
>
>
>
>       Datum: 10.02.2014 15:52

Nur so Neugierig, bist der Bruder vom berühmte Thomas der Bastler?

Autor: lekanteto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan K. (jan_k81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Reinhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

woher weiss der Linker denn dann wo das CCRAM liegt?


1. Eine neue Section im Linkerscript anlegen:

Sections:
{
  ...

  .ccram :
  {
    *(.ccram)
  } > CCRAM

  ...
}

Gruss,
Christian

Autor: Hobbyprogrammierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: LarsB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.