Einstieg AT91SAM7S256 **gesuchteHeaderfiles**

hallo,
geh mal auf www.at91.com und dort auf KIT -> AT91SAM7S-EK.
dort findest du jede menge beispiel-programme und auch die gewünschte
header-datei.

gruss
gerhard

Besten Dank für die Blitz-Antwort bin recht schnell fündig geworden...

Ja, die Definitionen in den Header-Files sind bis auf diejenigen fuer
RAM-Speichergroesse und der Organisation des Flash-Speichers gleich.
Falls die Anwendung diese Informationen nicht nutzt, kann auch die
Header-Datei des SAM7S64 fuer den SAM7S256 verwendet werden. Vergleich
mittels Win2k fc im Anhang. Aber Quelle fuer die "richtige" Datei
wurde von gerhard ja bereits genannt.

ich habe auch gerade das SAM7-P256 Board von Olimex aktiviert. Der
WinARM läuft und ich habe versucht das erste Atmel Beispiel aus dem
WinARM Package zum Laufen zu bringen. Das hat soweit geklappt, ich habe
auch die Header files aus dem AT91 Forum geladen. Dann habe ich im
Makefile zwei Kleinigkeiten geändert: das SUBMDL auf den 256er Typen
gesetzt und dann wollte der Linker auch passende files haben. Gibt es
fertige .ld files oder eine Beschreibung dazu? Ich habe das erstmal
durch Anpassen der 64er  ld files hinbekommen.
Dann habe ich noch die Optimierung ausgeschaltet, daraufhin hat der
Compiler die inline Routinen wegoptimiert und der Linker hat gemeckert
weil die Routinen nicht public sind. Warum werden diese inline
Konstrukte da benutzt, kommt das aus einem Codegenerator oder ist das
bei den AT91 'Standard' ?
Welche Quellen gibts noch mit Beispielen für den WinARM? Und wie lässt
sich das Ganze debuggen?

- Linker-Skript fuer SAM7256: Linker-Skript fuer SAM7S64 unterscheidet
sich nur in den Definitionen der Speichergroessen von dem fuer einen
SAM7S256. Ich habe inzwischen ein Beispiel so erweitert, dass man im
Makefile einfach das Model waehlen kann:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_at91.html#at91_gamma

- inline: Handelt sich wohl um die at91lib. Wie ist __inline im Projekt
definiert? Vgl. auch o.g. Beispiel Datei Board.h

- Beispiele: WinARM ist nur eine vorkompilierte GNU-Toolchain mit etwas
Zubehoer. Im Prinzip sollte man jeden Code fuer arm-elf-gcc damit
uebersetzen koennen.

- debuggen: Stichwort OpenOCD. Aktuelle Version nutzen, die in WinARM
20060606 ist inzwischen recht alt. Vgl. auch ww.yagarto.de

Martin Thomas

Hallo Martin,
danke für die Tipps, deine Beispiele und dein Engagement.
Die Inline Definition habe ich gefunden, damit wird das Verhalten klar.

Für den Anfang habe ich genug Beispiele gefunden: die mitgelieferten im
WinARM package, die Appnotes bei Atmel und deine Projekte. Der Einstieg
ist doch nicht so kompliziert wie es erst aussah, die mmc Routinen die
es bei Olimex zum Download gibt liessen sich auch sofort mit dem gcc
übersetzen und liefen auf Anhieb (auch wenn nur low Level Block r/w).
Die Hinweise zu OpenOCD habe ich inzwischen auch gefunden, das sehe ich
mir auch mal an.

>Für den Anfang habe ich genug Beispiele gefunden: die mitgelieferten
>im WinARM package, die Appnotes bei Atmel und deine Projekte.

