Einstieg in ARM

[Felix L. (flex)]

Hallo,

ich habe mich jetzt eine Zeitlang mit Atmel AVR beschäftigt. Da das 
Preis/Leistungsverhältnis bei ARM Mikrocontrollern besser ist, möchte 
ich gerne umsteigen. Zum Einstieg habe ich mir eine KL25Z Freedom Board 
von Freescale besorgt.
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-KL25Z&tid=vanFRDM-KL25Z
Es ist möglich das Board über http://www.mbed.org zu programmiern, oder 
über die JTAG Schnittstelle. Da ich einen Segger J-Link besitze, möchte 
ich auch die JTAG Schnittstelle verwenden. Als IDE verwende ich zur Zeit 
IAR Embedded Workbench.

Bei der IDE war ein Beispielprogramm dabei:

blinky.c:

#include "common.h"

#define SLOW_BLINK      (10000000)
#define FAST_BLINK      (1000000)
#define BLINK_DELAY     FAST_BLINK

#define RED        (18)
#define RED_SHIFT    (1 << 18)
#define GREEN      (19)
#define GREEN_SHIFT    (1 << 19)
#define BLUE      (1)
#define BLUE_SHIFT    (1 << 1)

#define RED_OFF      (GPIOB_PSOR = RED_SHIFT)
#define RED_ON      (GPIOB_PCOR = RED_SHIFT)
#define RED_TOGGLE    (GPIOB_PTOR = RED_SHIFT)

#define GREEN_OFF    (GPIOB_PSOR = GREEN_SHIFT)
#define GREEN_ON    (GPIOB_PCOR = GREEN_SHIFT)
#define GREEN_TOGGLE  (GPIOB_PTOR = GREEN_SHIFT)

#define BLUE_OFF    (GPIOD_PSOR = BLUE_SHIFT)
#define BLUE_ON      (GPIOD_PCOR = BLUE_SHIFT)
#define BLUE_TOGGLE    (GPIOD_PTOR = BLUE_SHIFT)

void delay_time(int);

/********************************************************************/
int main (void)
{
    printf("\nRunning the blinky project.\n");


  /*
   * Initialize the Red LED (PTB18)
   */
  {
    /* Turn on clock to PortB module */
    SIM_SCGC5 |= SIM_SCGC5_PORTB_MASK;

    /* Set the PTB18 pin multiplexer to GPIO mode */
    PORTB_PCR18 = PORT_PCR_MUX(1);

    /* Set the initial output state to high */
    GPIOB_PSOR |= RED_SHIFT;

    /* Set the pins direction to output */
    GPIOB_PDDR |= RED_SHIFT;
  }

  /*
   * Initialize the Green LED (PTB19)
   */
  {
    /* Turn on clock to PortB module */
    SIM_SCGC5 |= SIM_SCGC5_PORTB_MASK;

    /* Set the PTB19 pin multiplexer to GPIO mode */
    PORTB_PCR19 = PORT_PCR_MUX(1);

    /* Set the initial output state to high */
    GPIOB_PSOR |= GREEN_SHIFT;

    /* Set the pins direction to output */
    GPIOB_PDDR |= GREEN_SHIFT;
  }

  /*
   * Initialize the Blue LED (PTD1)
   */
  {
    /* Turn on clock to PortB module */
    SIM_SCGC5 |= SIM_SCGC5_PORTD_MASK;

    /* Set the PTD1 pin multiplexer to GPIO mode */
    PORTD_PCR1 = PORT_PCR_MUX(1);

    /* Set the initial output state to high */
    GPIOD_PSOR = BLUE_SHIFT;

    /* Set the pins direction to output */
    GPIOD_PDDR |= BLUE_SHIFT;
  }

  while(1)
    {
    RED_ON;
    delay_time(BLINK_DELAY);  /* Red */
    RED_OFF;
    GREEN_ON;
    delay_time(BLINK_DELAY);  /* Green */
    GREEN_OFF;
    BLUE_ON;
    delay_time(BLINK_DELAY);  /* Blue */
    RED_ON;
    delay_time(BLINK_DELAY);  /* Blue + Red */
    GREEN_ON;
    BLUE_OFF;
    delay_time(BLINK_DELAY);  /* Red + Green */
    RED_OFF;
    BLUE_ON;
    delay_time(BLINK_DELAY);  /* Green + Blue */
    RED_ON;
    delay_time(BLINK_DELAY);  /* Green + Blue + Red */
    GREEN_OFF;
    BLUE_OFF;
  }
}
/********************************************************************/

