Bin totaler Neueinsteiger in Sachen ARM-Technologie und suche nun mittlerweile schon seit ca 3 Tagen nach einem Headerfile für für die AT91SAM7S256 ARM Entwicklungsplatine aus dem Shop. Bin aber nur auf die File für den AT91SAM7s64 gestossen. Wäre jemand so gütig mir das File zur Verfügung stellen oder den URL zu posten... besten Dank im voraus...
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...
Sollte das Headerfile für den AT91SAM7S256 nicht nahezu vollständig identisch mit dem des AT91SAM7S64 sein? Der S256 hat mehr Speicher, bei den Peripherals sind die Unterschiede marginal. Gruss, Dominic
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.?
MMC/SD-Code für AT91SAM7 gibt's auch hier (mit DMA): http://www.mikrocontroller.net/trac/browser/trunk/fatfs
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.
Die Elm-chan-Lib kann man auch u.a. für den AVR gebrauchen, Beispiele bekommt man bei http://elm-chan.org/fsw/ff/00index_e.html. DMA ist Pflicht wenn man das ganze sinnvoll betreiben will. Ich hatte DMA auch für die EFSL implementiert (sind nur ein paar Zeilen, kann ich bei Bedarf gerne raussuchen), bin dann aber wegen einem vermeintlichen EFSL-Problem (das sich danach als Fehler meinerseits herausgestellt hat) auf das FatFS umgestiegen und dabei geblieben, weil es mir besser gefallen hat.
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.