Die Beispiele in WinARM sind weitestgehend die Beispiele, die man auch
auf meinen Web-Seite finden. Ich habe einfach alle Projekte von der
Webseite in WinARM reinkopiert. Ich aktualisiere den Beispiel-Quellcode
in WinARM allerdings nicht immer, sondern nur dann, wenn ich ein neues
WinARM-Packet zusammenbastle (meistens dann, wenn einen neue
gcc-Version verfuegbar wird). Im Zweifel also immer auch auf
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects nachsehen,
wenn ein in WinARM enthaltener Code nicht "will", moeglicherweise ist
der Fehler in einem aktualisierten Beispielcode schon behoben.

>Der Einstieg ist doch nicht so kompliziert wie es erst aussah,
>die mmc Routinen die es bei Olimex zum Download gibt liessen
>sich auch sofort mit dem gcc übersetzen und liefen auf Anhieb (auch
>wenn nur low Level Block r/w).
Vgl. auch
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/efsl_arm/index.html
dort habe ich ein "MMC/SD-Card-Interface" fuer AT91SAM7 in die efsl
ergaenzt. AT91-interface leider noch nicht im "offiziellen"
Source-Code eingebaut, also nicht von den efsl-Entwicklern
"abgesegnet". Funktioniert aber zumindest auf dem Testsystem
"hier".

Auch das funktionierte auf Anhieb:

Hit B to start the benchmark
Card is initialising.
Card is initialising.
CSD: 00 26 00 32 1F 59 83 B7 EC B5 CF 92 40 40 75 C4
Card Capacity is 62390272 Bytes (121856 Sectors)
Write benchmark start - write to file bm2.txt (100 bytes/write)
547400 bytes written in 5092 ms (104 KBytes/sec)
Read benchmark start - from file bm2.txt (in 100 bytes blocks)
547400 bytes read in 2383 ms (223 KBytes/sec)

Für das Olimex Board müssen nur die LED Bits in board.h geändert
werden:

1

/*-----------------*/

2

/* Leds Definition */

3

/*-----------------*/

4

/*                                 PIO   Flash    PA    PB   PIN */

5

#define LED1            (1<<17)  /* PA0 / PGMEN0 & PWM0 TIOA0  48 */

6

#define LED2            (1<<18)  /* PA1 / PGMEN1 & PWM1 TIOB0  47 */

7

#define NB_LEB      2

8

9

#define LED_MASK        (LED1|LED2)

10

11

/*-------------------------*/

12

/* Push Buttons Definition */

13

/*-------------------------*/

14

/*                                 PIO    Flash    PA    PB   PIN */

15

#define SW1_MASK        (1<<19)  /* PA19 / PGMD7  & RK   FIQ     13 */

16

#define SW2_MASK        (1<<20)  /* PA20 / PGMD8  & RF   IRQ0    16 */

17

#define SW_MASK         (SW1_MASK|SW2_MASK)

18

19

20

#define SW1   (1<<19)  // PA19

21

#define SW2   (1<<20)  // PA20

nur der Init Code findet manchmal kein Ende, stören die seriellen
Ausgaben evtl.?

sieht auch gut aus, vor allem wg. DMA. An der EFSL gefällt mir besser
das es auch für AVR zu gebrauchen ist. Reicht die Performance für den
MP3 Player oder ist die DMA impl. dafür Pflicht? Die MP3 Software soll
auch mal auf dem Board laufen (den TI DAC habe ich schon bekommen),
aber erstmal wollte ich ein bischen damit spielen.
Ich habe noch weitergesucht warum der Init nicht immer klappt: es
passiert immer wenn die SD card in den laufenden Rechner gesteckt wird
oder raus- und wieder reingesteckt wird. Dann hilft auch ein Druck auf
den Reset Taster nicht, irgendwo scheint das SPI zu klemmen (die
Debugoutputs sind unschuldig, habe ich abgeschaltet). Braucht die SD
card irgendeinen Reset? In efs_init() wird doch alles initialisiert,
und das wird nach einem Reset oder vor dem Start des Benchmark
aufgerufen. In der EFSL wird auch ein evtl. vorhandener 'card
present' Kontakt nicht genutzt, gibts dafür einen Grund? Ich habe da
noch nicht soviel im Forum gestöbert.