void delay_time(int number){
  int cnt;
  for(cnt=0;cnt<number;cnt++);
}
/********************************************************************/

/********************************************************************/

Soweit verstehe ich den Code, aber was ich nicht verstehe ist, für was 
ist die common.h?

/*
 * File:        common.h
 * Purpose:     File to be included by all project files
 *
 * Notes:
 */

#ifndef _COMMON_H_
#define _COMMON_H_

/********************************************************************/

/*
 * Debug prints ON (#define) or OFF (#undef)
 */

#define DEBUG
#define DEBUG_PRINT

/* 
 * Include the generic CPU header file 
 */
#include "arm_cm0.h"

/* 
 * Include the platform specific header file 
 */
#if (defined(FIREBIRD))
  #include "firebird.h"
#elif (defined(TOWER))
  #include "tower.h"
#elif (defined(FREEDOM))
  #include "freedom.h"
#elif (defined(BACES))
  #include "baces.h"
#else
  #error "No valid platform defined"
#endif

/* 
 * Include the cpu specific header file 
*/
#if (defined (CPU_MKL05Z32LF4))
  #include "MKL05Z4.h"
#elif (defined(CPU_MKL25Z128LK4))
  #include "MKL25Z4.h"
#else
  #error "No valid CPU defined"
#endif


/* 
 * Include any toolchain specfic header files 
 */
#if (defined(__MWERKS__))
  #include "mwerks.h"
#elif (defined(__DCC__))
  #include "build/wrs/diab.h"
#elif (defined(__ghs__))
  #include "build/ghs/ghs.h"
#elif (defined(__GNUC__))
  #include "build/gnu/gnu.h"
#elif (defined(IAR))
  #include "iar.h"
#elif (defined(KEIL))
  
#else
#warning "No toolchain specific header included"
#endif

/* 
 * Include common utilities
 */
#include "assert.h"
#include "io.h"
#include "startup.h"
#include "stdlib.h"
#include "intrinsics.h"

/* 
 * Global Variable
 */


/********************************************************************/

#endif /* _COMMON_H_ */

Woher bekomme ich die Include, wenn ich ein neues Projekt anlege?

Gruß
Felix

[Pete K. (pete77)]

Die common.h bringt die IDE mit und sollte im include-path stehen.

[Felix L. (flex)]

Wenn ich jetzt bei IAR ein neues Projekt anlege, wie sage ich der IDE 
dann, was für einen µC ich verwende? Beim Atmel Studio oder auch beim 
Code Composer Studio kann ich am Anfang immer auswählen, was ich für 
einen µC verwende. Dann werden alle Include Dateien automatisch 
eingefügt. Nur bei IAR habe ich das noch nicht rausgefunden.

Gruß
Felix

[Barnabas (Gast)]

Danke fürs Posten eines ersten Beispiels auf "Hallo Welt" Niveau! 
Verschafft dem Einsteiger gleich den rechten Einblick in die 
Leichtigkeit des ARM Daseins... Tja, das Preis/Leistungsverhältnis ist 
eben doch nicht alles, aber wer seine wertvolle Zeit dermaßen 
verschleudern will, bitte nur zu :-)

[old man (Gast)]

Barnabas schrieb:
> Tja, das Preis/Leistungsverhältnis ist
> eben doch nicht alles, aber wer seine wertvolle Zeit dermaßen
> verschleudern will, bitte nur zu :-)

Besser mit der Zeit was dazu lernen als vorgekauten Kram zu benutzen von 
den man nichts versteht. Das macht vielleicht das "Hello World" einfach, 
aber sobald es ans Eingemachte geht wird gemeckert oder hier die 
blödesten Fragen gestellt die man nie gestellt hätte wenn man etwas 
tiefer eingedrungen wäre.

[Juergen G. (jup)]

Barnabas schrieb:
> aber wer seine wertvolle Zeit dermaßen
> verschleudern will, bitte nur zu :-)

@Barnabas
Wiederverwendbaren Quellcode zu schreiben der auch auf mehreren 
Compilern laeuft scheint wohl ein unbekanntes Terrain fuer Dich zu sein.

Wenn Du die ganzen defines und Compiler Tweaks aus dem o.g. Code 
streichst wird er sehr viel verstaendlicher.

Wenn ich ein minimal Led-Blink-Programm fuer einen Arm und fuer nur 
einen Compiler schreibe, brauche ich 3 Zeilen Code mehr als auf einem 
AVR.

[tom57 (Gast)]

Hallo guten Morgen,
wenn Du im IAR ein neues Projekt anlegst, hast Du die Möglichkeit über 
Optionen bzw. Einstellungen dieses Projektes auch den Core bzw. Deinen 
Prozessor auszuwählen. Der Projektrumpf wird dann automatisch generiert.

[M. N. (Gast)]

Felix L. schrieb:
> Wenn ich jetzt bei IAR ein neues Projekt anlege, wie sage ich der IDE
> dann, was für einen µC ich verwende?

Mit linker Maustaste in der Liste "Workspace/Files" den Projektnamen 
anklicken.
Dann unter "Projekt->Options->General Options" die Einstellungen 
vornehmen.

[Felix L. (flex)]

Danke für die Antworten.

Wie ich den Prozessor einstelle habe ich gefunden. Noch eine Frage:
Woher bekomme ich die ganze Includes, die auf dem Screenshot zu sehen 
sind? Sind die bei der IDE dabei, oder wurde die extra für das "Hello 
World" geschrieben?

[M. N. (Gast)]

Du solltest mit Deiner Maus mehr spielen!
Mit der rechten Taste auf die xxx.h tippen und "Open Containing 
Folder..." auswählen.

[Felix L. (flex)]

M. N. schrieb:
> Du solltest mit Deiner Maus mehr spielen!
> Mit der rechten Taste auf die xxx.h tippen und "Open Containing
> Folder..." auswählen.

Dann komme ich immer in den Ordner des Beispiels. Im Zielverzeichnis der 
IDE gibt es nur die MKL25Z4.h.

[W.S. (Gast)]

Felix L. schrieb:
> Wie ich den Prozessor einstelle habe ich gefunden. Noch eine Frage:
> Woher bekomme ich die ganze Includes, die auf dem Screenshot zu sehen
> sind? Sind die bei der IDE dabei, oder wurde die extra für das "Hello
> World" geschrieben?

Wenn du schon damit nicht klarkommst, dann soltest du erstmal ganz unten 
an der Basis anfangen. Vom Überfliegen hat noch keiner was gelernt und 
vom Herumwurschteln in irgendeiner bestimmten IDE mit deren 
Befindlickeiten wird man das Verstehen der ARM-Architektur nicht lernen, 
sondern allenfalls, was irgendwer in irgendwelchen Blinky und HelloWorld 
Programmen für eben diese IDE einem vorgekaut hat.

Mein Rat: Lies erstmal das Manual zum Prozessor. Dann mach dich mit den 
Standalone-Programmen zu deinem Segger vertraut, insbesondere mit dem 
Programm zum Flashen deines µC.

Probiere das dann erstmal aus, ob du Code schreiben, verifizieren und 
auch wieder zurücklesen kannst.

Dann mach dich dran, dir einen eigenen Startupcode zu schreiben. Dabei 
ist "verstehendes Lesen" von Startupcodes anderer Leute durchaus 
hilfreich, aber laß dir das nicht zum Korsett werden. Sieh zu, daß du 
dir diesen Startupcode mit dem Assembler fehlerfrei übersetzt bekommst.

Als nächstes solltest du dir KEIN irgendwo gebotenes Blinky- oder 
HelloWorld-Beispiel nehmen, sondern dir selbst eien Art Minimal-Monitor 
schreiben. Also etwas, mit dem man über ne serielle Schnittstelle 
sprechen kann. Da gibt's hier im Board auch Beispiele dafür, such mal 
nach der "Lernbetty". Davon kannst du dir ne Menge relativ 
hardwareunabhängiger Teile nehmen (Quellen lesen und verstehen 
vorausgesetzt).

So ein Minimal-Monitor ist ne wichtige Sache, denn er ist quasi wie der 
Fuß in der Tür für den geübten Vertreter. Läuft erstmal sowas auf einem 
µC, dann ist die Tür offen für alles Weitere.

Und zum Schluß noch ein paar Ratschläge:
- laß sowas wie printf lieber bleiben. Schreib dir ein paar simplere 
Funktionen, um irgendwas zu irgendeiner Schnittstelle herauszukriegen. 
Das reduziert die Fehlermöglichkeiten.
- sieh zu, nicht alles und jedes Headerfile einzubinden, sondern 
wirklich nur das, was du WIRKLICH brauchst. Ich weiß, daß gerade bei 
einigen tollen Hardwareherstellern sowas wie deren noch viel tollere 
Standardbibliotheken haufenweise Headerfiles aller Art einbinden, bis 
man als Einsteiger sich zugeschüttet fühlt. Siehe deine Frage. Also: Laß 
erstmal all diesen Kram beiseite für den Anfang.

Das was du immer brauchst, sind die Verweise auf die typabhängigen 
Register in der Hardware. Ob das nun in einem Sammel-Headerfile ist oder 
jeweils intern in den diversen Treiber-Quellen für die einzelnen 
Peripherie-Teile, ist eigentlich egal. Es gibt aber noch ein elendes 
Ärgernis: Häufig muß man sehen, daß in fertigen Headerfiles die 
Registerbezeichnungen anders sind als im Hardware-Manual. Sowas ist 
Ober-Bockmist, denn wenn man mit jemand anderem über HW-Probleme reden 
will, ist Babylon angesagt: keiner versteht den anderen. Ich hab mir 
genau deswegen inzwischen angewöhnt, in solchen Fällen mir meine eigenen 
Headerfiles zu schreiben - und zwar mit exakt den gleichen 
Registerbezeichnungen wie in der Hardware-Doku.

W.S.

[Felix L. (flex)]

Hallo,

vielen Dank für die sehr ausführliche Antwort.

W.S. schrieb:
> Mein Rat: Lies erstmal das Manual zum Prozessor.

Damit meinst du das hier?:
http://cache.freescale.com/files/32bit/doc/ref_manual/KL25P80M48SF0RM.pdf

W.S. schrieb:
> Dann mach dich dran, dir einen eigenen Startupcode zu schreiben. Dabei
> ist "verstehendes Lesen" von Startupcodes anderer Leute durchaus
> hilfreich, aber laß dir das nicht zum Korsett werden.

Was genau macht ein Startup Code? Bei z.B. Keil wird man beim erstellem 
eines Projektes immer gefragt, ob der Startupcode mit eingefügt werden 
soll.

W.S. schrieb:
> Ich hab mir
> genau deswegen inzwischen angewöhnt, in solchen Fällen mir meine eigenen
> Headerfiles zu schreiben - und zwar mit exakt den gleichen
> Registerbezeichnungen wie in der Hardware-Doku.

Wenn die Header File aber vom selben Hersteller kommt, wie der µC, dann 
sollte das doch sitmmen? z.B.die MKL25Z4.h

Gruß
Felix

[Mops Fidibus (Gast)]

@Felix: Welche konkrete Anwendung schwebt Dir eigentlich vor die den 
ganzen Aufwand hier rechtfertigt?

[W.S. (Gast)]

Felix L. schrieb:
> Was genau macht ein Startup Code?

Ei was macht er wohl?

Stell dir vor, es ist kurz nach dem Reset und der prozessor kriegt 
seinen ersten Takt. Was wird er da wohl machen? Klar, das, was seine 
Konstrukteure ihm an Funktionalität gegeben haben. Er fängt also auf 
irgend eine Weise an zu arbeiten und das, was er dabei sinnvollerweise 
tun sollte ist, deinen Startupcode abzuarbeiten.

Was du dort unterbringst, ist deinen Erwägungen überlassen.
Ich setze dort die diversen Stacks auf, behandle Exceptions (sofern 
vorgekommen), arrangiere den Takt und starte anschließend "main".

Es ist wohl doch besser, du vertiefst dich erstmal in die Lektüre zu 
deinem Prozessor. Ist ein Cortex M0+ ja? Dann lies auch zusätzlich die 
zugehörigen PDF's von ARM. Anschließend sollte es dir so einigermaßen 
klar sein, wie man mit diesem Chip umgeht.

Felix L. schrieb:
> Wenn die Header File aber vom selben Hersteller kommt, wie der µC, dann
> sollte das doch sitmmen? z.B.die MKL25Z4.h

Vertrauen ist gut, Kontrolle ist besser - und haarsträubende 
Bitfelder-Konstrukte, wie sie manche Hersteller offenbar lieben, sind 
schlechter. Mein Rat (immer wieder): Schreib einen einfachen Stil, 
verzichte auf "tolle" C-Features, Macros und halsbrecherische 
Preprozessor-Akrobatik. Benutze #define's sparsam und nicht ausufernd 
und vermeide sowas wie #ifdef. Und überlasse das Optimieren dem 
Compiler.

W.S.