Mikrocontroller.net - Benutzerbeiträge [de]

ARM-DevCpp

2005-10-24T13:50:24Z

Clemens Helfmeier: /* Compiler einrichten */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich (Binaries stehen weiter unten).
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 und GNU Arm 3.4 und 4.0 für Cygwin gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' (''4.0.1'' für den 4.0er Compiler) nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Projekt Vorlage ==
Als nächstes wird eine Vorlage gebraucht. Diese kann anschließend für ein neues Projekt kopiert werden (per Explorer/Arbeitsplatz o.ä.). Leider kann diese Aufgabe nicht durch ein Template gereglt werden, da dieses die nötigen Einstellungen nicht unterstützt. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| '''Dateiname'''
| '''Inhalt'''
| '''Einstellungen bei''' '''Projekt Optionen'''->'''Dateien'''
|-
| Board.h
| Board-Definitionen
| keine Änderungen möglich (Header-Datei), nicht zwingend erforderlich
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Board.h'': Definitionen für das verwendete System (nicht zwingend erforderlich)
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]
* [[ARM-elf-GCC-Tutorial]]

ARM-DevCpp

2005-10-24T13:49:46Z

Clemens Helfmeier: /* Bezugsquellen */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich (Binaries stehen weiter unten).
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 und GNU Arm 3.4 und 4.0 für Cygwin gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Projekt Vorlage ==
Als nächstes wird eine Vorlage gebraucht. Diese kann anschließend für ein neues Projekt kopiert werden (per Explorer/Arbeitsplatz o.ä.). Leider kann diese Aufgabe nicht durch ein Template gereglt werden, da dieses die nötigen Einstellungen nicht unterstützt. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| '''Dateiname'''
| '''Inhalt'''
| '''Einstellungen bei''' '''Projekt Optionen'''->'''Dateien'''
|-
| Board.h
| Board-Definitionen
| keine Änderungen möglich (Header-Datei), nicht zwingend erforderlich
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Board.h'': Definitionen für das verwendete System (nicht zwingend erforderlich)
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]
* [[ARM-elf-GCC-Tutorial]]

ARM-DevCpp

2005-10-24T13:45:27Z

Clemens Helfmeier: /* Bezugsquellen */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich (Binaries stehen weiter unten).
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 und GNU Arm 3.4 für Cygwin gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Projekt Vorlage ==
Als nächstes wird eine Vorlage gebraucht. Diese kann anschließend für ein neues Projekt kopiert werden (per Explorer/Arbeitsplatz o.ä.). Leider kann diese Aufgabe nicht durch ein Template gereglt werden, da dieses die nötigen Einstellungen nicht unterstützt. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| '''Dateiname'''
| '''Inhalt'''
| '''Einstellungen bei''' '''Projekt Optionen'''->'''Dateien'''
|-
| Board.h
| Board-Definitionen
| keine Änderungen möglich (Header-Datei), nicht zwingend erforderlich
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Board.h'': Definitionen für das verwendete System (nicht zwingend erforderlich)
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]
* [[ARM-elf-GCC-Tutorial]]

ARM-DevCpp

2005-10-23T09:17:23Z

Clemens Helfmeier: /* Vorlage Projekt */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Projekt Vorlage ==
Als nächstes wird eine Vorlage gebraucht. Diese kann anschließend für ein neues Projekt kopiert werden (per Explorer/Arbeitsplatz o.ä.). Leider kann diese Aufgabe nicht durch ein Template gereglt werden, da dieses die nötigen Einstellungen nicht unterstützt. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| '''Dateiname'''
| '''Inhalt'''
| '''Einstellungen bei''' '''Projekt Optionen'''->'''Dateien'''
|-
| Board.h
| Board-Definitionen
| keine Änderungen möglich (Header-Datei), nicht zwingend erforderlich
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Board.h'': Definitionen für das verwendete System (nicht zwingend erforderlich)
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]
* [[ARM-elf-GCC-Tutorial]]

ARM-elf-GCC-Tutorial

2005-10-22T19:00:05Z

Clemens Helfmeier: /* Weitere Informationsquellen */

[[Category:ARM]]

Dieses Tutorial behandelt die Programmierung von ARM Mikrocontrollern mithilfe des ARM-elf-GCC Compilers. Die meisten Codebeispiele wurden mit WinARM übersetzt.
Vorerst wird sich dieses Tutorial an die '''[http://www.mikrocontroller.net/articles/LPC2000_Philips_ARM7TDMI-Familie LPC Reihe von Philips]''' richten. Im späteren Verlauf werden allerdings auch ARM Mikrocontroller von Atmel (SAM7 & co.) behandelt.

== Bezugsquellen ==
Komplette Boards mit ARM7 Kern kann man von folgenden Webseiten beziehen:
* [http://shop.mikrocontroller.net/ Mikrocontroller.net]
* [http://www.olimex.com/dev/index.html Olimex]
* [http://www.embeddedartists.com/ Embedded Artists]
* [http://www.keil.com/dd/arm7chips.asp Keil]

Wenn man allerdings selbst ein ARM7 Board herstellen möchte kann man die Schaltpläne von den Olimex Boards als gute Grundlage nehmen.

== Benötigte Programme ==
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html WinARM] Entwicklungsumgebung
* Alternativ zu Winarm: [http://www.gnuarm.com/ GNU ARM]
* [http://www.semiconductors.philips.com/files/markets/microcontrollers/philips_flash_utility.zip Philips Flashtool] Offizielles Programmiertool für Windows

* Optional: [http://guest.engelschall.com/~martin/lpc21xx/isp/ lpc21isp] Kommandozeilen-Programmiertool für Windows & Linux

== Startprobleme ==
Wenn man vor den ersten Versuchen mit ARM Mikrocontrollern mit WinAVR und ähnlichen Entwicklungsumgebungen programmiert hat musste man außer seinem C Code und dem daraus entstehenden HEX-File nicht viel beachten.
Bei der Programmierung von ARM-Mikrocontrollern muss man aber bedenken, dass es (noch? ;-) ) keine Standard - Linkerscripte und Startupcodes in WinARM gibt.
WinAVR nimmt einem diese Arbeit mit Standard-Files ab, so dass man bei WinAVR meistens nicht in Berührung damit kommt. Im Netz kursieren viele dieser Linkerscripte und Startupcodes. Wir empfehlen die von uns getesteten Scripte zu verwenden damit keine unschönen Phänomene auftreten (Keine Interrupts z.B.).
// Scripte befinden sich vorerst in den WinARM Examples.

== Bevor wir starten ==
Im '''[http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial AVR-GCC Tutorial]''' werden grundlegende Basics erklärt, die sicherlich nützlich sind (Makefiles, Programmablauf in einem Mikrocontroller, etc.). Wir möchten hiermit auf das AVR-GCC-Tutorial verweisen und gehen nicht nochmal auf diese Themen ein.

Außerdem sollte man sich vergewissern dass der Controller mithilfe des Bootloaders angesprochen werden kann. Hierzu verwendet man am besten das Flash Tool von Philips um die DEVICE PART ID auszulesen. Falls dies fehlschlägt sollte man seine Verbindung mit dem Mikrocontroller überprüfen.

=== Länge von Variablentypen ===
Die Länge der jeweiligen Variablentypen unterscheidet sich durchaus von denen des AVRs.
Folgendes ist beim ARM-elf-GCC Compiler gültig:
{| border=1
| '''char'''
| 1 Byte
|-
| '''short'''
| 2 Bytes
|-
| '''int'''
| 4 Bytes
|-
| '''long'''
| 4 Bytes
|-
| '''double'''
| 8 Bytes
|}

== Das erste Programm ==
Die meisten Sourcecodes wurden für einen LPC2124 mit WinARM compiliert. Hierbei muss man beachten, dass in einigen Header Files die Register (z.B. IOSET, IOCLR etc.) unterschiedliche Namen haben. Ein Blick in das Header File welches includet wird ist daher ratsam.

Beispiel:
lpc2114.h aus <arch/philips/lpc2114.h> (Auch gültig für LPC2124)

<pre class="code">
/*##############################################################################
## GPIO - General Purpose I/O
##############################################################################*/

#define GPIO0_IOPIN (*(REG32 (0xE0028000)))
#define GPIO0_IOSET (*(REG32 (0xE0028004)))
#define GPIO0_IODIR (*(REG32 (0xE0028008)))
#define GPIO0_IOCLR (*(REG32 (0xE002800C)))

#define GPIO1_IOPIN (*(REG32 (0xE0028010)))
#define GPIO1_IOSET (*(REG32 (0xE0028014)))
#define GPIO1_IODIR (*(REG32 (0xE0028018)))
#define GPIO1_IOCLR (*(REG32 (0xE002801C)))
</pre>

Verwendet man z.B. einen LPC2106 und bindet "lpc210x_keil.h" aus <arch/philips/lpc210x_keil.h> ein bekommt man folgende Namen:

<pre class="code">
/* General Purpose Input/Output (GPIO) */
#define IOPIN (*((volatile unsigned long *) 0xE0028000))
#define IOSET (*((volatile unsigned long *) 0xE0028004))
#define IODIR (*((volatile unsigned long *) 0xE0028008))
#define IOCLR (*((volatile unsigned long *) 0xE002800C))
</pre>

Daher:
Wenn Registernamen beim Compilieren nicht bekannt sind hilft ein Blick in das Header File des Controllers weiter.

=== Nutzung der I/O Ports ===
Zum Behandeln von I/O Ports sind die Register "IOPIN", "IOSET", "IOCLR" und "IODIR" nötig.
{| border=1
| '''IOPIN'''
| Liest die Zustände des angegebenen Ports ein
|-
| '''IOSET'''
| Setzt die angegebenen Pins auf einen bestimmten Pegel (HIGH / LOW)
|-
| '''IOCLR'''
| Setzt den Zustand des angegebenen Pins auf 0
|-
| '''IODIR'''
| Bestimmt welcher Pin ein Ausgang(1) bzw. ein Eingang(0) ist.
|}

In dem folgenden Code wird der Port 25 von PORT0 auf Ausgang geschaltet und danach auf HIGH gelegt:

<pre class="code">
#include <arch/philips/lpc2114.h>

int main(void){
GPIO0_IODIR|=(1<<25); // Pin 25 auf Ausgang setzen
GPIO0_IOSET|=(1<<25); // Pin 25 auf HIGH schalten

while(1){ // Endlos-Schleife
}
return 0;
}
</pre>

Wenn man einen Pin wieder auf LOW schalten möchte benutzt man IOCLR().

<pre class="code">
#include <arch/philips/lpc2114.h>

int main(void){
GPIO0_IODIR|=(1<<25); // Pin 25 auf Ausgang setzen
GPIO0_IOSET|=(1<<25); // Pin 25 auf HIGH schalten
for(int i=0;i<300000;i++){ // Etwas warten
asm volatile("nop");
}
GPIO0_IOCLR|=(1<<25); // Pin 25 auf LOW schalten

while(1){ // Endlos-Schleife
}
return 0;
}
</pre>

Doch wie geht man nun mit dem Setzen und Löschen einzelner Bits um?
In Variablen/Register benutzt man am besten logische Verknüpfungen wie sie bereits im AVR-GCC-Tutorial beschrieben werden:

<pre class="code">
x |= (1 << Bitnummer); // wird ein Bit in x gesetzt
x &= ~(1 << Bitnummer); // wird ein Bit in x geloescht
</pre>

Wenn man allerdings mit den I/O Ports arbeitet sollte man die IOSET und IOCLR Register benutzen:

<pre class="code">
GPIO0_IOSET|=(1<<25); // Pin 25 auf HIGH schalten
GPIO0_IOCLR|=(1<<25); // Pin 25 auf LOW schalten
</pre>

== Systemeinstellungen (System Control Block)==
Dass ein ARM generell komplexer als ein handelsüblicher AVR oder PIC ist sollte jedem geläufig sein. Hier kann man am Controller jede Menge (falsch) einstellen.
In diesem Abschnitt werden die verschiedenen Register und ihre Bedeutungen beim LPC2xxx erklärt:

===Phase locked loop===
{| border=1
| '''PLLCFG (SCB_PLLCFG)'''
| Das PLL Configuration Register hält den Multiplikator für die interne PLL Schaltung. Diese ermöglicht es die Taktrate des Prozessors zu erhöhen.Zum Beispiel: Ein angeschlossener Quarz mit 10 MHz x 4 (mithilfe von PLL) = 40 MHz Prozessortakt. Bei Bedarf kann auch ein Teiler eingestellt werden.
|-
| '''PLLCON (SCB_PLLCON)'''
| Mit dem PLL Control Register kann der PLL aktiviert werden
|-
| '''PLLSTAT (SCB_PLLSTAT) '''
| Im PLL Status Register werden Informationen bezüglich des PLL gespeichert, z.B. der aktuelle Multiplikator-Wert etc.
|-
| '''PLLFEED (SCB_PLLFEED)'''
| Damit Änderungen an PLLCON und PLLCFG übernommen werden muss erst in dieses Register eine "Feed-Sequenz" geschrieben werden. Die Feed-Sequenz wird im Codebeispiel weiter unten dargestellt
|}

Hier ein Codebeispiel zur Initialisierung:
<pre class="code">
int PLOCK;
PLOCK=(1<<10); // Das PLOCK Bit gibt an, ob der PLL auf die konfigurierte Frequenz eingestellt ist

SCB_PLLCFG = 4-1; // Multiplikator auf 4 stellen
SCB_PLLCON = 0x01; // PLL aktivieren

SCB_PLLFEED = 0xAA; //PLL Feed-Sequenz
SCB_PLLFEED = 0x55;
while ( !( SCB_PLLSTAT & PLOCK ) ); // Darauf warten, dass die Änderungen übernommen werden

SCB_PLLCON = 0x03; // PLL aktivieren und mit dem internen Taktgeber verbinden
SCB_PLLFEED=0xAA; //PLL Feed Sequence
SCB_PLLFEED=0x55;
</pre>

Warum SCB_PLLCFG=4-1; ? Der Multiplikatorwert 1 wird mit 0 dargestellt. Ein 2x Multiplikator wäre 1 , ein 3x Multiplikator wäre 2 ....
Man muss also immer "1" von dem gewünschten PLL Wert abziehen.

Weitere Informationen zum PLL findet man im User Manual( bei LPC2124 ab Seite 60 ).

=== VPBDivider ===
Die gesamte Peripherie ( SPI, UART, etc. ) des ARMs hängt am sogenannten "VLSI Peripheral Bus". Mithilfe des VPBDIV Registers kann man die Taktfrequenz dieses Buses einstellen.

<pre class="code">
SCB_VPBDIV = 1; // Teiler auf 1 stellen; Prozessor-Takt=Peripherie-Takt
</pre>
Gebrauchen kann man das wenn man die gesamte Peripherie des Systems drosseln möchte. Der Peripherie-Takt kann ohne Probleme so schnell sein wie der Prozessor-Takt.

=== Zwischenstand ===
Generell sollte man Dinge wie Multplikator und die Quarz-Taktfrequenz am Anfang seines Programms definieren, z.B. so:

<pre class="code">
#define FOSC 14745000 // Quarzfrequenz
#define PLL_M 4 // PLL Multiplikator
#define VPBDIV_VAL 1 // Teiler des Peripherie-Takts
</pre>

== UART ==
Um den UART zu aktivieren sind in der Minimalkonfiguration folgende Register nötig(n steht für den jeweiligen UART):
{| border=1
| '''UARTn_LCR'''
| Das Line Control Register bestimmt das Format wie die Daten empfangen oder gesendet werden.
|-
| '''UARTn_DLL/UARTn_DLM'''
| In diesen Registern wird der Frequenzteiler hinterlegt, damit der Baudratengenerator eine richtige BAUD erzeugt.
|-
| '''UARTn_FCR'''
| Im FIFO Control Register kann man Einstellungen am FIFO des jeweiligen UARTs vornehmen.
|}

Für den Datenverkehr sind folgende Register definiert:
{| border=1
| '''UARTn_RBR'''
| Das Recieve Buffer Register beinhaltet alle empfangenen Datenbytes.
|-
| '''UARTn_THR'''
| Im Transmitter Holding Register werden die Daten abgelegt, die über den UART versendet werden sollen.
|}

== Weitere Informationsquellen ==
* [http://www.hitex.co.uk/arm/lpc2000book/index.html Das LPC2000 Book]
* [http://www.semiconductors.philips.com/pip/LPC2124.html#applications Application Notes von Philips]
* [http://groups.yahoo.com/group/lpc2000/ Yahoo Group "LPC2000"]
* [http://www.mikrocontroller.net/articles/LPC2000_Philips_ARM7TDMI-Familie LPC2000 Wiki Eintrag auf µC.net]
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects WinARM und viele Beispielcodes]
* [[ARM-DevCpp]]: DevC++ für Cross-Compilieren auf ARM konfigurieren

== Nützliche Threads ==
Hier landen Threads aus dem Mikrocontroller.net Forum die sich mit dem Thema ARM beschäftigen. Zum größten Teil sind dies besonders nützliche Threads oder solche, die über den Threadtitel nicht als ARM-Thread identifiziert werden können

* [http://www.mikrocontroller.net/forum/read-1-243735.html Internes und externes RAM]
* [http://www.mikrocontroller.net/forum/read-1-243278.html Smalltalk mit einem Philips-Mitarbeiter]
* [http://www.mikrocontroller.net/forum/read-1-243596.html LPC2292 und DRAM]
* [http://www.mikrocontroller.net/forum/read-1-241416.html Olimex E2124 mit WinARM programmieren]
* [http://www.mikrocontroller.net/forum/read-1-235784.html Atmel ARM7 woher?]
* [http://www.mikrocontroller.net/forum/read-1-240716.html Stromaufnahme vs. Speed]
* [http://www.mikrocontroller.net/forum/read-1-244434.html Spannungsregler für ARM Mikrocontroller]
* [http://www.mikrocontroller.net/forum/read-1-245066.html ARM - Welche Entwicklungsumgebung ? Welches JTAG-Interface ?]
* [http://www.mikrocontroller.net/forum/read-1-245332.html Brauche ich einen JTAG Adapter?]
* [http://www.mikrocontroller.net/forum/read-1-247592.html AVR <-> ARM Vergleich]
* [http://www.mikrocontroller.net/forum/read-1-247048.html Ein paar Fragen zum LPC]
* [http://www.mikrocontroller.net/forum/read-1-249621.html Fragen zum LPC2106]

ARM-elf-GCC-Tutorial

2005-10-22T18:59:18Z

Clemens Helfmeier: /* Weitere Informationsquellen */

[[Category:ARM]]

Dieses Tutorial behandelt die Programmierung von ARM Mikrocontrollern mithilfe des ARM-elf-GCC Compilers. Die meisten Codebeispiele wurden mit WinARM übersetzt.
Vorerst wird sich dieses Tutorial an die '''[http://www.mikrocontroller.net/articles/LPC2000_Philips_ARM7TDMI-Familie LPC Reihe von Philips]''' richten. Im späteren Verlauf werden allerdings auch ARM Mikrocontroller von Atmel (SAM7 & co.) behandelt.

== Bezugsquellen ==
Komplette Boards mit ARM7 Kern kann man von folgenden Webseiten beziehen:
* [http://shop.mikrocontroller.net/ Mikrocontroller.net]
* [http://www.olimex.com/dev/index.html Olimex]
* [http://www.embeddedartists.com/ Embedded Artists]
* [http://www.keil.com/dd/arm7chips.asp Keil]

Wenn man allerdings selbst ein ARM7 Board herstellen möchte kann man die Schaltpläne von den Olimex Boards als gute Grundlage nehmen.

== Benötigte Programme ==
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html WinARM] Entwicklungsumgebung
* Alternativ zu Winarm: [http://www.gnuarm.com/ GNU ARM]
* [http://www.semiconductors.philips.com/files/markets/microcontrollers/philips_flash_utility.zip Philips Flashtool] Offizielles Programmiertool für Windows

* Optional: [http://guest.engelschall.com/~martin/lpc21xx/isp/ lpc21isp] Kommandozeilen-Programmiertool für Windows & Linux

== Startprobleme ==
Wenn man vor den ersten Versuchen mit ARM Mikrocontrollern mit WinAVR und ähnlichen Entwicklungsumgebungen programmiert hat musste man außer seinem C Code und dem daraus entstehenden HEX-File nicht viel beachten.
Bei der Programmierung von ARM-Mikrocontrollern muss man aber bedenken, dass es (noch? ;-) ) keine Standard - Linkerscripte und Startupcodes in WinARM gibt.
WinAVR nimmt einem diese Arbeit mit Standard-Files ab, so dass man bei WinAVR meistens nicht in Berührung damit kommt. Im Netz kursieren viele dieser Linkerscripte und Startupcodes. Wir empfehlen die von uns getesteten Scripte zu verwenden damit keine unschönen Phänomene auftreten (Keine Interrupts z.B.).
// Scripte befinden sich vorerst in den WinARM Examples.

== Bevor wir starten ==
Im '''[http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial AVR-GCC Tutorial]''' werden grundlegende Basics erklärt, die sicherlich nützlich sind (Makefiles, Programmablauf in einem Mikrocontroller, etc.). Wir möchten hiermit auf das AVR-GCC-Tutorial verweisen und gehen nicht nochmal auf diese Themen ein.

Außerdem sollte man sich vergewissern dass der Controller mithilfe des Bootloaders angesprochen werden kann. Hierzu verwendet man am besten das Flash Tool von Philips um die DEVICE PART ID auszulesen. Falls dies fehlschlägt sollte man seine Verbindung mit dem Mikrocontroller überprüfen.

=== Länge von Variablentypen ===
Die Länge der jeweiligen Variablentypen unterscheidet sich durchaus von denen des AVRs.
Folgendes ist beim ARM-elf-GCC Compiler gültig:
{| border=1
| '''char'''
| 1 Byte
|-
| '''short'''
| 2 Bytes
|-
| '''int'''
| 4 Bytes
|-
| '''long'''
| 4 Bytes
|-
| '''double'''
| 8 Bytes
|}

== Das erste Programm ==
Die meisten Sourcecodes wurden für einen LPC2124 mit WinARM compiliert. Hierbei muss man beachten, dass in einigen Header Files die Register (z.B. IOSET, IOCLR etc.) unterschiedliche Namen haben. Ein Blick in das Header File welches includet wird ist daher ratsam.

Beispiel:
lpc2114.h aus <arch/philips/lpc2114.h> (Auch gültig für LPC2124)

<pre class="code">
/*##############################################################################
## GPIO - General Purpose I/O
##############################################################################*/

#define GPIO0_IOPIN (*(REG32 (0xE0028000)))
#define GPIO0_IOSET (*(REG32 (0xE0028004)))
#define GPIO0_IODIR (*(REG32 (0xE0028008)))
#define GPIO0_IOCLR (*(REG32 (0xE002800C)))

#define GPIO1_IOPIN (*(REG32 (0xE0028010)))
#define GPIO1_IOSET (*(REG32 (0xE0028014)))
#define GPIO1_IODIR (*(REG32 (0xE0028018)))
#define GPIO1_IOCLR (*(REG32 (0xE002801C)))
</pre>

Verwendet man z.B. einen LPC2106 und bindet "lpc210x_keil.h" aus <arch/philips/lpc210x_keil.h> ein bekommt man folgende Namen:

<pre class="code">
/* General Purpose Input/Output (GPIO) */
#define IOPIN (*((volatile unsigned long *) 0xE0028000))
#define IOSET (*((volatile unsigned long *) 0xE0028004))
#define IODIR (*((volatile unsigned long *) 0xE0028008))
#define IOCLR (*((volatile unsigned long *) 0xE002800C))
</pre>

Daher:
Wenn Registernamen beim Compilieren nicht bekannt sind hilft ein Blick in das Header File des Controllers weiter.

=== Nutzung der I/O Ports ===
Zum Behandeln von I/O Ports sind die Register "IOPIN", "IOSET", "IOCLR" und "IODIR" nötig.
{| border=1
| '''IOPIN'''
| Liest die Zustände des angegebenen Ports ein
|-
| '''IOSET'''
| Setzt die angegebenen Pins auf einen bestimmten Pegel (HIGH / LOW)
|-
| '''IOCLR'''
| Setzt den Zustand des angegebenen Pins auf 0
|-
| '''IODIR'''
| Bestimmt welcher Pin ein Ausgang(1) bzw. ein Eingang(0) ist.
|}

In dem folgenden Code wird der Port 25 von PORT0 auf Ausgang geschaltet und danach auf HIGH gelegt:

<pre class="code">
#include <arch/philips/lpc2114.h>

int main(void){
GPIO0_IODIR|=(1<<25); // Pin 25 auf Ausgang setzen
GPIO0_IOSET|=(1<<25); // Pin 25 auf HIGH schalten

while(1){ // Endlos-Schleife
}
return 0;
}
</pre>

Wenn man einen Pin wieder auf LOW schalten möchte benutzt man IOCLR().

<pre class="code">
#include <arch/philips/lpc2114.h>

int main(void){
GPIO0_IODIR|=(1<<25); // Pin 25 auf Ausgang setzen
GPIO0_IOSET|=(1<<25); // Pin 25 auf HIGH schalten
for(int i=0;i<300000;i++){ // Etwas warten
asm volatile("nop");
}
GPIO0_IOCLR|=(1<<25); // Pin 25 auf LOW schalten

while(1){ // Endlos-Schleife
}
return 0;
}
</pre>

Doch wie geht man nun mit dem Setzen und Löschen einzelner Bits um?
In Variablen/Register benutzt man am besten logische Verknüpfungen wie sie bereits im AVR-GCC-Tutorial beschrieben werden:

<pre class="code">
x |= (1 << Bitnummer); // wird ein Bit in x gesetzt
x &= ~(1 << Bitnummer); // wird ein Bit in x geloescht
</pre>

Wenn man allerdings mit den I/O Ports arbeitet sollte man die IOSET und IOCLR Register benutzen:

<pre class="code">
GPIO0_IOSET|=(1<<25); // Pin 25 auf HIGH schalten
GPIO0_IOCLR|=(1<<25); // Pin 25 auf LOW schalten
</pre>

== Systemeinstellungen (System Control Block)==
Dass ein ARM generell komplexer als ein handelsüblicher AVR oder PIC ist sollte jedem geläufig sein. Hier kann man am Controller jede Menge (falsch) einstellen.
In diesem Abschnitt werden die verschiedenen Register und ihre Bedeutungen beim LPC2xxx erklärt:

===Phase locked loop===
{| border=1
| '''PLLCFG (SCB_PLLCFG)'''
| Das PLL Configuration Register hält den Multiplikator für die interne PLL Schaltung. Diese ermöglicht es die Taktrate des Prozessors zu erhöhen.Zum Beispiel: Ein angeschlossener Quarz mit 10 MHz x 4 (mithilfe von PLL) = 40 MHz Prozessortakt. Bei Bedarf kann auch ein Teiler eingestellt werden.
|-
| '''PLLCON (SCB_PLLCON)'''
| Mit dem PLL Control Register kann der PLL aktiviert werden
|-
| '''PLLSTAT (SCB_PLLSTAT) '''
| Im PLL Status Register werden Informationen bezüglich des PLL gespeichert, z.B. der aktuelle Multiplikator-Wert etc.
|-
| '''PLLFEED (SCB_PLLFEED)'''
| Damit Änderungen an PLLCON und PLLCFG übernommen werden muss erst in dieses Register eine "Feed-Sequenz" geschrieben werden. Die Feed-Sequenz wird im Codebeispiel weiter unten dargestellt
|}

Hier ein Codebeispiel zur Initialisierung:
<pre class="code">
int PLOCK;
PLOCK=(1<<10); // Das PLOCK Bit gibt an, ob der PLL auf die konfigurierte Frequenz eingestellt ist

SCB_PLLCFG = 4-1; // Multiplikator auf 4 stellen
SCB_PLLCON = 0x01; // PLL aktivieren

SCB_PLLFEED = 0xAA; //PLL Feed-Sequenz
SCB_PLLFEED = 0x55;
while ( !( SCB_PLLSTAT & PLOCK ) ); // Darauf warten, dass die Änderungen übernommen werden

SCB_PLLCON = 0x03; // PLL aktivieren und mit dem internen Taktgeber verbinden
SCB_PLLFEED=0xAA; //PLL Feed Sequence
SCB_PLLFEED=0x55;
</pre>

Warum SCB_PLLCFG=4-1; ? Der Multiplikatorwert 1 wird mit 0 dargestellt. Ein 2x Multiplikator wäre 1 , ein 3x Multiplikator wäre 2 ....
Man muss also immer "1" von dem gewünschten PLL Wert abziehen.

Weitere Informationen zum PLL findet man im User Manual( bei LPC2124 ab Seite 60 ).

=== VPBDivider ===
Die gesamte Peripherie ( SPI, UART, etc. ) des ARMs hängt am sogenannten "VLSI Peripheral Bus". Mithilfe des VPBDIV Registers kann man die Taktfrequenz dieses Buses einstellen.

<pre class="code">
SCB_VPBDIV = 1; // Teiler auf 1 stellen; Prozessor-Takt=Peripherie-Takt
</pre>
Gebrauchen kann man das wenn man die gesamte Peripherie des Systems drosseln möchte. Der Peripherie-Takt kann ohne Probleme so schnell sein wie der Prozessor-Takt.

=== Zwischenstand ===
Generell sollte man Dinge wie Multplikator und die Quarz-Taktfrequenz am Anfang seines Programms definieren, z.B. so:

<pre class="code">
#define FOSC 14745000 // Quarzfrequenz
#define PLL_M 4 // PLL Multiplikator
#define VPBDIV_VAL 1 // Teiler des Peripherie-Takts
</pre>

== UART ==
Um den UART zu aktivieren sind in der Minimalkonfiguration folgende Register nötig(n steht für den jeweiligen UART):
{| border=1
| '''UARTn_LCR'''
| Das Line Control Register bestimmt das Format wie die Daten empfangen oder gesendet werden.
|-
| '''UARTn_DLL/UARTn_DLM'''
| In diesen Registern wird der Frequenzteiler hinterlegt, damit der Baudratengenerator eine richtige BAUD erzeugt.
|-
| '''UARTn_FCR'''
| Im FIFO Control Register kann man Einstellungen am FIFO des jeweiligen UARTs vornehmen.
|}

Für den Datenverkehr sind folgende Register definiert:
{| border=1
| '''UARTn_RBR'''
| Das Recieve Buffer Register beinhaltet alle empfangenen Datenbytes.
|-
| '''UARTn_THR'''
| Im Transmitter Holding Register werden die Daten abgelegt, die über den UART versendet werden sollen.
|}

== Weitere Informationsquellen ==
* [http://www.hitex.co.uk/arm/lpc2000book/index.html Das LPC2000 Book]
* [http://www.semiconductors.philips.com/pip/LPC2124.html#applications Application Notes von Philips]
* [http://groups.yahoo.com/group/lpc2000/ Yahoo Group "LPC2000"]
* [http://www.mikrocontroller.net/articles/LPC2000_Philips_ARM7TDMI-Familie LPC2000 Wiki Eintrag auf µC.net]
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects WinARM und viele Beispielcodes]
* [[ARM-DevCpp DevC++ für Cross-Compilieren auf ARM konfigurieren]]

== Nützliche Threads ==
Hier landen Threads aus dem Mikrocontroller.net Forum die sich mit dem Thema ARM beschäftigen. Zum größten Teil sind dies besonders nützliche Threads oder solche, die über den Threadtitel nicht als ARM-Thread identifiziert werden können

* [http://www.mikrocontroller.net/forum/read-1-243735.html Internes und externes RAM]
* [http://www.mikrocontroller.net/forum/read-1-243278.html Smalltalk mit einem Philips-Mitarbeiter]
* [http://www.mikrocontroller.net/forum/read-1-243596.html LPC2292 und DRAM]
* [http://www.mikrocontroller.net/forum/read-1-241416.html Olimex E2124 mit WinARM programmieren]
* [http://www.mikrocontroller.net/forum/read-1-235784.html Atmel ARM7 woher?]
* [http://www.mikrocontroller.net/forum/read-1-240716.html Stromaufnahme vs. Speed]
* [http://www.mikrocontroller.net/forum/read-1-244434.html Spannungsregler für ARM Mikrocontroller]
* [http://www.mikrocontroller.net/forum/read-1-245066.html ARM - Welche Entwicklungsumgebung ? Welches JTAG-Interface ?]
* [http://www.mikrocontroller.net/forum/read-1-245332.html Brauche ich einen JTAG Adapter?]
* [http://www.mikrocontroller.net/forum/read-1-247592.html AVR <-> ARM Vergleich]
* [http://www.mikrocontroller.net/forum/read-1-247048.html Ein paar Fragen zum LPC]
* [http://www.mikrocontroller.net/forum/read-1-249621.html Fragen zum LPC2106]

ARM-DevCpp

2005-10-22T17:22:42Z

Clemens Helfmeier: /* Zusammenfassung */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| '''Dateiname'''
| '''Inhalt'''
| '''Einstellungen bei''' '''Projekt Optionen'''->'''Dateien'''
|-
| Board.h
| Board-Definitionen
| keine Änderungen möglich (Header-Datei), nicht zwingend erforderlich
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Board.h'': Definitionen für das verwendete System (nicht zwingend erforderlich)
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]
* [[ARM-elf-GCC-Tutorial]]

ARM-DevCpp

2005-10-22T17:22:01Z

Clemens Helfmeier: /* Links */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| '''Dateiname'''
| '''Inhalt'''
| '''Einstellungen bei''' '''Projekt Optionen'''->'''Dateien'''
|-
| Board.h
| Board-Definitionen
| keine Änderungen möglich (Header-Datei), nicht zwingend erforderlich
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]
* [[ARM-elf-GCC-Tutorial]]

ARM-DevCpp

2005-10-22T17:18:45Z

Clemens Helfmeier: /* Dateieinstellungen */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| '''Dateiname'''
| '''Inhalt'''
| '''Einstellungen bei''' '''Projekt Optionen'''->'''Dateien'''
|-
| Board.h
| Board-Definitionen
| keine Änderungen möglich (Header-Datei), nicht zwingend erforderlich
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T17:18:28Z

Clemens Helfmeier: /* Dateieinstellungen */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| '''Dateiname'''
| '''Inhalt'''
| '''Einstellungen bei '''Projekt Optionen'''->'''Dateien''' '''
|-
| Board.h
| Board-Definitionen
| keine Änderungen möglich (Header-Datei), nicht zwingend erforderlich
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T17:17:49Z

Clemens Helfmeier: /* Dateieinstellungen */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Board.h
| Board-Definitionen
| keine Änderungen möglich (Header-Datei)
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T17:16:46Z

Clemens Helfmeier: /* Atmel AT91SAM7S-Serie */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. Wird die Datei ''Cstartup_c.c'' von Martin Thomas verwendet, so empfiehlt es sich, auch die Datei ''Board.h'' und ''AT91SAM7S64.h'' zu übernehmen.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T17:14:02Z

Clemens Helfmeier: /* Dateieinstellungen */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. In der ''Cstartup_c.c''-Dateien von Martin Thomas muss noch die Zeile ''#include "Board.h"'' durch ''#include <AT91SAM7S64.h>'' ersetzt werden.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Compiler''': Hier muss der richtige Compiler ausgewählt werden (''GNU ARM''), der rest kann gelassen werden (alles auf ''No'').
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Build Optionen''': Hier kann das Kästchen '''Überschreibe Ausgabe-Dateiname''' angewählt werden, wenn man keine *.exe Dateie erzeugen will. Ggf. ''ARM-C-Vorlage.elf'' eintragen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T17:04:20Z

Clemens Helfmeier: /* Dateieinstellungen */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. In der ''Cstartup_c.c''-Dateien von Martin Thomas muss noch die Zeile ''#include "Board.h"'' durch ''#include <AT91SAM7S64.h>'' ersetzt werden.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Make Datei''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T17:02:00Z

Clemens Helfmeier: /* Atmel AT91SAM7S-Serie */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas. In der ''Cstartup_c.c''-Dateien von Martin Thomas muss noch die Zeile ''#include "Board.h"'' durch ''#include <AT91SAM7S64.h>'' ersetzt werden.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Makefile''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T16:57:43Z

Clemens Helfmeier: /* Vorlage Projekt */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei'''->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Makefile''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T16:57:26Z

Clemens Helfmeier: /* Vorlage Projekt */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt '''Datei->'''Neu'''->'''Projekt''' und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Makefile''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T16:47:22Z

Clemens Helfmeier: /* Compiler einrichten */

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Dialog '''Werkzeuge'''->'''Compiler Optionen'''. Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt (Datei->Neu->Projekt) und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Makefile''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T16:45:18Z

Clemens Helfmeier:

[[Category:ARM]]

-- [[Benutzer:Clemens Helfmeier|Clemens Helfmeier]] 18:45, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Compiler-Dialog (Werkzeuge -> Compiler Optionen). Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt (Datei->Neu->Projekt) und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup_c.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup_c.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist. Davon also die Finger lassen ;-).
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Makefile''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

= Zusammenfassung =
Im Projektverzeichnis befinden sich nun folgende Dateien:
* ''ARM-C-Vorlage.dev'': DevC++-Projekt Datei
* ''ARM-C-Vorlage.layout'': DevC++-Datei
* ''Cstartup.S'': Assembler-Startup-Datei
* ''Cstartup_c.c'': C-Startup-Datei
* ''main.c'': C-Programm Datei
* ''Makefile.inc'': Zusätzliches Makefile
* ''mem.ld'': Linker-Script
Nach einer Erfolgreichen Kompilation und Linkung kommen folgende Dateien hinzu:
* ''ARM-C-Vorlage.elf'': Ergebnis des Linkers
* ''ARM-C-Vorlage.elf.bin'': Binärdatei für den Flash
* ''ARM-C-Vorlage.elf.lss'': Dissassemblierte Binärdatei
* ''Cstartup.o''
* ''Cstartup_c.o''
* ''main.o''
* ''Makefile.win'': Makefile von DevC++

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

ARM-DevCpp

2005-10-22T16:38:36Z

Clemens Helfmeier:

[[Category:ARM]]

-- [[Benutzer:84.191.33.140|84.191.33.140]] 18:33, 22. Okt 2005 (CEST)

Dieser Artikel beschreibt, wie man die Entwicklungsumgebung [http://www.bloodshed.net/dev/devcpp.html DevC++] so einstellt, dass sie mit dem [http://www.gnuarm.com/ GnuARM] Compiler arbeitet.

= Bezugsquellen =
* GNU ARM toolchain für Windows und Linux ist unter [http://www.gnuarm.com/ http://www.gnuarm.com/] zum kostenlosen Download erhältlich.
* DevC++ ist eine IDE für C und C++ von Bloodshed. Download unter [http://www.bloodshed.net/dev/devcpp.html http://www.bloodshed.net/dev/devcpp.html]

Die folgenden Schritte wurden mit DevC++ 4.9.9.2 gemacht.

= DevC++ Einrichten =

== Compiler einrichten ==
Zuerst muss man DevC++ mitteilen, dass auf dem System ein (weiterer) C-Compiler vorhanden ist. Dazu öffne man den Compiler-Dialog (Werkzeuge -> Compiler Optionen). Im '''Compiler Set konfigurieren'''-Abschnitt fügt man einen neuen Compiler durch betätigen der '''+'''-Taste hinzu, z.B. GNU ARM. Im folgenden ist wichtig, dass in der Auswahlliste neben der '''+'''-Taste der neu hinzugefügte Compiler ausgewählt ist (GNU ARM).

Beim Compileraufruf müssen einige Flags angefügt werden: '''Folgende Befehle beim Compiler-Aufruf hinzufügen''' ankreuzen und in das darunterliegende Textfeld folgendes Eintragen: ''-g -Os -std=c99''.
Der Code wird dann auf Größe optimiert und der C99 Standard verwendet (for (int i = 0; i<10; i++){ ... } ist erlaubt)

Ähnliches gilt für den Linker-Aufruf. Auch hier das Kächsten markieren und in das Textfeld darunter folgendes eintragen: ''-Tmem.ld -lc -lgcc -nostartfiles -g3 -nostdlib''.
Damit wird das Linkerscript mem.ld automatisch verwendet (dies ist bei Atmel's SAM7-Controller nötig).

In der Karteikarte '''Einstellungen''' sind i.A. keine Änderungen vorzunehmen. Der Compiler arbeitet einwandfrei, wenn alle Auswahlmöglichkeiten auf ''No'' stehen.

Als nächstes öffnet man die Karteikarte '''Verzeichnisse'''. Hier müssen die Verzeichnisse des Compilers eingestellt werden. Vorher ggf. vorhandene Verzeichnisse mit ''Löschen'' entfernen.
In der Kartei '''Programmdateien''' das Verzeichnis für die GNU ARM Compilerdateien durch Eintragen in die Textzeile unter der Liste und anschließendem Betätigen von '''Hinzufügen''' einfügen (''C:\Programme\GNUARM\bin'').
In der Kartei '''Bibliotheken''' muss das Verzeichnis ''lib'' eingefügt werden (''C:\Programme\GNUARM\lib'').
Die Kartei '''C-Includes''' ist etwas umfangreicher zu ergänzen: Hier müssen die Includes für den Compiler und den Controller eingefügt werden (''C:\Programme\GNUARM\include\atmel'' für den Controller und ''C:\Programme\GNUARM\arm-elf\include\'' für die allgemeinen Funktionen des Compilers).
Ähnliches gilt für die '''C++-Includes''', hier ist ''C:\Programme\GNUARM\include\c++\3.4.3'' nötig (noch nicht getestet, ggf. Unterverzeichnisse hinzufügen).

Nun ist die Umgebung schon fast fertig eingerichtet. In der Karteikarte '''Programme''' müssen nun noch die richtigen Programme ausgewählt werden: Als '''gcc''' wird ''arm-elf-gcc.exe'' eingetragen, als '''g++''' ''arm-elf-g++.exe'' und als '''gdb''' ''arm-elf-gdb.exe''. Nun kann dieser Dialog geschlossen werden.

== Vorlage Projekt ==
Als nächstes wird eine Vorlage gebraucht. Man erstelle ein neues Projekt (Datei->Neu->Projekt) und wähle in der Kategorie '''Basic''' ''Empty Project'' aus. Als Namen gebe man z.B. ''ARM-C-Vorlage'' an und wähle im rechten unteren Teil ''C-Projekt'' aus. Als nächstes wird gefragt, wo das Projekt angelegt werden soll. Danach wird ein leeres Projekt erzeugt.

Als erstes fügt man eine Haupt-Datei hinzu: '''Projekt'''->'''Neue Datei'''. Hier schreibt man eine Routine ''int main(void){ while(1); }'' mit einer Endlosschleife rein. Danach speichert man diese ('''Datei'''->'''Speichern''') unter dem Namen ''main.c''.

== Hersteller Spezifischer Code ==
Weiterhin muss dem Projekt noch der Startup-Code hinzugefügt werden ('''Projekt'''->'''Zum Projekt hinzufügen'''). Dieser ist je nach Zielkontroller ggf. etwas unterschiedlich.

=== Atmel AT91SAM7S-Serie ===
Für Atmel-Controller gibt es die Dateien ''Cstartup.c'' und ''Cstartup.S''. Gute Vorlagen dieser Dateien gibt es z.B. in den [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ AT91SAM7 Examples] von Martin Thomas.

=== Phillips LPC2100-Serie ===
Sanic: dein Part!

== Dateieinstellungen ==
Nun sind folgende Dateien vorhanden:
{| border=1
| Dateiname
| Inhalt
| Einstellungen bei '''Projekt Optionen'''->'''Dateien'''
|-
| Cstartup.S
| Assembler-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen'', ''Überschreibe Build Kommando'', Textfeld = ''$(CC) -c Cstartup.S -o Cstartup.o $(CFLAGS)''
|-
| Cstartup.c
| C-Startup-Code
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|-
| main.c
| C-Programm
| ''In Kompilation Einbeziehen'', ''Ins Linken einbeziehen''
|}

Als nächstes müssen noch einige Einstellungen für das Projekt vorgenommen werden: '''Projekt'''->'''Projekt Optionen''' öffnet das benötigte Dialogfenster. Hier ist folgendes Wichtig:
* Karteikarte '''Allgemein''': Der Projekt-Type muss ''Win32 Konsole'' sein,
* Karteikarte '''Dateien''': Auf jede Datei klicken und die Einstellungen aus der obigen Tabelle übernehmen. Meine DevC++ stürzt ab, sobal die Priorität von ''1000'' verschieden ist.
* Karteikarte '''Parameter''': Hier muss der Controllertyp angegeben werden: ''-mcpu=arm7tdmi'' sowohl in das '''Compiler'''- als auch in das '''C++-Compiler'''-Textfeld einfügen.
* Karteikarte '''Makefile''': Es muss ein externes Makefile eingefügt werden, um aus der *.elf Datei eine *.bin Datei zu erzeugen. Es kann auch gleich eine Disassemblierung veranlassen, näheres dazu weiter unten.

== Makefile ==
DevC++ erzeugt durch die Einstellungen automatisch ein Makefile (''Makefile.win''). Manchmal sind aber Erweiterungen hierzu nötig: Zuerst erstellt man eine neue Datei '''Datei'''->'''Neu'''->'''Quelldatei'''. Diese Datei braucht nicht dem Projekt hinzugefügt werden. Dann fügt man in diese folgendes ein:
<pre class="makefile">
OBJDUMP = arm-elf-objdump
OBJCOPY = arm-elf-objcopy

all-after:
$(OBJCOPY) -O binary $(BIN) $(BIN).bin
$(OBJDUMP) -h -S -d $(BIN) >> $(BIN).lss

clean-custom:
${RM} $(BIN).bin
${RM} $(BIN).lss
</pre>
Anschließend speichert man diese Datei unter dem Namen ''Makefile.inc'' im Projektverzeichnis ab und trägt in dem Dialog '''Projekt'''->'''Projekt Optionen''' in der Karteikarte '''Make Datei''' in die Liste den Eintrag ''Makefile.inc'' ein (darunterliegendes Textfenster benutzen). Diese Makefile erzeugt aus dem Ergebnis der Kompilation eine Binärdatei (für SAM-BA) und eine Disassemblierung (.lss).

== Linker-Script ==
Da der ARM fast immer über einen Assembler-Startup-Code gestartet und initialisiert wird, der nicht in den Standardbibliotheken enthalten ist, muss dem Linker noch mitgeteilt werden, dass der Assembler-Startup-Code ganz an den Anfang des Programms muss. Dies wird in der Datei mem.ld im Projektverzeichnis festgelegt. Diese gibt es z.B. in dem AT91SAM7S64-Beispiel von Martin Thomas, dort heisst sie allerdings ''AT91SAM7S64-ROM.ld'' und muss also umbenannt werden nach ''mem.ld''

Anschließend sollte das Projekt einwandfrei Kompilieren und eine ''*.elf.bin'' und ''*.elf.lss'' Datei erzeugen.

= Links =
* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Martin Thomas' ARM-Projekt Seite]

Logic Analyzer-Projekt: Ideen zur Hardware

2005-09-21T21:01:41Z

Clemens Helfmeier: /* Interface LA <-> DUT (Device under Test) */

hier mal das Lastenheft für den Logic Analyser (LA). Bitte je nach Anforderung einen Strich mittels ALT GR + <> Taste links neben dem Ypsilon.
Die Aufteilung könnt ihr ja ändern/erweitern falls was fehlt. Ich gebe mal meine Maximalanforderungen ein.

'''Kanalanzahl'''
* .8 Kanäle: ||
* 16 Kanäle: ||||| ||||
* 20 Kanäle: |
* 24 Kanäle: |
* 32 Kanäle: ||||
* Modulair (erweiterbar X mal 8/16 Kanäle): ||

'''Samplingfrequenz'''
* ...8 MHz : |
* ..16 MHz : |
* ..32 MHz : ||
* .>32 MHz : ||||| ||||| |||

'''Speichertiefe'''
*....32 kByte: |
*....64 kByte:
*...128 kByte: |
*...256 kByte: |
*...512 kByte:
*..1024 kByte: |

Anmerkung: Wäre es nicht sinnvoller, die Speichertiefe in "Samples" anzugeben. So macht das nicht viel Sinn, da die Anzahl der Samples wenn man immer nur 8 Bits abspeichert ne andere ist als wie wenn man 32 Bits pro Sample speichert.

'''integrierter Pattern Generator'''
* .8 Kanäle : |
* 16 Kanäle:

Anm.: könnte bis zu einer gewissen Geschwindigkeit vom AVR erledigt werden... => uU. Mega16 drauf
--[[Benutzer:Hans|Hans]] 14:16, 20. Jul 2005 (CEST)

'''Schnittstelle zum Computer'''
* Seriell syncron..........: |
* Seriell asyncron (RS232).: ||||
* USB......................: ||||| |||||||
* Parallelport.............: ||
* Ethernet.................: |

'''Am PC läuft/wird laufen'''
* Windows .: ||||| ||||
* Linux .: ||||| |||||
* MacOS X .: |
* Solaris .: |
* Anderes .:

----

= Status =

(--[[Benutzer:84.182.244.75|84.182.244.75]] 10:43, 20. Sep 2005 (CEST) [ope])

Da der Logic Analyzer (LA) Thread schnell wächst und entsprechend schwer zu verfolgen ist, ständig sich irgend etwas ändert, kommt hier eine Zusammenfassung der Diskussion. Ich versuche sie halbwegs aktuell zu halten, öfteres Vorbeischauen lohnt sich also.

Eine fertige Lösung existiert jeodch noch nicht und einer alleine macht sich tot, zumal derjenige ja auch ein Real-Life hat und kein professioneller Designer für LA ist - daher ist das Projekt auf aktive Hilfe angewiesen sonst wird es sterben!

Auch sind die Threads dazu etwas verteilt (thematisch). Hier die grossen:

* [http://www.mikrocontroller.net/forum/read-1-204570.html#new Logic Analyzer bauen] (Initialthread)
* [http://www.mikrocontroller.net/forum/read-1-208137.html#new Pegelkomparator für High-Speed-Digital (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-234597.html#new Logic Analyzer Core (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-207389.html#new CPLD und AVR Kombo (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-221618.html#new Diverse Fragen bezueglich SRAM Anbindung]
* [http://www.mikrocontroller.net/forum/read-4-228557.html#new Programmieren des CPLDs über den AVR]

Eine reine AVR Lösung scheint sich hier abzuzeichnen:

* [http://www.mikrocontroller.net/forum/read-1-225498.html#new Logic Analyzer bauen, die 2.]

= Das Ziel =

Nun ja, preiswert und universell und für den Großteil der Probleme brauchbar soll er sein. Zudem sollen die Bauteile z.B. auch in Schweiz/Österreich gut verfügbar sein. Dass er sich mit einem LA der großen Hersteller messen lassen kann, ist aufgrund des Hobby Bereiches bzw. Proof-on-Concepts eher unwahrscheinlich. Unter den eben genanntenn Prämissen sollen die verfügbaren Mittel optimal genutzt werden.

Je nach Ergebnis, Lust und Laune wird es irgendwann evtl. eine Fortsetzung geben - aber das ist Zukunftsmusik.

= Grundlegende Überlegungen =

Im Internet kann man verschiedene, einfache Konzepte für einen LA finden, z.B. mittels Parallelport. Forumgerecht, reicht für einen einfachen LA bereits ein Mikrokontroller aus, der seine Ports polled um so die Logik Pegel mitzuschneiden. Allerdings ist diese Lösung begrenzt, wenn es um höhere Taktraten geht.

Eine erschwingliche Alternative stellt ein CPLD (Complex programmable logic devices) dar. Die CPLD z.B. von Xilinx können mit über 100MHz arbeiten und sind somit für diese Aufgabe prädestiniert. Leider ist die Anzahl der Macro Zellen zu gering, um eine hohe Speichertiefe zu erreichen. Daher werden die Daten vom CPLD in einem SRAM geschrieben. Damit ist der CPLD für die Triggerbedingungen des LA, dem Speicherinterface und natürlich dem eigentlichen sampeln der Eingänge verantwortlich. Der Mikrokontroller liest die Daten des SRAM über den CPLD aus und schickt sie an den Computer, übernimmt also die Kommunikation. Die Software stellt die gesampelten Daten sinnvoll und ansprechend dar.

Um die Störungen gering zu halten, wird als Versorgungspannung 3.3V Vorzug gegeben - ironischer Weise sind die Xilinx CPLD XC95000XL mit dieser Spannung preiswerter als in der 5V Version.

= Die Komponenten =

== Der CPLD und das Speicherinterface ==

Nach einigen Hin- und Her hat sich der XC95144XL TQ144 als beste Option herausgestellt. Auch FPGAs waren kurz im Gespräch, aufgrund der sich im Gespräch heraustellenden Komplexität. Allerdings war die Komplexität des FPGA und der Preis auch gleichzeitig das KO-Kriterium dafür.

Kurzinfo XC95144XL TQ144 [http://www.mhl.tuc.gr/data_books/Xilinx/Xc9500/95144XL.pdf]:

* 144Macro, 3.3V, 117 I/O, TQFP144 für ca. 10€

Dieser bietet genug I/O um:

* 2x SRAM 256k x 16 (jeweils 18 AD, 16 DB, 3 Ctrl)
* 2x 8-bit-LA-Channel
* Ext. TriggerIn, TriggerOut
* SPI Bus zum AVR
* JTAG

anschliessen zu können.

Der Grund für die 2 Speicherbänke liegen in den Möglichkeiten, sich den LA selbst zu konfigurieren für:

* Interleave
* Speicherung eines Timestamp
* non-Interleave und non-Timestamp mit nur einem SRAM

Beim Interleave werden zwei 16 Bit Samples im CPLD gelatched und gemeinsam auf den nun 32bit breiten Datenbus gelegt. Dabei sind die Adressen für die SRAMs folglich identisch. Damit beträgt die SChreibrate beim SRAM bei der Hälfte des Sampleclocks, der entsprechend hoch gesetzt werden kann.

Bei Verwendung des 2x 256k x 16 Bit SRAM eröffnet sich aber weiterhin die Möglichkeit, den Transitional Timing Analysis Mode zu realisieren, d.h. nur Bit-Änderungen werden mit einem Timestamp gespeichert - also ideal für langsame Busse bei hohen Sampleraten. Hier kann man zB. eine 16bit Time-Stamp-Adresse (256k) mit einem 16bit Pattern speichern, oder ein 24bit Timestamps für 8bit. Ein Interleave ist dann allerdings nicht mehr möglich.

Als letze Möglichkeit kann man auf alles obige Verzichten und nur einen SRAM bestücken.

Der heisseste Kandidat für den Speicher ist derzeit die 61LV25616 (256k*16) asynchrone Serie (zB.[http://www.issi.com/pdf/61LV25616AL.pdf IS61LV25616]), da er gut verfügbar und preiswert sein soll. Bei asynchronen SRAM müssen wie eingangs erwähnt die Adressen und Daten in einem Latch zwischen gespeichert werden. Bei einem synchronen SRAM werden die Adressen bei mit Flanke gespeichert, ebenso die Daten. Die Setup und Hold Zeiten gehen daher gegen Null... Außerdem muss man WR\ nicht toggeln, was wertvolle Zeit kostet, sondern es reicht, den Speichertakt anzulegen.

Weitere Typen wären

Asynchrone SRAM:

* CY22393,CY22394,CY22395 [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22393_4_5_5.pdf] mit Layout Hinweisen [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Layout%20Recommendations%20for%20the%20CY2239x%20Devices]
* AS7C34098-12TCN (256K x 16, 12ns) [http://www.alsc.com/pdf/sram.pdf/fa/AS7C4098.pdf] und AS7C31026B-12TCN (64k x 16, 12ns) Asynchroner SRAM bei Farnell

Synchrone SRAM:

* CY7C1327G (256k*18) [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327g_5.pdf]
* CY7C1327F (256k*18) [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327f_5.pdf]
* CY7C1327B (256k*18 Synchronous-Pipelined Cache RAM)[http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598266]

Den CY7C1327B (TQFP100 256Kx18, 3.3V, 4ns ) gibt's zumindest bei R&S für 11,60€

== Interface CPLD <-> uC ==

Eine grundlegende Idee ist, dass der CPLD doppelt benutzt wird. Er enthält ja einen Addresszähler zum Schreiben des SRAM's. Dieser kann aber auch zum Lesen des SRAM's benutzt werden. Der SRAM wird immer sequentiell vom PLD geschrieben und gelesen.

Die Daten, Statusinfos etc. werden per SPI vom AVR aus dem CPLD gelesen. Vorteil ist dabei, dass man nun auch z.B. 512Kb SRAM's benutzen kann ohne dass der uC ein kompliziertes Memory Banking benutzen müsste.

== Interface uC <-> Computer ==

Da die Daten schnell im PC sein sollen, bietet sich USB an, also mit dem
[http://www.ftdichip.com/Documents/DataSheets/ds245b16.pdf FT245]
um schneller (2-3 Mbaud) als der
[http://www.ftdichip.com/Documents/DataSheets/ds232b17.pdf FT232] (1 Mbaud)
die Daten zu versenden. FTDI bietet die Treiber für Windows/Linux kostenlose an.

Eine Alternative ist der
[http://www.silabs.com/public/documents/tpub_doc/dshort/Microcontrollers/Interface/en/CP2102_short.pdf CP2102], der weniger Bauelemente benötigt aber auch wesentlich schwerer zu löten ist.

uC mit integrierten USB standen auch in der Disskusion. Aufgrund vieler Unwägbarkeiten, wie Beschaffung, Preis, HID Treiber etc. sind diese Ideen wieder verworfen worden.

== Interface LA <-> DUT (Device under Test) ==

Prinzipiell gibt es zwei Wege, wie der LA an seine Informationen kommt:
* Der rein digitale Weg geht z.B. über 74AHC245 oder 74ACT14 o.ä. womit allerdings die Logikpegel feststehen.
* Ein anderer Weg geht über Analog-Komparatoren, bei denen die Logikpegel (Treshold) variabel sind und somit auch am flexibelsten für die versch. Logikfamilien [http://www.mikrocontroller.net/attachment.php/209385/Scan0004.png] ist.

Für die Komparatorlösung steht momentan der [http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf MAX964] und
[http://www.analog.com/UploadedFiles/Data_Sheets/155150085AD8564_a.pdf AD8564]
zur Debatte. Allerdings ist der MAX964 schwer zu beschaffen und bereits in der Dualvariante teurer als der AD8564 (ca. 10 Euro). Auch müssen diese mit 5V betrieben werden (wegen der TTL Eingänge und das der Eingspg.bereich von der VCC abhängt), wodurch Pegelwandler wie der 74LVC245 zum CPLD notwendig werden. Auch die Treshold-Reference muss in diesem Bereich liegen. Diese Schwelle wird durch einen DAC vorgegeben, der vom uC über SPI gesteuert wird. Dieser sollte eine interne Referenz besitzen um mit möglichst wenig Bauelementen auszukommen. Zudem sollte er über zwei Kanäle verfügen, da aktuell der LA über 2 pods mit jeweils einem 8 Bit-Channel verfügen soll. Z.Zt. scheint die beste Wahl hinsichtlich Parameter, Preis und Verfügbarkeit die [http://focus.ti.com/lit/ds/symlink/tlv5626.pdf TLV5626], [http://focus.ti.com/lit/ds/symlink/tlv5637.pdf TLV5637] und [http://focus.ti.com/lit/ds/symlink/tlv5638.pdf TLV5638] mit 8, 10 bzw. 12 Bit zu sein. Der Einsatz eines DAC wird wesentlich einfacher als eine PWM per uC mit anschließenden Tiefpaß mit OPVs, welches die Fehlerrate steigen lassen kann.

Bei einem digitalen Eingangsteil bietet sich folgendes an:
*[http://www.semiconductors.philips.com/acrobat/datasheets/74LVC14A_4.pdf 74lvc14] Hex inverting Schmitt-trigger with 5 V tolerant input; Dummerweise eben 6 Stck. - für 0,56? bei R&S
*[http://www.semiconductors.philips.com/acrobat_download/datasheets/74LVC541A_3.pdf 74LVC541] Octal buffer/line driver with 5 V tolerant inputs/outputs (3-state) für 0,71? bei R&S
*[http://www.semiconductors.philips.com/acrobat_download/datasheets/74HC_HCT7541_CNV_2.pdf 74HC7541] Octal Schmitt trigger buffer/line driver; 3-state für 9,85? bei R&S - damit können gerade langsame Busse untersucht werden da die Eingänge nicht so fürchterlich empfindlich sind; ansonsten ist es ein 541. Leider scheint es ihn nicht in der 74lvc zu geben.

Einigkeit besteht darüber, dass verschiedene Eingangsoptionen möglich sein sollen. Dies wird dadurch erreicht, dass die Hauptplatine als Eingangsbauteil einen 5V-toleranten Schmitt Trigger erhält. Damit ist es jedem selber überlassen, ob er zusätzlich eine Komparatorplatine baut, oder ob er sich mit der einfachen Variante zufrieden gibt. Die Eingangsplatine wird zusätzlich noch mit 3,3V Versorgung und einem SPI Bus versorgt (2x CS).

Mit dem Grundkonzept (digitaler Eingangsteil) werden wahrscheinlich 90% der Interessenten zufrieden sein. Dadurch bleibt der Preis der "Basisvariante" auch im bezahlbaren Bereich.

Einigkeit besteht jedoch in der notwendigen Schutzschaltung, z.B. mit einem Dioden-Array. Auch darf die Eingangsspannung den Input Voltage Range (je nach Typ) nicht überschreiten.

== Clock Rate Generierung ==

Aufgrund seiner Bandbreite bietet sich die Generierung des Systemtaktes durch den CPLD an. Dieser benutzt einen 1/N Teiler um den Sample Takt zu generieren.

Prinzipiell kann er auch gleichzeitig den Takt für den uC erzeugen - dieser wird also extern getaktet und man erhält dadurch Synchronität zwischen CPLD und uC und spart den Quarz am uC. Allerdings bieted sich auch ein eigener Quarz für den uC an. Man sieht - hier wird noch diskutiert.

Zur Generierung des Mastertaktes bieten sich zwei Weg an:
* Quarz, bei 50-64 MHz dürfte da wegen Verfügbarkeit/Preis wohl Schluss sein, auch sind Obertonquarze nicht ganz unkritisch. Auch kann man dann nur noch durch umlöten und wecheln den Mastertakt ändern, falls es Probleme gibt.
* VCO/PLL ggf. per uC programmierbar, damit kann man dann echt die Grenzen des Designs austesten. Die Chips dazu gibt's bei Maxim/AD und den anderen üblichen Verdächtigen, stehen also noch nicht fest. Als aussichtsrechster Kandidat sticht derzeit der [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22150_5.pdf CY22150] hervor, der mehrere synchrone Freq. mit einem einfachen Quarz erzeugen kann. Dadurch wird der Freq.teiler im CPLD nicht mehr benötigt und hat wieder einige MC frei.

Die Grenzen der Samplefreq. liegen zum einem in den verwendeten Bauelementen (>100MHz), aber vielmehr wird der begrenzende Faktor das Layout und die Leiterplatte sein. Ein 4-Layer-PCB ist aus technischer Sicht sicher das optimale, nur schaut der Geldbeutel danach sehr leer aus; auch wird ein Komparatoreingang ca. 45 Euro teurer werden als eine Lösung mit 74xxx.

== Stromversorgung ==

Tja, auch ein LA braucht Strom. Bei Verwendung eines USB kann dieses elegant gelöst werden, da dieser (nach Anforderungen an das OS) bis zu 500mA liefern kann. Eine kurze worst-case "Stromrechnung" zeigt:

* XC95144XL CPLD pauschal 150mA lt. DB
* 61LV25616 SRAM 2x 320mA
* ATMega ???
* FT245 ????

mit Max964 8mA/Comparator x 16 kommen 128 mA hinzu.

Die FTDI-Chips haben für Geräte, die über 100mA ziehen (darin wird wohl der LA u.U. fallen ), aber noch bus-powered sein sollen, einen Schaltausgang, an den z.B. ein p-Kanal-FET angeschlossen werden kann, der den stromhungrigen Teil der Schaltung erst nach der Registrierung beim Computer einschaltet. Dazu hat er einen "sleep"-Ausgang, mit dem man den angeschlossenen AVR schlafen legen kann. In den FTDI-Docs bzw. Application Notes finden sich dazu genüg Beispiele mit kompletten Schaltbildern. Allerdings ergibt die Überschlagsrechnung, dass ein externes Steckernetzteil notwendig wird.

Einsetzbar wäre auch ein LM2575S-3.3 [http://www.national.com/ds/LM/LM1575.pdf] für 2,47€ (Farnell), der sieht gut und einfach in der Handhabung aus im Falle einer externen Stromversorgung.

= Programmierung =

== AVR ==
Recht früh hat sich in dem Forum heraus kristallisiert, dass der AVR per Bootloader vom Computer her programmiert werden sollte. Hierdurch sind Firmware Updates sehr einfach möglich und verschiedene Bootloader sind verfügbar. Die Bootloader Option setzt damit einen AVR der ATMega Serie vorraus.

Der AVR braucht folgende Anschlüsse:
* JTAG (4 Pins)
* SPI (3 Pins + ~4 CS Leitungen)
* FTDI (12 Pins)
* LEDs (2 Pins)

Demnach ist ein 40poliger nötig. Es wird ein ATMega16 angesetzt.

== CPLD ==

Die Programmierung des CPLD ist dagegen noch nicht konkret. Wünschenswert wäre es, ebenfalls seine Firmaware über den Computer zu updaten.

Der Standardweg der Programmierung der Xilinx CPLD sieht einen JTAG Stiftsockel vor. Dann kann die Programmierung z.B. über ein Xilinx JTAG/Parallel Download Cable [http://www.xilinx.com/support/programr/jtag_cable.pdf] aus dem ISE/impact geschehen.

Einen möglichen Weg stellt die XApp058 [http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf] dar, darin wird beschrieben, wie der CPLD mittels uC beschrieben wird.
Dieses Thema wurde bereits im Forum "AVR Ethernet Platine" aufgegriffen. In diesem Thread [http://www.mikrocontroller.net/forum/read-1-138024.html#157356] kam man allerdings zu der Überzeugung, dass die XSVF Datei mit 45kByte für uC Verhältnisse extrem groß ist und somit nur in einen ATMega128 (und größer) [http://www.atmel.com/dyn/products/devices.asp?family_id=607#760] reinpassen würde da das SVF JTAG Protokoll riesige Datenbuffer im SRAM benötigt. Dies ist protokollbedingt - es wurden 10kByte für ein FPGA genannt. Dabei sind die Xilinx CPLD Speicherplatz effezienter als welche von Altera. Leider sind die Xilinx CPLD eben nur über JTAG programmierbar.

Allerdings wurde in diesem Zusammenhang auch auf den XSVF Executor [http://www.ethernut.de/en/xsvfexec/index.html] verwiesen.
Auch ist die Frage noch offen, inwiefern die XSVF Datei über die RS232/USB geladen werden kann, ebenso das Timing der JTAG Schnittstelle.

Dies lässt sich z.B. ähnlich dem Projekt in der Codesammlung machen [http://www.mikrocontroller.net/forum/read-4-228557.html#233821]. Dann ist zum Programmieren des CPLDs nur eine Software auf dem PC nötig, die Daten werden über USB oder RS232 an den AVR gesandt und dort umgesetzt.

Aufgrund der vielen offenen Fragen ist die schnellste und sicherste Lösung die Anbindung über den JTAG Stecker um den CPLD per JTAG/Parallel Download Cable zu programmieren. Zusätzlich wird eine JTAG Verbindung zum AVR Port eingerichtet, falls das Problem irgendwann 'mal später gelöst wird.

Bisher existiert in VHDL für den CPLD LA Core:

* Trigger (bit pattern, rising/falling/any edge) verifiziert mit TB
* SRAM Interface

= PCB =

Dieses Thema kommt noch intensiv.

Dabei sind u.a. die folgenden Appl. Notes nützlich:

für AVR:

* AVR040: EMC Design Considerations [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf]
* AVR042: AVR Hardware Design Considerations [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf]

für CPLD:

* Device Package User Guide [http://www.xilinx.com/bvdocs/userguides/ug112.pdf]
* XAPP112 - Designing With XC9500XL CPLDs [http://www.xilinx.com/bvdocs/appnotes/xapp112.pdf]
* XAPP114 - Understanding XC9500XL CPLD Power [http://www.xilinx.com/bvdocs/appnotes/xapp114.pdf]
* XAPP115 - Planning for High Speed XC9500XL Designs [http://www.xilinx.com/bvdocs/appnotes/xapp115.pdf]
* XAPP784 - Bulletproof CPLD Design Practices [http://www.xilinx.com/bvdocs/appnotes/xapp784.pdf]

= Resumee =

Keep-It-Simple ist ein Grundsatz hier. Je komplexer, desto schwerer zu beherrschen. Sicher hat jeder von Komplexität eine andere Vorstellung, aber wir arbeiten daran und hoffen ein nachbaufähiges, stabiles Gerät zu bekommen. Dennoch kommt man bei diesem Projekt um SMD löten mit 0.5mm Beinchen nicht umhin!

= Und was soll das kosten? =

Schwierig, da noch nicht alles feststeht - als Ziel steht aber im Forum mehr oder weniger ungeschrieben die 100€ Marke einschließlich PCB.

== Datenblätter, Bezugsquellen und Preise (allg.) ==

... oder was bisher so zusammengetragen wurde.

{| border="1"
|-
| align="center" | '''IC'''
| align="center" | '''Gehäuse'''
| align="center" | '''Kommentar'''
| align="center" | '''Datenblatt/Appnotes'''
| align="center" | '''Bezugsquelle'''
| align="center" | '''Preis'''
|-
| ''CPLD'' / XC95144XL10TQ144
| align="center" | TQFP144
| align="center" | -
| align="center" | [http://www.mhl.tuc.gr/data_books/Xilinx/Xc9500/95144XL.pdf], [http://www.xilinx.com/xlnx/xweb/xil_publications_index.jsp?category=Publications/CPLD+Device+Families&iLanguageID=1]
| align="center" | [http://www.darisus.de/Elektonikshop/Framesets/Shopset1.php Darius.De]
| align="center" | ca. 10?
|-
| ''USB'' / CP1202
| align="center" | -
| align="center" | -
| align="center" | [http://www.silabs.com/public/documents/tpub_doc/dshort/Microcontrollers/Interface/en/CP2102_short.pdf]
| align="center" | -
| align="center" | -?
|-
| ''USB'' / FT232BM
| align="center" | LQFP-32
| align="center" | -
| align="center" | [http://www.ftdichip.com/Documents/DataSheets/ds232b17.pdf], [http://www.ftdichip.com/Documents/AppNotes.htm]
| align="center" | -
| align="center" | -?
|-
| ''USB'' / FT245BM
| align="center" | LQFP-32
| align="center" | -
| align="center" | [http://www.ftdichip.com/Documents/DataSheets/ds245b16.pdf], [http://www.ftdichip.com/Documents/AppNotes.htm]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / Max964 (Maxim)
| align="center" | SO-16
| align="center" | '''Quad''' Beyond-the-Rails Comparators, 4.5ns, 3V/5V
| align="center" | [http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / AD8564 (Analog Devices)
| align="center" | TSSOP-16
| align="center" | '''Quad''' 7 ns Single Supply 5V Comparator
| align="center" | [http://www.analog.com/UploadedFiles/Data_Sheets/155150085AD8564_a.pdf]
| align="center" | [http://www.spoerle.de Spörle.de]
| align="center" | 8,80? Netto
|-
| ''Comp'' / LT1715 (LT)
| align="center" | -
| align="center" | Dual 4ns, 5V/3V, Independent I/O Supplies
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1154,C1004,C1012,P1908,D2821]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / LT1720/LT1721 (LT)
| align="center" | -
| align="center" | Dual/Quad 4.5ns, 3V, Rail-to-RailOut, Quad schlecht für's Layout
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1154,C1004,C1012,P1707,D3080]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / TLV3502 (TI/BB)
| align="center" | SOIC-8
| align="center" | 4.5ns Rail-to-Rail, Dual High-Speed Comparator
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv3502.pdf]
| align="center" | -
| align="center" | -?
|-
| ''ECL-Comp'' / Max9600
| align="center" | -
| align="center" | Schwierig zu realisieren: 2 "Wandlungsstufen" notwendig. 1x Inputpegel -> ECL, 1x ECL -> Logikpegel CPLD
| align="center" | [http://pdfserv.maxim-ic.com/en/ds/MAX9600-MAX9602.pdf]
| align="center" | -
| align="center" | -?
|-
| ''DAC'' / TLV5626 (TI)
| align="center" | SOIC-8
| align="center" | 8-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5626.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 5.29?
|-
| ''DAC'' / TLV5637 (TI)
| align="center" | SOIC-8
| align="center" | 10-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5637.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 6.35?
|-
| ''DAC'' / TLV5638 (TI)
| align="center" | SOIC-8
| align="center" | 12-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5638.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 7.44?
|-
| ''DAC'' / LTC1446L (LT)
| align="center" | SO-8
| align="center" | Dual 12-Bit, 3.3V, int. Uref=2.5V
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1155,C1005,C1156,P1507,D1746]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 12.35?
|-
| ''Clk'' / CY22393,CY22394,CY22395
| align="center" | -
| align="center" | -
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22393_4_5_5.pdf] ,[http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Layout%20Recommendations%20for%20the%20CY2239x%20Devices]
| align="center" | -
| align="center" | -?
|-
| ''Clk'' / ICD2053B
| align="center" | -
| align="center" | -
| align="center" | [http://www.commtech-fastcom.com/data_sheets/icd2053b.pdf]
| align="center" | -
| align="center" | -?
|-
| ''Clk'' / CY22150FC
| align="center" | 16-lead TSSOP
| align="center" | Taktgeber, Three-PLL, SPI progr. Taktgenerator
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22150_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 3,94?
|-
| ''SRAM'' / IC61LV25616
| align="center" | TSOP-2
| align="center" | asynchroner SRAM 256KB x 16
| align="center" | [http://www.glyn.de/data/glyn/media/doc/IS61LV25616.pdf],[http://www.icsi.com.tw/english/products/products-frame.asp?Title=Datasheet-Async%20SRAM&URL=http%3A//web.icsi.com.tw/English/Datasheets/ASYNCHRONOUSSTATICRAM.html]
| align="center" | [http://www.glyn.de Glyn.De] ???
| align="center" | ???
|-
| ''SRAM'' / AS7C34098-12TCN
| align="center" | TSOP, SOJ
| align="center" | asynchroner SRAM 256K x 16, 12ns
| align="center" | [http://www.alsc.com/pdf/sram.pdf/fa/AS7C4098.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 13,17?
|-
| ''SRAM'' / CY7C1327B
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18, 3.3V, 4ns
| align="center" | [http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598266]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 11,60?
|-
| ''SRAM'' / CY7C1327G
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327g_5.pdf]
| align="center" | -
| align="center" | -?
|-
| ''SRAM'' / CY7C1327F
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327f_5.pdf]
| align="center" | -
| align="center" | -?
|-
| ''SRAM'' / CY7C1351F-100AC
| align="center" | TQFP100
| align="center" | Burst, synchron, Durchfluss, NoBL, 4MB, 128Kx36, 3.3V
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1351f_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 11,25?
|-
| ''SRAM'' / CY7C1381B-100AC
| align="center" | TQFP100
| align="center" | Burst, synchron, Durchfluss, 18MB, 512Kx36, 3.3V
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1381c_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 48,75?
|-
| ''IC'' / Dummy
| align="center" | -
| align="center" | -
| align="center" | -
| align="center" | -
| align="center" | -?
|}

= Literatur =

* [http://web.mit.edu/6.111/www/s2005/HANDOUTS/LA.pdf] Agilent XYZs of Logic Analyzers
* [http://cp.literature.agilent.com/litweb/pdf/5988-9125EN.pdf] Agilent Logic Analyzer Probing Techniques for High-Speed Digital Systems
* [http://www.home.agilent.com/USeng/nav/-536898184.0/pc.html] Agilent Logic Analyzer Probing Solutions
* [http://www.designcon.com/2003/marketing/HP3-5.pdf] Logic Analyzer Probing Techniques for High-Speed Digital Systems (DesignCon 2003)
* [http://www.signalintegrity.com/Pubs/straight/probes.htm] Probing High-Speed Digital Designs (Electronic Design Magazine, March, 1997)
* [http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf] Handheld Pocket Logic Analyzer (XApp368)
* [http://www.xilinx.com/bvdocs/appnotes/xapp369.pdf] Handheld 1553 Bus Data Analyzer (XApp369)
* [http://www.amateurfunkbasteln.de/pcla/pcla.html] PC-basierter 32-Kanal-Logik-Analysator
* [http://www.bitscope.com] bitscope
* [http://www.rockylogic.com/products/ant8spec.html] Ant8 (mit fixer Treshold) und
* [http://www.rockylogic.com/products/ant16spec.html] Ant16 (mit variabler Treshold)
* [http://alternatezone.com/electronics/pcla.htm] PC LA
* [http://eebit.com/] FPGA-based Logic Analyzer
* [http://www.nci-usa.com/default.htm] Kommerziell: GoLogic, mit guten Texten und Videos
* [http://www.ethernut.de/en/xsvfexec/index.html] XSVF Executor
* [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Jitter%20in%20PLL%20Based%20Systems:%20Causes,%20Effects,%20and%20Solutions] Jitter in PLL Based Systems: Causes, Effects, and Solutions

* [http://www.standardics.philips.com/packaging/handbook/pdf/pkgchapter5.pdf] SMD Mounting Methods

[[Kategorie:Logic Analyzer Project|Hardware]]

Logic Analyzer-Projekt: Ideen zur Hardware

2005-09-21T20:42:47Z

Clemens Helfmeier: /* Interface LA <-> DUT (Device under Test) */

hier mal das Lastenheft für den Logic Analyser (LA). Bitte je nach Anforderung einen Strich mittels ALT GR + <> Taste links neben dem Ypsilon.
Die Aufteilung könnt ihr ja ändern/erweitern falls was fehlt. Ich gebe mal meine Maximalanforderungen ein.

'''Kanalanzahl'''
* .8 Kanäle: ||
* 16 Kanäle: ||||| ||||
* 20 Kanäle: |
* 24 Kanäle: |
* 32 Kanäle: ||||
* Modulair (erweiterbar X mal 8/16 Kanäle): ||

'''Samplingfrequenz'''
* ...8 MHz : |
* ..16 MHz : |
* ..32 MHz : ||
* .>32 MHz : ||||| ||||| |||

'''Speichertiefe'''
*....32 kByte: |
*....64 kByte:
*...128 kByte: |
*...256 kByte: |
*...512 kByte:
*..1024 kByte: |

Anmerkung: Wäre es nicht sinnvoller, die Speichertiefe in "Samples" anzugeben. So macht das nicht viel Sinn, da die Anzahl der Samples wenn man immer nur 8 Bits abspeichert ne andere ist als wie wenn man 32 Bits pro Sample speichert.

'''integrierter Pattern Generator'''
* .8 Kanäle : |
* 16 Kanäle:

Anm.: könnte bis zu einer gewissen Geschwindigkeit vom AVR erledigt werden... => uU. Mega16 drauf
--[[Benutzer:Hans|Hans]] 14:16, 20. Jul 2005 (CEST)

'''Schnittstelle zum Computer'''
* Seriell syncron..........: |
* Seriell asyncron (RS232).: ||||
* USB......................: ||||| |||||||
* Parallelport.............: ||
* Ethernet.................: |

'''Am PC läuft/wird laufen'''
* Windows .: ||||| ||||
* Linux .: ||||| |||||
* MacOS X .: |
* Solaris .: |
* Anderes .:

----

= Status =

(--[[Benutzer:84.182.244.75|84.182.244.75]] 10:43, 20. Sep 2005 (CEST) [ope])

Da der Logic Analyzer (LA) Thread schnell wächst und entsprechend schwer zu verfolgen ist, ständig sich irgend etwas ändert, kommt hier eine Zusammenfassung der Diskussion. Ich versuche sie halbwegs aktuell zu halten, öfteres Vorbeischauen lohnt sich also.

Eine fertige Lösung existiert jeodch noch nicht und einer alleine macht sich tot, zumal derjenige ja auch ein Real-Life hat und kein professioneller Designer für LA ist - daher ist das Projekt auf aktive Hilfe angewiesen sonst wird es sterben!

Auch sind die Threads dazu etwas verteilt (thematisch). Hier die grossen:

* [http://www.mikrocontroller.net/forum/read-1-204570.html#new Logic Analyzer bauen] (Initialthread)
* [http://www.mikrocontroller.net/forum/read-1-208137.html#new Pegelkomparator für High-Speed-Digital (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-234597.html#new Logic Analyzer Core (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-207389.html#new CPLD und AVR Kombo (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-221618.html#new Diverse Fragen bezueglich SRAM Anbindung]
* [http://www.mikrocontroller.net/forum/read-4-228557.html#new Programmieren des CPLDs über den AVR]

Eine reine AVR Lösung scheint sich hier abzuzeichnen:

* [http://www.mikrocontroller.net/forum/read-1-225498.html#new Logic Analyzer bauen, die 2.]

= Das Ziel =

Nun ja, preiswert und universell und für den Großteil der Probleme brauchbar soll er sein. Zudem sollen die Bauteile z.B. auch in Schweiz/Österreich gut verfügbar sein. Dass er sich mit einem LA der großen Hersteller messen lassen kann, ist aufgrund des Hobby Bereiches bzw. Proof-on-Concepts eher unwahrscheinlich. Unter den eben genanntenn Prämissen sollen die verfügbaren Mittel optimal genutzt werden.

Je nach Ergebnis, Lust und Laune wird es irgendwann evtl. eine Fortsetzung geben - aber das ist Zukunftsmusik.

= Grundlegende Überlegungen =

Im Internet kann man verschiedene, einfache Konzepte für einen LA finden, z.B. mittels Parallelport. Forumgerecht, reicht für einen einfachen LA bereits ein Mikrokontroller aus, der seine Ports polled um so die Logik Pegel mitzuschneiden. Allerdings ist diese Lösung begrenzt, wenn es um höhere Taktraten geht.

Eine erschwingliche Alternative stellt ein CPLD (Complex programmable logic devices) dar. Die CPLD z.B. von Xilinx können mit über 100MHz arbeiten und sind somit für diese Aufgabe prädestiniert. Leider ist die Anzahl der Macro Zellen zu gering, um eine hohe Speichertiefe zu erreichen. Daher werden die Daten vom CPLD in einem SRAM geschrieben. Damit ist der CPLD für die Triggerbedingungen des LA, dem Speicherinterface und natürlich dem eigentlichen sampeln der Eingänge verantwortlich. Der Mikrokontroller liest die Daten des SRAM über den CPLD aus und schickt sie an den Computer, übernimmt also die Kommunikation. Die Software stellt die gesampelten Daten sinnvoll und ansprechend dar.

Um die Störungen gering zu halten, wird als Versorgungspannung 3.3V Vorzug gegeben - ironischer Weise sind die Xilinx CPLD XC95000XL mit dieser Spannung preiswerter als in der 5V Version.

= Die Komponenten =

== Der CPLD und das Speicherinterface ==

Nach einigen Hin- und Her hat sich der XC95144XL TQ144 als beste Option herausgestellt. Auch FPGAs waren kurz im Gespräch, aufgrund der sich im Gespräch heraustellenden Komplexität. Allerdings war die Komplexität des FPGA und der Preis auch gleichzeitig das KO-Kriterium dafür.

Kurzinfo XC95144XL TQ144 [http://www.mhl.tuc.gr/data_books/Xilinx/Xc9500/95144XL.pdf]:

* 144Macro, 3.3V, 117 I/O, TQFP144 für ca. 10€

Dieser bietet genug I/O um:

* 2x SRAM 256k x 16 (jeweils 18 AD, 16 DB, 3 Ctrl)
* 2x 8-bit-LA-Channel
* Ext. TriggerIn, TriggerOut
* SPI Bus zum AVR
* JTAG

anschliessen zu können.

Der Grund für die 2 Speicherbänke liegen in den Möglichkeiten, sich den LA selbst zu konfigurieren für:

* Interleave
* Speicherung eines Timestamp
* non-Interleave und non-Timestamp mit nur einem SRAM

Beim Interleave werden zwei 16 Bit Samples im CPLD gelatched und gemeinsam auf den nun 32bit breiten Datenbus gelegt. Dabei sind die Adressen für die SRAMs folglich identisch. Damit beträgt die SChreibrate beim SRAM bei der Hälfte des Sampleclocks, der entsprechend hoch gesetzt werden kann.

Bei Verwendung des 2x 256k x 16 Bit SRAM eröffnet sich aber weiterhin die Möglichkeit, den Transitional Timing Analysis Mode zu realisieren, d.h. nur Bit-Änderungen werden mit einem Timestamp gespeichert - also ideal für langsame Busse bei hohen Sampleraten. Hier kann man zB. eine 16bit Time-Stamp-Adresse (256k) mit einem 16bit Pattern speichern, oder ein 24bit Timestamps für 8bit. Ein Interleave ist dann allerdings nicht mehr möglich.

Als letze Möglichkeit kann man auf alles obige Verzichten und nur einen SRAM bestücken.

Der heisseste Kandidat für den Speicher ist derzeit die 61LV25616 (256k*16) asynchrone Serie (zB.[http://www.issi.com/pdf/61LV25616AL.pdf IS61LV25616]), da er gut verfügbar und preiswert sein soll. Bei asynchronen SRAM müssen wie eingangs erwähnt die Adressen und Daten in einem Latch zwischen gespeichert werden. Bei einem synchronen SRAM werden die Adressen bei mit Flanke gespeichert, ebenso die Daten. Die Setup und Hold Zeiten gehen daher gegen Null... Außerdem muss man WR\ nicht toggeln, was wertvolle Zeit kostet, sondern es reicht, den Speichertakt anzulegen.

Weitere Typen wären

Asynchrone SRAM:

* CY22393,CY22394,CY22395 [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22393_4_5_5.pdf] mit Layout Hinweisen [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Layout%20Recommendations%20for%20the%20CY2239x%20Devices]
* AS7C34098-12TCN (256K x 16, 12ns) [http://www.alsc.com/pdf/sram.pdf/fa/AS7C4098.pdf] und AS7C31026B-12TCN (64k x 16, 12ns) Asynchroner SRAM bei Farnell

Synchrone SRAM:

* CY7C1327G (256k*18) [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327g_5.pdf]
* CY7C1327F (256k*18) [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327f_5.pdf]
* CY7C1327B (256k*18 Synchronous-Pipelined Cache RAM)[http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598266]

Den CY7C1327B (TQFP100 256Kx18, 3.3V, 4ns ) gibt's zumindest bei R&S für 11,60€

== Interface CPLD <-> uC ==

Eine grundlegende Idee ist, dass der CPLD doppelt benutzt wird. Er enthält ja einen Addresszähler zum Schreiben des SRAM's. Dieser kann aber auch zum Lesen des SRAM's benutzt werden. Der SRAM wird immer sequentiell vom PLD geschrieben und gelesen.

Die Daten, Statusinfos etc. werden per SPI vom AVR aus dem CPLD gelesen. Vorteil ist dabei, dass man nun auch z.B. 512Kb SRAM's benutzen kann ohne dass der uC ein kompliziertes Memory Banking benutzen müsste.

== Interface uC <-> Computer ==

Da die Daten schnell im PC sein sollen, bietet sich USB an, also mit dem
[http://www.ftdichip.com/Documents/DataSheets/ds245b16.pdf FT245]
um schneller (2-3 Mbaud) als der
[http://www.ftdichip.com/Documents/DataSheets/ds232b17.pdf FT232] (1 Mbaud)
die Daten zu versenden. FTDI bietet die Treiber für Windows/Linux kostenlose an.

Eine Alternative ist der
[http://www.silabs.com/public/documents/tpub_doc/dshort/Microcontrollers/Interface/en/CP2102_short.pdf CP2102], der weniger Bauelemente benötigt aber auch wesentlich schwerer zu löten ist.

uC mit integrierten USB standen auch in der Disskusion. Aufgrund vieler Unwägbarkeiten, wie Beschaffung, Preis, HID Treiber etc. sind diese Ideen wieder verworfen worden.

== Interface LA <-> DUT (Device under Test) ==

Prinzipiell gibt es zwei Wege, wie der LA an seine Informationen kommt:
* Der rein digitale Weg geht z.B. über 74AHC245 oder 74ACT14 o.ä. womit allerdings die Logikpegel feststehen.
* Ein anderer Weg geht über Analog-Komparatoren, bei denen die Logikpegel (Treshold) variabel sind und somit auch am flexibelsten für die versch. Logikfamilien [http://www.mikrocontroller.net/attachment.php/209385/Scan0004.png] ist.

Für die Komparatorlösung steht momentan der [http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf MAX964] und
[http://www.analog.com/UploadedFiles/Data_Sheets/155150085AD8564_a.pdf AD8564]
zur Debatte. Allerdings ist der MAX964 schwer zu beschaffen und bereits in der Dualvariante teurer als der AD8564 (ca. 10 Euro). Auch müssen diese mit 5V betrieben werden (wegen der TTL Eingänge und das der Eingspg.bereich von der VCC abhängt), wodurch Pegelwandler wie der 74LVC245 zum CPLD notwendig werden. Auch die Treshold-Reference muss in diesem Bereich liegen. Diese Schwelle wird durch einen DAC vorgegeben, der vom uC über SPI gesteuert wird. Dieser sollte eine interne Referenz besitzen um mit möglichst wenig Bauelementen auszukommen. Zudem sollte er über zwei Kanäle verfügen, da aktuell der LA über 2 pods mit jeweils einem 8 Bit-Channel verfügen soll. Z.Zt. scheint die beste Wahl hinsichtlich Parameter, Preis und Verfügbarkeit die [http://focus.ti.com/lit/ds/symlink/tlv5626.pdf TLV5626], [http://focus.ti.com/lit/ds/symlink/tlv5637.pdf TLV5637] und [http://focus.ti.com/lit/ds/symlink/tlv5638.pdf TLV5638] mit 8, 10 bzw. 12 Bit zu sein. Der Einsatz eines DAC wird wesentlich einfacher als eine PWM per uC mit anschließenden Tiefpaß mit OPVs, welches die Fehlerrate steigen lassen kann.

Bei einem digitalen Eingangsteil bietet sich folgendes an:
*[http://www.semiconductors.philips.com/acrobat/datasheets/74LVC14A_4.pdf 74lvc14] Hex inverting Schmitt-trigger with 5 V tolerant input; Dummerweise eben 6 Stck. - für 0,56? bei R&S
*[http://www.semiconductors.philips.com/acrobat_download/datasheets/74LVC541A_3.pdf 74LVC541] Octal buffer/line driver with 5 V tolerant inputs/outputs (3-state) für 0,71? bei R&S
*[http://www.semiconductors.philips.com/acrobat_download/datasheets/74HC_HCT7541_CNV_2.pdf 74HC7541] Octal Schmitt trigger buffer/line driver; 3-state für 9,85? bei R&S - damit können gerade langsame Busse untersucht werden da die Eingänge nicht so fürchterlich empfindlich sind; ansonsten ist es ein 541. Leider scheint es ihn nicht in der 74lvc zu geben.

Einigkeit besteht darüber, dass verschiedene Eingangsoptionen möglich sein sollen. Dies wird dadurch erreicht, dass die Eingangsbeschaltung auf einer extra Platine plaziert wird und definierte Logikpegel an den CPLD (3,3V) liefern muss. Dann kann - je nach Geldbeutel & Einsatzzweck - die eine oder andere Variante umgesetzt werden. Zusätzlich zu den Datenleitungen sind noch Versorgung und SPI-Schnittstellen zu den Eingangsplatinen nötig.

Einigkeit besteht jedoch in der notwendigen Schutzschaltung, z.B. mit einem Dioden-Array. Auch darf die Eingangsspannung den Input Voltage Range (je nach Typ) nicht überschreiten.

== Clock Rate Generierung ==

Aufgrund seiner Bandbreite bietet sich die Generierung des Systemtaktes durch den CPLD an. Dieser benutzt einen 1/N Teiler um den Sample Takt zu generieren.

Prinzipiell kann er auch gleichzeitig den Takt für den uC erzeugen - dieser wird also extern getaktet und man erhält dadurch Synchronität zwischen CPLD und uC und spart den Quarz am uC. Allerdings bieted sich auch ein eigener Quarz für den uC an. Man sieht - hier wird noch diskutiert.

Zur Generierung des Mastertaktes bieten sich zwei Weg an:
* Quarz, bei 50-64 MHz dürfte da wegen Verfügbarkeit/Preis wohl Schluss sein, auch sind Obertonquarze nicht ganz unkritisch. Auch kann man dann nur noch durch umlöten und wecheln den Mastertakt ändern, falls es Probleme gibt.
* VCO/PLL ggf. per uC programmierbar, damit kann man dann echt die Grenzen des Designs austesten. Die Chips dazu gibt's bei Maxim/AD und den anderen üblichen Verdächtigen, stehen also noch nicht fest. Als aussichtsrechster Kandidat sticht derzeit der [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22150_5.pdf CY22150] hervor, der mehrere synchrone Freq. mit einem einfachen Quarz erzeugen kann. Dadurch wird der Freq.teiler im CPLD nicht mehr benötigt und hat wieder einige MC frei.

Die Grenzen der Samplefreq. liegen zum einem in den verwendeten Bauelementen (>100MHz), aber vielmehr wird der begrenzende Faktor das Layout und die Leiterplatte sein. Ein 4-Layer-PCB ist aus technischer Sicht sicher das optimale, nur schaut der Geldbeutel danach sehr leer aus; auch wird ein Komparatoreingang ca. 45 Euro teurer werden als eine Lösung mit 74xxx.

== Stromversorgung ==

Tja, auch ein LA braucht Strom. Bei Verwendung eines USB kann dieses elegant gelöst werden, da dieser (nach Anforderungen an das OS) bis zu 500mA liefern kann. Eine kurze worst-case "Stromrechnung" zeigt:

* XC95144XL CPLD pauschal 150mA lt. DB
* 61LV25616 SRAM 2x 320mA
* ATMega ???
* FT245 ????

mit Max964 8mA/Comparator x 16 kommen 128 mA hinzu.

Die FTDI-Chips haben für Geräte, die über 100mA ziehen (darin wird wohl der LA u.U. fallen ), aber noch bus-powered sein sollen, einen Schaltausgang, an den z.B. ein p-Kanal-FET angeschlossen werden kann, der den stromhungrigen Teil der Schaltung erst nach der Registrierung beim Computer einschaltet. Dazu hat er einen "sleep"-Ausgang, mit dem man den angeschlossenen AVR schlafen legen kann. In den FTDI-Docs bzw. Application Notes finden sich dazu genüg Beispiele mit kompletten Schaltbildern. Allerdings ergibt die Überschlagsrechnung, dass ein externes Steckernetzteil notwendig wird.

Einsetzbar wäre auch ein LM2575S-3.3 [http://www.national.com/ds/LM/LM1575.pdf] für 2,47€ (Farnell), der sieht gut und einfach in der Handhabung aus im Falle einer externen Stromversorgung.

= Programmierung =

== AVR ==
Recht früh hat sich in dem Forum heraus kristallisiert, dass der AVR per Bootloader vom Computer her programmiert werden sollte. Hierdurch sind Firmware Updates sehr einfach möglich und verschiedene Bootloader sind verfügbar. Die Bootloader Option setzt damit einen AVR der ATMega Serie vorraus.

Der AVR braucht folgende Anschlüsse:
* JTAG (4 Pins)
* SPI (3 Pins + ~4 CS Leitungen)
* FTDI (12 Pins)
* LEDs (2 Pins)

Demnach ist ein 40poliger nötig. Es wird ein ATMega16 angesetzt.

== CPLD ==

Die Programmierung des CPLD ist dagegen noch nicht konkret. Wünschenswert wäre es, ebenfalls seine Firmaware über den Computer zu updaten.

Der Standardweg der Programmierung der Xilinx CPLD sieht einen JTAG Stiftsockel vor. Dann kann die Programmierung z.B. über ein Xilinx JTAG/Parallel Download Cable [http://www.xilinx.com/support/programr/jtag_cable.pdf] aus dem ISE/impact geschehen.

Einen möglichen Weg stellt die XApp058 [http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf] dar, darin wird beschrieben, wie der CPLD mittels uC beschrieben wird.
Dieses Thema wurde bereits im Forum "AVR Ethernet Platine" aufgegriffen. In diesem Thread [http://www.mikrocontroller.net/forum/read-1-138024.html#157356] kam man allerdings zu der Überzeugung, dass die XSVF Datei mit 45kByte für uC Verhältnisse extrem groß ist und somit nur in einen ATMega128 (und größer) [http://www.atmel.com/dyn/products/devices.asp?family_id=607#760] reinpassen würde da das SVF JTAG Protokoll riesige Datenbuffer im SRAM benötigt. Dies ist protokollbedingt - es wurden 10kByte für ein FPGA genannt. Dabei sind die Xilinx CPLD Speicherplatz effezienter als welche von Altera. Leider sind die Xilinx CPLD eben nur über JTAG programmierbar.

Allerdings wurde in diesem Zusammenhang auch auf den XSVF Executor [http://www.ethernut.de/en/xsvfexec/index.html] verwiesen.
Auch ist die Frage noch offen, inwiefern die XSVF Datei über die RS232/USB geladen werden kann, ebenso das Timing der JTAG Schnittstelle.

Dies lässt sich z.B. ähnlich dem Projekt in der Codesammlung machen [http://www.mikrocontroller.net/forum/read-4-228557.html#233821]. Dann ist zum Programmieren des CPLDs nur eine Software auf dem PC nötig, die Daten werden über USB oder RS232 an den AVR gesandt und dort umgesetzt.

Aufgrund der vielen offenen Fragen ist die schnellste und sicherste Lösung die Anbindung über den JTAG Stecker um den CPLD per JTAG/Parallel Download Cable zu programmieren. Zusätzlich wird eine JTAG Verbindung zum AVR Port eingerichtet, falls das Problem irgendwann 'mal später gelöst wird.

Bisher existiert in VHDL für den CPLD LA Core:

* Trigger (bit pattern, rising/falling/any edge) verifiziert mit TB
* SRAM Interface

= PCB =

Dieses Thema kommt noch intensiv.

Dabei sind u.a. die folgenden Appl. Notes nützlich:

für AVR:

* AVR040: EMC Design Considerations [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf]
* AVR042: AVR Hardware Design Considerations [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf]

für CPLD:

* Device Package User Guide [http://www.xilinx.com/bvdocs/userguides/ug112.pdf]
* XAPP112 - Designing With XC9500XL CPLDs [http://www.xilinx.com/bvdocs/appnotes/xapp112.pdf]
* XAPP114 - Understanding XC9500XL CPLD Power [http://www.xilinx.com/bvdocs/appnotes/xapp114.pdf]
* XAPP115 - Planning for High Speed XC9500XL Designs [http://www.xilinx.com/bvdocs/appnotes/xapp115.pdf]
* XAPP784 - Bulletproof CPLD Design Practices [http://www.xilinx.com/bvdocs/appnotes/xapp784.pdf]

= Resumee =

Keep-It-Simple ist ein Grundsatz hier. Je komplexer, desto schwerer zu beherrschen. Sicher hat jeder von Komplexität eine andere Vorstellung, aber wir arbeiten daran und hoffen ein nachbaufähiges, stabiles Gerät zu bekommen. Dennoch kommt man bei diesem Projekt um SMD löten mit 0.5mm Beinchen nicht umhin!

= Und was soll das kosten? =

Schwierig, da noch nicht alles feststeht - als Ziel steht aber im Forum mehr oder weniger ungeschrieben die 100€ Marke einschließlich PCB.

== Datenblätter, Bezugsquellen und Preise (allg.) ==

... oder was bisher so zusammengetragen wurde.

{| border="1"
|-
| align="center" | '''IC'''
| align="center" | '''Gehäuse'''
| align="center" | '''Kommentar'''
| align="center" | '''Datenblatt/Appnotes'''
| align="center" | '''Bezugsquelle'''
| align="center" | '''Preis'''
|-
| ''CPLD'' / XC95144XL10TQ144
| align="center" | TQFP144
| align="center" | -
| align="center" | [http://www.mhl.tuc.gr/data_books/Xilinx/Xc9500/95144XL.pdf], [http://www.xilinx.com/xlnx/xweb/xil_publications_index.jsp?category=Publications/CPLD+Device+Families&iLanguageID=1]
| align="center" | [http://www.darisus.de/Elektonikshop/Framesets/Shopset1.php Darius.De]
| align="center" | ca. 10?
|-
| ''USB'' / CP1202
| align="center" | -
| align="center" | -
| align="center" | [http://www.silabs.com/public/documents/tpub_doc/dshort/Microcontrollers/Interface/en/CP2102_short.pdf]
| align="center" | -
| align="center" | -?
|-
| ''USB'' / FT232BM
| align="center" | LQFP-32
| align="center" | -
| align="center" | [http://www.ftdichip.com/Documents/DataSheets/ds232b17.pdf], [http://www.ftdichip.com/Documents/AppNotes.htm]
| align="center" | -
| align="center" | -?
|-
| ''USB'' / FT245BM
| align="center" | LQFP-32
| align="center" | -
| align="center" | [http://www.ftdichip.com/Documents/DataSheets/ds245b16.pdf], [http://www.ftdichip.com/Documents/AppNotes.htm]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / Max964 (Maxim)
| align="center" | SO-16
| align="center" | '''Quad''' Beyond-the-Rails Comparators, 4.5ns, 3V/5V
| align="center" | [http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / AD8564 (Analog Devices)
| align="center" | TSSOP-16
| align="center" | '''Quad''' 7 ns Single Supply 5V Comparator
| align="center" | [http://www.analog.com/UploadedFiles/Data_Sheets/155150085AD8564_a.pdf]
| align="center" | [http://www.spoerle.de Spörle.de]
| align="center" | 8,80? Netto
|-
| ''Comp'' / LT1715 (LT)
| align="center" | -
| align="center" | Dual 4ns, 5V/3V, Independent I/O Supplies
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1154,C1004,C1012,P1908,D2821]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / LT1720/LT1721 (LT)
| align="center" | -
| align="center" | Dual/Quad 4.5ns, 3V, Rail-to-RailOut, Quad schlecht für's Layout
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1154,C1004,C1012,P1707,D3080]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / TLV3502 (TI/BB)
| align="center" | SOIC-8
| align="center" | 4.5ns Rail-to-Rail, Dual High-Speed Comparator
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv3502.pdf]
| align="center" | -
| align="center" | -?
|-
| ''ECL-Comp'' / Max9600
| align="center" | -
| align="center" | Schwierig zu realisieren: 2 "Wandlungsstufen" notwendig. 1x Inputpegel -> ECL, 1x ECL -> Logikpegel CPLD
| align="center" | [http://pdfserv.maxim-ic.com/en/ds/MAX9600-MAX9602.pdf]
| align="center" | -
| align="center" | -?
|-
| ''DAC'' / TLV5626 (TI)
| align="center" | SOIC-8
| align="center" | 8-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5626.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 5.29?
|-
| ''DAC'' / TLV5637 (TI)
| align="center" | SOIC-8
| align="center" | 10-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5637.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 6.35?
|-
| ''DAC'' / TLV5638 (TI)
| align="center" | SOIC-8
| align="center" | 12-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5638.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 7.44?
|-
| ''DAC'' / LTC1446L (LT)
| align="center" | SO-8
| align="center" | Dual 12-Bit, 3.3V, int. Uref=2.5V
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1155,C1005,C1156,P1507,D1746]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 12.35?
|-
| ''Clk'' / CY22393,CY22394,CY22395
| align="center" | -
| align="center" | -
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22393_4_5_5.pdf] ,[http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Layout%20Recommendations%20for%20the%20CY2239x%20Devices]
| align="center" | -
| align="center" | -?
|-
| ''Clk'' / ICD2053B
| align="center" | -
| align="center" | -
| align="center" | [http://www.commtech-fastcom.com/data_sheets/icd2053b.pdf]
| align="center" | -
| align="center" | -?
|-
| ''Clk'' / CY22150FC
| align="center" | 16-lead TSSOP
| align="center" | Taktgeber, Three-PLL, SPI progr. Taktgenerator
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22150_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 3,94?
|-
| ''SRAM'' / IC61LV25616
| align="center" | TSOP-2
| align="center" | asynchroner SRAM 256KB x 16
| align="center" | [http://www.glyn.de/data/glyn/media/doc/IS61LV25616.pdf],[http://www.icsi.com.tw/english/products/products-frame.asp?Title=Datasheet-Async%20SRAM&URL=http%3A//web.icsi.com.tw/English/Datasheets/ASYNCHRONOUSSTATICRAM.html]
| align="center" | [http://www.glyn.de Glyn.De] ???
| align="center" | ???
|-
| ''SRAM'' / AS7C34098-12TCN
| align="center" | TSOP, SOJ
| align="center" | asynchroner SRAM 256K x 16, 12ns
| align="center" | [http://www.alsc.com/pdf/sram.pdf/fa/AS7C4098.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 13,17?
|-
| ''SRAM'' / CY7C1327B
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18, 3.3V, 4ns
| align="center" | [http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598266]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 11,60?
|-
| ''SRAM'' / CY7C1327G
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327g_5.pdf]
| align="center" | -
| align="center" | -?
|-
| ''SRAM'' / CY7C1327F
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327f_5.pdf]
| align="center" | -
| align="center" | -?
|-
| ''SRAM'' / CY7C1351F-100AC
| align="center" | TQFP100
| align="center" | Burst, synchron, Durchfluss, NoBL, 4MB, 128Kx36, 3.3V
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1351f_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 11,25?
|-
| ''SRAM'' / CY7C1381B-100AC
| align="center" | TQFP100
| align="center" | Burst, synchron, Durchfluss, 18MB, 512Kx36, 3.3V
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1381c_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 48,75?
|-
| ''IC'' / Dummy
| align="center" | -
| align="center" | -
| align="center" | -
| align="center" | -
| align="center" | -?
|}

= Literatur =

* [http://web.mit.edu/6.111/www/s2005/HANDOUTS/LA.pdf] Agilent XYZs of Logic Analyzers
* [http://cp.literature.agilent.com/litweb/pdf/5988-9125EN.pdf] Agilent Logic Analyzer Probing Techniques for High-Speed Digital Systems
* [http://www.home.agilent.com/USeng/nav/-536898184.0/pc.html] Agilent Logic Analyzer Probing Solutions
* [http://www.designcon.com/2003/marketing/HP3-5.pdf] Logic Analyzer Probing Techniques for High-Speed Digital Systems (DesignCon 2003)
* [http://www.signalintegrity.com/Pubs/straight/probes.htm] Probing High-Speed Digital Designs (Electronic Design Magazine, March, 1997)
* [http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf] Handheld Pocket Logic Analyzer (XApp368)
* [http://www.xilinx.com/bvdocs/appnotes/xapp369.pdf] Handheld 1553 Bus Data Analyzer (XApp369)
* [http://www.amateurfunkbasteln.de/pcla/pcla.html] PC-basierter 32-Kanal-Logik-Analysator
* [http://www.bitscope.com] bitscope
* [http://www.rockylogic.com/products/ant8spec.html] Ant8 (mit fixer Treshold) und
* [http://www.rockylogic.com/products/ant16spec.html] Ant16 (mit variabler Treshold)
* [http://alternatezone.com/electronics/pcla.htm] PC LA
* [http://eebit.com/] FPGA-based Logic Analyzer
* [http://www.nci-usa.com/default.htm] Kommerziell: GoLogic, mit guten Texten und Videos
* [http://www.ethernut.de/en/xsvfexec/index.html] XSVF Executor
* [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Jitter%20in%20PLL%20Based%20Systems:%20Causes,%20Effects,%20and%20Solutions] Jitter in PLL Based Systems: Causes, Effects, and Solutions

* [http://www.standardics.philips.com/packaging/handbook/pdf/pkgchapter5.pdf] SMD Mounting Methods

[[Kategorie:Logic Analyzer Project|Hardware]]

Logic Analyzer-Projekt: Ideen zur Hardware

2005-09-21T20:36:43Z

Clemens Helfmeier: /* CPLD */

hier mal das Lastenheft für den Logic Analyser (LA). Bitte je nach Anforderung einen Strich mittels ALT GR + <> Taste links neben dem Ypsilon.
Die Aufteilung könnt ihr ja ändern/erweitern falls was fehlt. Ich gebe mal meine Maximalanforderungen ein.

'''Kanalanzahl'''
* .8 Kanäle: ||
* 16 Kanäle: ||||| ||||
* 20 Kanäle: |
* 24 Kanäle: |
* 32 Kanäle: ||||
* Modulair (erweiterbar X mal 8/16 Kanäle): ||

'''Samplingfrequenz'''
* ...8 MHz : |
* ..16 MHz : |
* ..32 MHz : ||
* .>32 MHz : ||||| ||||| |||

'''Speichertiefe'''
*....32 kByte: |
*....64 kByte:
*...128 kByte: |
*...256 kByte: |
*...512 kByte:
*..1024 kByte: |

Anmerkung: Wäre es nicht sinnvoller, die Speichertiefe in "Samples" anzugeben. So macht das nicht viel Sinn, da die Anzahl der Samples wenn man immer nur 8 Bits abspeichert ne andere ist als wie wenn man 32 Bits pro Sample speichert.

'''integrierter Pattern Generator'''
* .8 Kanäle : |
* 16 Kanäle:

Anm.: könnte bis zu einer gewissen Geschwindigkeit vom AVR erledigt werden... => uU. Mega16 drauf
--[[Benutzer:Hans|Hans]] 14:16, 20. Jul 2005 (CEST)

'''Schnittstelle zum Computer'''
* Seriell syncron..........: |
* Seriell asyncron (RS232).: ||||
* USB......................: ||||| |||||||
* Parallelport.............: ||
* Ethernet.................: |

'''Am PC läuft/wird laufen'''
* Windows .: ||||| ||||
* Linux .: ||||| |||||
* MacOS X .: |
* Solaris .: |
* Anderes .:

----

= Status =

(--[[Benutzer:84.182.244.75|84.182.244.75]] 10:43, 20. Sep 2005 (CEST) [ope])

Da der Logic Analyzer (LA) Thread schnell wächst und entsprechend schwer zu verfolgen ist, ständig sich irgend etwas ändert, kommt hier eine Zusammenfassung der Diskussion. Ich versuche sie halbwegs aktuell zu halten, öfteres Vorbeischauen lohnt sich also.

Eine fertige Lösung existiert jeodch noch nicht und einer alleine macht sich tot, zumal derjenige ja auch ein Real-Life hat und kein professioneller Designer für LA ist - daher ist das Projekt auf aktive Hilfe angewiesen sonst wird es sterben!

Auch sind die Threads dazu etwas verteilt (thematisch). Hier die grossen:

* [http://www.mikrocontroller.net/forum/read-1-204570.html#new Logic Analyzer bauen] (Initialthread)
* [http://www.mikrocontroller.net/forum/read-1-208137.html#new Pegelkomparator für High-Speed-Digital (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-234597.html#new Logic Analyzer Core (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-207389.html#new CPLD und AVR Kombo (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-221618.html#new Diverse Fragen bezueglich SRAM Anbindung]
* [http://www.mikrocontroller.net/forum/read-4-228557.html#new Programmieren des CPLDs über den AVR]

Eine reine AVR Lösung scheint sich hier abzuzeichnen:

* [http://www.mikrocontroller.net/forum/read-1-225498.html#new Logic Analyzer bauen, die 2.]

= Das Ziel =

Nun ja, preiswert und universell und für den Großteil der Probleme brauchbar soll er sein. Zudem sollen die Bauteile z.B. auch in Schweiz/Österreich gut verfügbar sein. Dass er sich mit einem LA der großen Hersteller messen lassen kann, ist aufgrund des Hobby Bereiches bzw. Proof-on-Concepts eher unwahrscheinlich. Unter den eben genanntenn Prämissen sollen die verfügbaren Mittel optimal genutzt werden.

Je nach Ergebnis, Lust und Laune wird es irgendwann evtl. eine Fortsetzung geben - aber das ist Zukunftsmusik.

= Grundlegende Überlegungen =

Im Internet kann man verschiedene, einfache Konzepte für einen LA finden, z.B. mittels Parallelport. Forumgerecht, reicht für einen einfachen LA bereits ein Mikrokontroller aus, der seine Ports polled um so die Logik Pegel mitzuschneiden. Allerdings ist diese Lösung begrenzt, wenn es um höhere Taktraten geht.

Eine erschwingliche Alternative stellt ein CPLD (Complex programmable logic devices) dar. Die CPLD z.B. von Xilinx können mit über 100MHz arbeiten und sind somit für diese Aufgabe prädestiniert. Leider ist die Anzahl der Macro Zellen zu gering, um eine hohe Speichertiefe zu erreichen. Daher werden die Daten vom CPLD in einem SRAM geschrieben. Damit ist der CPLD für die Triggerbedingungen des LA, dem Speicherinterface und natürlich dem eigentlichen sampeln der Eingänge verantwortlich. Der Mikrokontroller liest die Daten des SRAM über den CPLD aus und schickt sie an den Computer, übernimmt also die Kommunikation. Die Software stellt die gesampelten Daten sinnvoll und ansprechend dar.

Um die Störungen gering zu halten, wird als Versorgungspannung 3.3V Vorzug gegeben - ironischer Weise sind die Xilinx CPLD XC95000XL mit dieser Spannung preiswerter als in der 5V Version.

= Die Komponenten =

== Der CPLD und das Speicherinterface ==

Nach einigen Hin- und Her hat sich der XC95144XL TQ144 als beste Option herausgestellt. Auch FPGAs waren kurz im Gespräch, aufgrund der sich im Gespräch heraustellenden Komplexität. Allerdings war die Komplexität des FPGA und der Preis auch gleichzeitig das KO-Kriterium dafür.

Kurzinfo XC95144XL TQ144 [http://www.mhl.tuc.gr/data_books/Xilinx/Xc9500/95144XL.pdf]:

* 144Macro, 3.3V, 117 I/O, TQFP144 für ca. 10€

Dieser bietet genug I/O um:

* 2x SRAM 256k x 16 (jeweils 18 AD, 16 DB, 3 Ctrl)
* 2x 8-bit-LA-Channel
* Ext. TriggerIn, TriggerOut
* SPI Bus zum AVR
* JTAG

anschliessen zu können.

Der Grund für die 2 Speicherbänke liegen in den Möglichkeiten, sich den LA selbst zu konfigurieren für:

* Interleave
* Speicherung eines Timestamp
* non-Interleave und non-Timestamp mit nur einem SRAM

Beim Interleave werden zwei 16 Bit Samples im CPLD gelatched und gemeinsam auf den nun 32bit breiten Datenbus gelegt. Dabei sind die Adressen für die SRAMs folglich identisch. Damit beträgt die SChreibrate beim SRAM bei der Hälfte des Sampleclocks, der entsprechend hoch gesetzt werden kann.

Bei Verwendung des 2x 256k x 16 Bit SRAM eröffnet sich aber weiterhin die Möglichkeit, den Transitional Timing Analysis Mode zu realisieren, d.h. nur Bit-Änderungen werden mit einem Timestamp gespeichert - also ideal für langsame Busse bei hohen Sampleraten. Hier kann man zB. eine 16bit Time-Stamp-Adresse (256k) mit einem 16bit Pattern speichern, oder ein 24bit Timestamps für 8bit. Ein Interleave ist dann allerdings nicht mehr möglich.

Als letze Möglichkeit kann man auf alles obige Verzichten und nur einen SRAM bestücken.

Der heisseste Kandidat für den Speicher ist derzeit die 61LV25616 (256k*16) asynchrone Serie (zB.[http://www.issi.com/pdf/61LV25616AL.pdf IS61LV25616]), da er gut verfügbar und preiswert sein soll. Bei asynchronen SRAM müssen wie eingangs erwähnt die Adressen und Daten in einem Latch zwischen gespeichert werden. Bei einem synchronen SRAM werden die Adressen bei mit Flanke gespeichert, ebenso die Daten. Die Setup und Hold Zeiten gehen daher gegen Null... Außerdem muss man WR\ nicht toggeln, was wertvolle Zeit kostet, sondern es reicht, den Speichertakt anzulegen.

Weitere Typen wären

Asynchrone SRAM:

* CY22393,CY22394,CY22395 [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22393_4_5_5.pdf] mit Layout Hinweisen [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Layout%20Recommendations%20for%20the%20CY2239x%20Devices]
* AS7C34098-12TCN (256K x 16, 12ns) [http://www.alsc.com/pdf/sram.pdf/fa/AS7C4098.pdf] und AS7C31026B-12TCN (64k x 16, 12ns) Asynchroner SRAM bei Farnell

Synchrone SRAM:

* CY7C1327G (256k*18) [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327g_5.pdf]
* CY7C1327F (256k*18) [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327f_5.pdf]
* CY7C1327B (256k*18 Synchronous-Pipelined Cache RAM)[http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598266]

Den CY7C1327B (TQFP100 256Kx18, 3.3V, 4ns ) gibt's zumindest bei R&S für 11,60€

== Interface CPLD <-> uC ==

Eine grundlegende Idee ist, dass der CPLD doppelt benutzt wird. Er enthält ja einen Addresszähler zum Schreiben des SRAM's. Dieser kann aber auch zum Lesen des SRAM's benutzt werden. Der SRAM wird immer sequentiell vom PLD geschrieben und gelesen.

Die Daten, Statusinfos etc. werden per SPI vom AVR aus dem CPLD gelesen. Vorteil ist dabei, dass man nun auch z.B. 512Kb SRAM's benutzen kann ohne dass der uC ein kompliziertes Memory Banking benutzen müsste.

== Interface uC <-> Computer ==

Da die Daten schnell im PC sein sollen, bietet sich USB an, also mit dem
[http://www.ftdichip.com/Documents/DataSheets/ds245b16.pdf FT245]
um schneller (2-3 Mbaud) als der
[http://www.ftdichip.com/Documents/DataSheets/ds232b17.pdf FT232] (1 Mbaud)
die Daten zu versenden. FTDI bietet die Treiber für Windows/Linux kostenlose an.

Eine Alternative ist der
[http://www.silabs.com/public/documents/tpub_doc/dshort/Microcontrollers/Interface/en/CP2102_short.pdf CP2102], der weniger Bauelemente benötigt aber auch wesentlich schwerer zu löten ist.

uC mit integrierten USB standen auch in der Disskusion. Aufgrund vieler Unwägbarkeiten, wie Beschaffung, Preis, HID Treiber etc. sind diese Ideen wieder verworfen worden.

== Interface LA <-> DUT (Device under Test) ==

Prinzipiell gibt es zwei Wege, wie der LA an seine Informationen kommt:
* Der rein digitale Weg geht z.B. über 74AHC245 oder 74ACT14 o.ä. womit allerdings die Logikpegel feststehen.
* Ein anderer Weg geht über Analog-Komparatoren, bei denen die Logikpegel (Treshold) variabel sind und somit auch am flexibelsten für die versch. Logikfamilien [http://www.mikrocontroller.net/attachment.php/209385/Scan0004.png] ist.

Für die Komparatorlösung steht momentan der [http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf MAX964] und
[http://www.analog.com/UploadedFiles/Data_Sheets/155150085AD8564_a.pdf AD8564]
zur Debatte. Allerdings ist der MAX964 schwer zu beschaffen und bereits in der Dualvariante teurer als der AD8564 (ca. 10 Euro). Auch müssen diese mit 5V betrieben werden (wegen der TTL Eingänge und das der Eingspg.bereich von der VCC abhängt), wodurch Pegelwandler wie der 74LVC245 zum CPLD notwendig werden. Auch die Treshold-Reference muss in diesem Bereich liegen. Diese Schwelle wird durch einen DAC vorgegeben, der vom uC über SPI gesteuert wird. Dieser sollte eine interne Referenz besitzen um mit möglichst wenig Bauelementen auszukommen. Zudem sollte er über zwei Kanäle verfügen, da aktuell der LA über 2 pods mit jeweils einem 8 Bit-Channel verfügen soll. Z.Zt. scheint die beste Wahl hinsichtlich Parameter, Preis und Verfügbarkeit die [http://focus.ti.com/lit/ds/symlink/tlv5626.pdf TLV5626], [http://focus.ti.com/lit/ds/symlink/tlv5637.pdf TLV5637] und [http://focus.ti.com/lit/ds/symlink/tlv5638.pdf TLV5638] mit 8, 10 bzw. 12 Bit zu sein. Der Einsatz eines DAC wird wesentlich einfacher als eine PWM per uC mit anschließenden Tiefpaß mit OPVs, welches die Fehlerrate steigen lassen kann.

Bei einem digitalen Eingangsteil bietet sich folgendes an:
*[http://www.semiconductors.philips.com/acrobat/datasheets/74LVC14A_4.pdf 74lvc14] Hex inverting Schmitt-trigger with 5 V tolerant input; Dummerweise eben 6 Stck. - für 0,56? bei R&S
*[http://www.semiconductors.philips.com/acrobat_download/datasheets/74LVC541A_3.pdf 74LVC541] Octal buffer/line driver with 5 V tolerant inputs/outputs (3-state) für 0,71? bei R&S
*[http://www.semiconductors.philips.com/acrobat_download/datasheets/74HC_HCT7541_CNV_2.pdf 74HC7541] Octal Schmitt trigger buffer/line driver; 3-state für 9,85? bei R&S - damit können gerade langsame Busse untersucht werden da die Eingänge nicht so fürchterlich empfindlich sind; ansonsten ist es ein 541. Leider scheint es ihn nicht in der 74lvc zu geben.

Eine konzeptionelle Entscheidung zwischen der Ausführung der Input Stage als Komparator oder 74xx basierend ist also noch nicht getroffen.

Einigkeit besteht jedoch in der notwendigen Schutzschaltung, z.B. mit einem Dioden-Array. Auch darf die Eingangsspannung den Input Voltage Range (je nach Typ) nicht überschreiten.

== Clock Rate Generierung ==

Aufgrund seiner Bandbreite bietet sich die Generierung des Systemtaktes durch den CPLD an. Dieser benutzt einen 1/N Teiler um den Sample Takt zu generieren.

Prinzipiell kann er auch gleichzeitig den Takt für den uC erzeugen - dieser wird also extern getaktet und man erhält dadurch Synchronität zwischen CPLD und uC und spart den Quarz am uC. Allerdings bieted sich auch ein eigener Quarz für den uC an. Man sieht - hier wird noch diskutiert.

Zur Generierung des Mastertaktes bieten sich zwei Weg an:
* Quarz, bei 50-64 MHz dürfte da wegen Verfügbarkeit/Preis wohl Schluss sein, auch sind Obertonquarze nicht ganz unkritisch. Auch kann man dann nur noch durch umlöten und wecheln den Mastertakt ändern, falls es Probleme gibt.
* VCO/PLL ggf. per uC programmierbar, damit kann man dann echt die Grenzen des Designs austesten. Die Chips dazu gibt's bei Maxim/AD und den anderen üblichen Verdächtigen, stehen also noch nicht fest. Als aussichtsrechster Kandidat sticht derzeit der [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22150_5.pdf CY22150] hervor, der mehrere synchrone Freq. mit einem einfachen Quarz erzeugen kann. Dadurch wird der Freq.teiler im CPLD nicht mehr benötigt und hat wieder einige MC frei.

Die Grenzen der Samplefreq. liegen zum einem in den verwendeten Bauelementen (>100MHz), aber vielmehr wird der begrenzende Faktor das Layout und die Leiterplatte sein. Ein 4-Layer-PCB ist aus technischer Sicht sicher das optimale, nur schaut der Geldbeutel danach sehr leer aus; auch wird ein Komparatoreingang ca. 45 Euro teurer werden als eine Lösung mit 74xxx.

== Stromversorgung ==

Tja, auch ein LA braucht Strom. Bei Verwendung eines USB kann dieses elegant gelöst werden, da dieser (nach Anforderungen an das OS) bis zu 500mA liefern kann. Eine kurze worst-case "Stromrechnung" zeigt:

* XC95144XL CPLD pauschal 150mA lt. DB
* 61LV25616 SRAM 2x 320mA
* ATMega ???
* FT245 ????

mit Max964 8mA/Comparator x 16 kommen 128 mA hinzu.

Die FTDI-Chips haben für Geräte, die über 100mA ziehen (darin wird wohl der LA u.U. fallen ), aber noch bus-powered sein sollen, einen Schaltausgang, an den z.B. ein p-Kanal-FET angeschlossen werden kann, der den stromhungrigen Teil der Schaltung erst nach der Registrierung beim Computer einschaltet. Dazu hat er einen "sleep"-Ausgang, mit dem man den angeschlossenen AVR schlafen legen kann. In den FTDI-Docs bzw. Application Notes finden sich dazu genüg Beispiele mit kompletten Schaltbildern. Allerdings ergibt die Überschlagsrechnung, dass ein externes Steckernetzteil notwendig wird.

Einsetzbar wäre auch ein LM2575S-3.3 [http://www.national.com/ds/LM/LM1575.pdf] für 2,47€ (Farnell), der sieht gut und einfach in der Handhabung aus im Falle einer externen Stromversorgung.

= Programmierung =

== AVR ==
Recht früh hat sich in dem Forum heraus kristallisiert, dass der AVR per Bootloader vom Computer her programmiert werden sollte. Hierdurch sind Firmware Updates sehr einfach möglich und verschiedene Bootloader sind verfügbar. Die Bootloader Option setzt damit einen AVR der ATMega Serie vorraus.

Der AVR braucht folgende Anschlüsse:
* JTAG (4 Pins)
* SPI (3 Pins + ~4 CS Leitungen)
* FTDI (12 Pins)
* LEDs (2 Pins)

Demnach ist ein 40poliger nötig. Es wird ein ATMega16 angesetzt.

== CPLD ==

Die Programmierung des CPLD ist dagegen noch nicht konkret. Wünschenswert wäre es, ebenfalls seine Firmaware über den Computer zu updaten.

Der Standardweg der Programmierung der Xilinx CPLD sieht einen JTAG Stiftsockel vor. Dann kann die Programmierung z.B. über ein Xilinx JTAG/Parallel Download Cable [http://www.xilinx.com/support/programr/jtag_cable.pdf] aus dem ISE/impact geschehen.

Einen möglichen Weg stellt die XApp058 [http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf] dar, darin wird beschrieben, wie der CPLD mittels uC beschrieben wird.
Dieses Thema wurde bereits im Forum "AVR Ethernet Platine" aufgegriffen. In diesem Thread [http://www.mikrocontroller.net/forum/read-1-138024.html#157356] kam man allerdings zu der Überzeugung, dass die XSVF Datei mit 45kByte für uC Verhältnisse extrem groß ist und somit nur in einen ATMega128 (und größer) [http://www.atmel.com/dyn/products/devices.asp?family_id=607#760] reinpassen würde da das SVF JTAG Protokoll riesige Datenbuffer im SRAM benötigt. Dies ist protokollbedingt - es wurden 10kByte für ein FPGA genannt. Dabei sind die Xilinx CPLD Speicherplatz effezienter als welche von Altera. Leider sind die Xilinx CPLD eben nur über JTAG programmierbar.

Allerdings wurde in diesem Zusammenhang auch auf den XSVF Executor [http://www.ethernut.de/en/xsvfexec/index.html] verwiesen.
Auch ist die Frage noch offen, inwiefern die XSVF Datei über die RS232/USB geladen werden kann, ebenso das Timing der JTAG Schnittstelle.

Dies lässt sich z.B. ähnlich dem Projekt in der Codesammlung machen [http://www.mikrocontroller.net/forum/read-4-228557.html#233821]. Dann ist zum Programmieren des CPLDs nur eine Software auf dem PC nötig, die Daten werden über USB oder RS232 an den AVR gesandt und dort umgesetzt.

Aufgrund der vielen offenen Fragen ist die schnellste und sicherste Lösung die Anbindung über den JTAG Stecker um den CPLD per JTAG/Parallel Download Cable zu programmieren. Zusätzlich wird eine JTAG Verbindung zum AVR Port eingerichtet, falls das Problem irgendwann 'mal später gelöst wird.

Bisher existiert in VHDL für den CPLD LA Core:

* Trigger (bit pattern, rising/falling/any edge) verifiziert mit TB
* SRAM Interface

= PCB =

Dieses Thema kommt noch intensiv.

Dabei sind u.a. die folgenden Appl. Notes nützlich:

für AVR:

* AVR040: EMC Design Considerations [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf]
* AVR042: AVR Hardware Design Considerations [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf]

für CPLD:

* Device Package User Guide [http://www.xilinx.com/bvdocs/userguides/ug112.pdf]
* XAPP112 - Designing With XC9500XL CPLDs [http://www.xilinx.com/bvdocs/appnotes/xapp112.pdf]
* XAPP114 - Understanding XC9500XL CPLD Power [http://www.xilinx.com/bvdocs/appnotes/xapp114.pdf]
* XAPP115 - Planning for High Speed XC9500XL Designs [http://www.xilinx.com/bvdocs/appnotes/xapp115.pdf]
* XAPP784 - Bulletproof CPLD Design Practices [http://www.xilinx.com/bvdocs/appnotes/xapp784.pdf]

= Resumee =

Keep-It-Simple ist ein Grundsatz hier. Je komplexer, desto schwerer zu beherrschen. Sicher hat jeder von Komplexität eine andere Vorstellung, aber wir arbeiten daran und hoffen ein nachbaufähiges, stabiles Gerät zu bekommen. Dennoch kommt man bei diesem Projekt um SMD löten mit 0.5mm Beinchen nicht umhin!

= Und was soll das kosten? =

Schwierig, da noch nicht alles feststeht - als Ziel steht aber im Forum mehr oder weniger ungeschrieben die 100€ Marke einschließlich PCB.

== Datenblätter, Bezugsquellen und Preise (allg.) ==

... oder was bisher so zusammengetragen wurde.

{| border="1"
|-
| align="center" | '''IC'''
| align="center" | '''Gehäuse'''
| align="center" | '''Kommentar'''
| align="center" | '''Datenblatt/Appnotes'''
| align="center" | '''Bezugsquelle'''
| align="center" | '''Preis'''
|-
| ''CPLD'' / XC95144XL10TQ144
| align="center" | TQFP144
| align="center" | -
| align="center" | [http://www.mhl.tuc.gr/data_books/Xilinx/Xc9500/95144XL.pdf], [http://www.xilinx.com/xlnx/xweb/xil_publications_index.jsp?category=Publications/CPLD+Device+Families&iLanguageID=1]
| align="center" | [http://www.darisus.de/Elektonikshop/Framesets/Shopset1.php Darius.De]
| align="center" | ca. 10?
|-
| ''USB'' / CP1202
| align="center" | -
| align="center" | -
| align="center" | [http://www.silabs.com/public/documents/tpub_doc/dshort/Microcontrollers/Interface/en/CP2102_short.pdf]
| align="center" | -
| align="center" | -?
|-
| ''USB'' / FT232BM
| align="center" | LQFP-32
| align="center" | -
| align="center" | [http://www.ftdichip.com/Documents/DataSheets/ds232b17.pdf], [http://www.ftdichip.com/Documents/AppNotes.htm]
| align="center" | -
| align="center" | -?
|-
| ''USB'' / FT245BM
| align="center" | LQFP-32
| align="center" | -
| align="center" | [http://www.ftdichip.com/Documents/DataSheets/ds245b16.pdf], [http://www.ftdichip.com/Documents/AppNotes.htm]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / Max964 (Maxim)
| align="center" | SO-16
| align="center" | '''Quad''' Beyond-the-Rails Comparators, 4.5ns, 3V/5V
| align="center" | [http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / AD8564 (Analog Devices)
| align="center" | TSSOP-16
| align="center" | '''Quad''' 7 ns Single Supply 5V Comparator
| align="center" | [http://www.analog.com/UploadedFiles/Data_Sheets/155150085AD8564_a.pdf]
| align="center" | [http://www.spoerle.de Spörle.de]
| align="center" | 8,80? Netto
|-
| ''Comp'' / LT1715 (LT)
| align="center" | -
| align="center" | Dual 4ns, 5V/3V, Independent I/O Supplies
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1154,C1004,C1012,P1908,D2821]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / LT1720/LT1721 (LT)
| align="center" | -
| align="center" | Dual/Quad 4.5ns, 3V, Rail-to-RailOut, Quad schlecht für's Layout
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1154,C1004,C1012,P1707,D3080]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / TLV3502 (TI/BB)
| align="center" | SOIC-8
| align="center" | 4.5ns Rail-to-Rail, Dual High-Speed Comparator
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv3502.pdf]
| align="center" | -
| align="center" | -?
|-
| ''ECL-Comp'' / Max9600
| align="center" | -
| align="center" | Schwierig zu realisieren: 2 "Wandlungsstufen" notwendig. 1x Inputpegel -> ECL, 1x ECL -> Logikpegel CPLD
| align="center" | [http://pdfserv.maxim-ic.com/en/ds/MAX9600-MAX9602.pdf]
| align="center" | -
| align="center" | -?
|-
| ''DAC'' / TLV5626 (TI)
| align="center" | SOIC-8
| align="center" | 8-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5626.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 5.29?
|-
| ''DAC'' / TLV5637 (TI)
| align="center" | SOIC-8
| align="center" | 10-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5637.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 6.35?
|-
| ''DAC'' / TLV5638 (TI)
| align="center" | SOIC-8
| align="center" | 12-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5638.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 7.44?
|-
| ''DAC'' / LTC1446L (LT)
| align="center" | SO-8
| align="center" | Dual 12-Bit, 3.3V, int. Uref=2.5V
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1155,C1005,C1156,P1507,D1746]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 12.35?
|-
| ''Clk'' / CY22393,CY22394,CY22395
| align="center" | -
| align="center" | -
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22393_4_5_5.pdf] ,[http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Layout%20Recommendations%20for%20the%20CY2239x%20Devices]
| align="center" | -
| align="center" | -?
|-
| ''Clk'' / ICD2053B
| align="center" | -
| align="center" | -
| align="center" | [http://www.commtech-fastcom.com/data_sheets/icd2053b.pdf]
| align="center" | -
| align="center" | -?
|-
| ''Clk'' / CY22150FC
| align="center" | 16-lead TSSOP
| align="center" | Taktgeber, Three-PLL, SPI progr. Taktgenerator
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22150_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 3,94?
|-
| ''SRAM'' / IC61LV25616
| align="center" | TSOP-2
| align="center" | asynchroner SRAM 256KB x 16
| align="center" | [http://www.glyn.de/data/glyn/media/doc/IS61LV25616.pdf],[http://www.icsi.com.tw/english/products/products-frame.asp?Title=Datasheet-Async%20SRAM&URL=http%3A//web.icsi.com.tw/English/Datasheets/ASYNCHRONOUSSTATICRAM.html]
| align="center" | [http://www.glyn.de Glyn.De] ???
| align="center" | ???
|-
| ''SRAM'' / AS7C34098-12TCN
| align="center" | TSOP, SOJ
| align="center" | asynchroner SRAM 256K x 16, 12ns
| align="center" | [http://www.alsc.com/pdf/sram.pdf/fa/AS7C4098.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 13,17?
|-
| ''SRAM'' / CY7C1327B
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18, 3.3V, 4ns
| align="center" | [http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598266]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 11,60?
|-
| ''SRAM'' / CY7C1327G
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327g_5.pdf]
| align="center" | -
| align="center" | -?
|-
| ''SRAM'' / CY7C1327F
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327f_5.pdf]
| align="center" | -
| align="center" | -?
|-
| ''SRAM'' / CY7C1351F-100AC
| align="center" | TQFP100
| align="center" | Burst, synchron, Durchfluss, NoBL, 4MB, 128Kx36, 3.3V
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1351f_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 11,25?
|-
| ''SRAM'' / CY7C1381B-100AC
| align="center" | TQFP100
| align="center" | Burst, synchron, Durchfluss, 18MB, 512Kx36, 3.3V
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1381c_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 48,75?
|-
| ''IC'' / Dummy
| align="center" | -
| align="center" | -
| align="center" | -
| align="center" | -
| align="center" | -?
|}

= Literatur =

* [http://web.mit.edu/6.111/www/s2005/HANDOUTS/LA.pdf] Agilent XYZs of Logic Analyzers
* [http://cp.literature.agilent.com/litweb/pdf/5988-9125EN.pdf] Agilent Logic Analyzer Probing Techniques for High-Speed Digital Systems
* [http://www.home.agilent.com/USeng/nav/-536898184.0/pc.html] Agilent Logic Analyzer Probing Solutions
* [http://www.designcon.com/2003/marketing/HP3-5.pdf] Logic Analyzer Probing Techniques for High-Speed Digital Systems (DesignCon 2003)
* [http://www.signalintegrity.com/Pubs/straight/probes.htm] Probing High-Speed Digital Designs (Electronic Design Magazine, March, 1997)
* [http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf] Handheld Pocket Logic Analyzer (XApp368)
* [http://www.xilinx.com/bvdocs/appnotes/xapp369.pdf] Handheld 1553 Bus Data Analyzer (XApp369)
* [http://www.amateurfunkbasteln.de/pcla/pcla.html] PC-basierter 32-Kanal-Logik-Analysator
* [http://www.bitscope.com] bitscope
* [http://www.rockylogic.com/products/ant8spec.html] Ant8 (mit fixer Treshold) und
* [http://www.rockylogic.com/products/ant16spec.html] Ant16 (mit variabler Treshold)
* [http://alternatezone.com/electronics/pcla.htm] PC LA
* [http://eebit.com/] FPGA-based Logic Analyzer
* [http://www.nci-usa.com/default.htm] Kommerziell: GoLogic, mit guten Texten und Videos
* [http://www.ethernut.de/en/xsvfexec/index.html] XSVF Executor
* [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Jitter%20in%20PLL%20Based%20Systems:%20Causes,%20Effects,%20and%20Solutions] Jitter in PLL Based Systems: Causes, Effects, and Solutions

* [http://www.standardics.philips.com/packaging/handbook/pdf/pkgchapter5.pdf] SMD Mounting Methods

[[Kategorie:Logic Analyzer Project|Hardware]]

Logic Analyzer-Projekt: Ideen zur Hardware

2005-09-21T20:33:03Z

Clemens Helfmeier: /* AVR */

hier mal das Lastenheft für den Logic Analyser (LA). Bitte je nach Anforderung einen Strich mittels ALT GR + <> Taste links neben dem Ypsilon.
Die Aufteilung könnt ihr ja ändern/erweitern falls was fehlt. Ich gebe mal meine Maximalanforderungen ein.

'''Kanalanzahl'''
* .8 Kanäle: ||
* 16 Kanäle: ||||| ||||
* 20 Kanäle: |
* 24 Kanäle: |
* 32 Kanäle: ||||
* Modulair (erweiterbar X mal 8/16 Kanäle): ||

'''Samplingfrequenz'''
* ...8 MHz : |
* ..16 MHz : |
* ..32 MHz : ||
* .>32 MHz : ||||| ||||| |||

'''Speichertiefe'''
*....32 kByte: |
*....64 kByte:
*...128 kByte: |
*...256 kByte: |
*...512 kByte:
*..1024 kByte: |

Anmerkung: Wäre es nicht sinnvoller, die Speichertiefe in "Samples" anzugeben. So macht das nicht viel Sinn, da die Anzahl der Samples wenn man immer nur 8 Bits abspeichert ne andere ist als wie wenn man 32 Bits pro Sample speichert.

'''integrierter Pattern Generator'''
* .8 Kanäle : |
* 16 Kanäle:

Anm.: könnte bis zu einer gewissen Geschwindigkeit vom AVR erledigt werden... => uU. Mega16 drauf
--[[Benutzer:Hans|Hans]] 14:16, 20. Jul 2005 (CEST)

'''Schnittstelle zum Computer'''
* Seriell syncron..........: |
* Seriell asyncron (RS232).: ||||
* USB......................: ||||| |||||||
* Parallelport.............: ||
* Ethernet.................: |

'''Am PC läuft/wird laufen'''
* Windows .: ||||| ||||
* Linux .: ||||| |||||
* MacOS X .: |
* Solaris .: |
* Anderes .:

----

= Status =

(--[[Benutzer:84.182.244.75|84.182.244.75]] 10:43, 20. Sep 2005 (CEST) [ope])

Da der Logic Analyzer (LA) Thread schnell wächst und entsprechend schwer zu verfolgen ist, ständig sich irgend etwas ändert, kommt hier eine Zusammenfassung der Diskussion. Ich versuche sie halbwegs aktuell zu halten, öfteres Vorbeischauen lohnt sich also.

Eine fertige Lösung existiert jeodch noch nicht und einer alleine macht sich tot, zumal derjenige ja auch ein Real-Life hat und kein professioneller Designer für LA ist - daher ist das Projekt auf aktive Hilfe angewiesen sonst wird es sterben!

Auch sind die Threads dazu etwas verteilt (thematisch). Hier die grossen:

* [http://www.mikrocontroller.net/forum/read-1-204570.html#new Logic Analyzer bauen] (Initialthread)
* [http://www.mikrocontroller.net/forum/read-1-208137.html#new Pegelkomparator für High-Speed-Digital (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-234597.html#new Logic Analyzer Core (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-207389.html#new CPLD und AVR Kombo (Logic Analyzer)]
* [http://www.mikrocontroller.net/forum/read-9-221618.html#new Diverse Fragen bezueglich SRAM Anbindung]
* [http://www.mikrocontroller.net/forum/read-4-228557.html#new Programmieren des CPLDs über den AVR]

Eine reine AVR Lösung scheint sich hier abzuzeichnen:

* [http://www.mikrocontroller.net/forum/read-1-225498.html#new Logic Analyzer bauen, die 2.]

= Das Ziel =

Nun ja, preiswert und universell und für den Großteil der Probleme brauchbar soll er sein. Zudem sollen die Bauteile z.B. auch in Schweiz/Österreich gut verfügbar sein. Dass er sich mit einem LA der großen Hersteller messen lassen kann, ist aufgrund des Hobby Bereiches bzw. Proof-on-Concepts eher unwahrscheinlich. Unter den eben genanntenn Prämissen sollen die verfügbaren Mittel optimal genutzt werden.

Je nach Ergebnis, Lust und Laune wird es irgendwann evtl. eine Fortsetzung geben - aber das ist Zukunftsmusik.

= Grundlegende Überlegungen =

Im Internet kann man verschiedene, einfache Konzepte für einen LA finden, z.B. mittels Parallelport. Forumgerecht, reicht für einen einfachen LA bereits ein Mikrokontroller aus, der seine Ports polled um so die Logik Pegel mitzuschneiden. Allerdings ist diese Lösung begrenzt, wenn es um höhere Taktraten geht.

Eine erschwingliche Alternative stellt ein CPLD (Complex programmable logic devices) dar. Die CPLD z.B. von Xilinx können mit über 100MHz arbeiten und sind somit für diese Aufgabe prädestiniert. Leider ist die Anzahl der Macro Zellen zu gering, um eine hohe Speichertiefe zu erreichen. Daher werden die Daten vom CPLD in einem SRAM geschrieben. Damit ist der CPLD für die Triggerbedingungen des LA, dem Speicherinterface und natürlich dem eigentlichen sampeln der Eingänge verantwortlich. Der Mikrokontroller liest die Daten des SRAM über den CPLD aus und schickt sie an den Computer, übernimmt also die Kommunikation. Die Software stellt die gesampelten Daten sinnvoll und ansprechend dar.

Um die Störungen gering zu halten, wird als Versorgungspannung 3.3V Vorzug gegeben - ironischer Weise sind die Xilinx CPLD XC95000XL mit dieser Spannung preiswerter als in der 5V Version.

= Die Komponenten =

== Der CPLD und das Speicherinterface ==

Nach einigen Hin- und Her hat sich der XC95144XL TQ144 als beste Option herausgestellt. Auch FPGAs waren kurz im Gespräch, aufgrund der sich im Gespräch heraustellenden Komplexität. Allerdings war die Komplexität des FPGA und der Preis auch gleichzeitig das KO-Kriterium dafür.

Kurzinfo XC95144XL TQ144 [http://www.mhl.tuc.gr/data_books/Xilinx/Xc9500/95144XL.pdf]:

* 144Macro, 3.3V, 117 I/O, TQFP144 für ca. 10€

Dieser bietet genug I/O um:

* 2x SRAM 256k x 16 (jeweils 18 AD, 16 DB, 3 Ctrl)
* 2x 8-bit-LA-Channel
* Ext. TriggerIn, TriggerOut
* SPI Bus zum AVR
* JTAG

anschliessen zu können.

Der Grund für die 2 Speicherbänke liegen in den Möglichkeiten, sich den LA selbst zu konfigurieren für:

* Interleave
* Speicherung eines Timestamp
* non-Interleave und non-Timestamp mit nur einem SRAM

Beim Interleave werden zwei 16 Bit Samples im CPLD gelatched und gemeinsam auf den nun 32bit breiten Datenbus gelegt. Dabei sind die Adressen für die SRAMs folglich identisch. Damit beträgt die SChreibrate beim SRAM bei der Hälfte des Sampleclocks, der entsprechend hoch gesetzt werden kann.

Bei Verwendung des 2x 256k x 16 Bit SRAM eröffnet sich aber weiterhin die Möglichkeit, den Transitional Timing Analysis Mode zu realisieren, d.h. nur Bit-Änderungen werden mit einem Timestamp gespeichert - also ideal für langsame Busse bei hohen Sampleraten. Hier kann man zB. eine 16bit Time-Stamp-Adresse (256k) mit einem 16bit Pattern speichern, oder ein 24bit Timestamps für 8bit. Ein Interleave ist dann allerdings nicht mehr möglich.

Als letze Möglichkeit kann man auf alles obige Verzichten und nur einen SRAM bestücken.

Der heisseste Kandidat für den Speicher ist derzeit die 61LV25616 (256k*16) asynchrone Serie (zB.[http://www.issi.com/pdf/61LV25616AL.pdf IS61LV25616]), da er gut verfügbar und preiswert sein soll. Bei asynchronen SRAM müssen wie eingangs erwähnt die Adressen und Daten in einem Latch zwischen gespeichert werden. Bei einem synchronen SRAM werden die Adressen bei mit Flanke gespeichert, ebenso die Daten. Die Setup und Hold Zeiten gehen daher gegen Null... Außerdem muss man WR\ nicht toggeln, was wertvolle Zeit kostet, sondern es reicht, den Speichertakt anzulegen.

Weitere Typen wären

Asynchrone SRAM:

* CY22393,CY22394,CY22395 [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22393_4_5_5.pdf] mit Layout Hinweisen [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Layout%20Recommendations%20for%20the%20CY2239x%20Devices]
* AS7C34098-12TCN (256K x 16, 12ns) [http://www.alsc.com/pdf/sram.pdf/fa/AS7C4098.pdf] und AS7C31026B-12TCN (64k x 16, 12ns) Asynchroner SRAM bei Farnell

Synchrone SRAM:

* CY7C1327G (256k*18) [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327g_5.pdf]
* CY7C1327F (256k*18) [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327f_5.pdf]
* CY7C1327B (256k*18 Synchronous-Pipelined Cache RAM)[http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598266]

Den CY7C1327B (TQFP100 256Kx18, 3.3V, 4ns ) gibt's zumindest bei R&S für 11,60€

== Interface CPLD <-> uC ==

Eine grundlegende Idee ist, dass der CPLD doppelt benutzt wird. Er enthält ja einen Addresszähler zum Schreiben des SRAM's. Dieser kann aber auch zum Lesen des SRAM's benutzt werden. Der SRAM wird immer sequentiell vom PLD geschrieben und gelesen.

Die Daten, Statusinfos etc. werden per SPI vom AVR aus dem CPLD gelesen. Vorteil ist dabei, dass man nun auch z.B. 512Kb SRAM's benutzen kann ohne dass der uC ein kompliziertes Memory Banking benutzen müsste.

== Interface uC <-> Computer ==

Da die Daten schnell im PC sein sollen, bietet sich USB an, also mit dem
[http://www.ftdichip.com/Documents/DataSheets/ds245b16.pdf FT245]
um schneller (2-3 Mbaud) als der
[http://www.ftdichip.com/Documents/DataSheets/ds232b17.pdf FT232] (1 Mbaud)
die Daten zu versenden. FTDI bietet die Treiber für Windows/Linux kostenlose an.

Eine Alternative ist der
[http://www.silabs.com/public/documents/tpub_doc/dshort/Microcontrollers/Interface/en/CP2102_short.pdf CP2102], der weniger Bauelemente benötigt aber auch wesentlich schwerer zu löten ist.

uC mit integrierten USB standen auch in der Disskusion. Aufgrund vieler Unwägbarkeiten, wie Beschaffung, Preis, HID Treiber etc. sind diese Ideen wieder verworfen worden.

== Interface LA <-> DUT (Device under Test) ==

Prinzipiell gibt es zwei Wege, wie der LA an seine Informationen kommt:
* Der rein digitale Weg geht z.B. über 74AHC245 oder 74ACT14 o.ä. womit allerdings die Logikpegel feststehen.
* Ein anderer Weg geht über Analog-Komparatoren, bei denen die Logikpegel (Treshold) variabel sind und somit auch am flexibelsten für die versch. Logikfamilien [http://www.mikrocontroller.net/attachment.php/209385/Scan0004.png] ist.

Für die Komparatorlösung steht momentan der [http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf MAX964] und
[http://www.analog.com/UploadedFiles/Data_Sheets/155150085AD8564_a.pdf AD8564]
zur Debatte. Allerdings ist der MAX964 schwer zu beschaffen und bereits in der Dualvariante teurer als der AD8564 (ca. 10 Euro). Auch müssen diese mit 5V betrieben werden (wegen der TTL Eingänge und das der Eingspg.bereich von der VCC abhängt), wodurch Pegelwandler wie der 74LVC245 zum CPLD notwendig werden. Auch die Treshold-Reference muss in diesem Bereich liegen. Diese Schwelle wird durch einen DAC vorgegeben, der vom uC über SPI gesteuert wird. Dieser sollte eine interne Referenz besitzen um mit möglichst wenig Bauelementen auszukommen. Zudem sollte er über zwei Kanäle verfügen, da aktuell der LA über 2 pods mit jeweils einem 8 Bit-Channel verfügen soll. Z.Zt. scheint die beste Wahl hinsichtlich Parameter, Preis und Verfügbarkeit die [http://focus.ti.com/lit/ds/symlink/tlv5626.pdf TLV5626], [http://focus.ti.com/lit/ds/symlink/tlv5637.pdf TLV5637] und [http://focus.ti.com/lit/ds/symlink/tlv5638.pdf TLV5638] mit 8, 10 bzw. 12 Bit zu sein. Der Einsatz eines DAC wird wesentlich einfacher als eine PWM per uC mit anschließenden Tiefpaß mit OPVs, welches die Fehlerrate steigen lassen kann.

Bei einem digitalen Eingangsteil bietet sich folgendes an:
*[http://www.semiconductors.philips.com/acrobat/datasheets/74LVC14A_4.pdf 74lvc14] Hex inverting Schmitt-trigger with 5 V tolerant input; Dummerweise eben 6 Stck. - für 0,56? bei R&S
*[http://www.semiconductors.philips.com/acrobat_download/datasheets/74LVC541A_3.pdf 74LVC541] Octal buffer/line driver with 5 V tolerant inputs/outputs (3-state) für 0,71? bei R&S
*[http://www.semiconductors.philips.com/acrobat_download/datasheets/74HC_HCT7541_CNV_2.pdf 74HC7541] Octal Schmitt trigger buffer/line driver; 3-state für 9,85? bei R&S - damit können gerade langsame Busse untersucht werden da die Eingänge nicht so fürchterlich empfindlich sind; ansonsten ist es ein 541. Leider scheint es ihn nicht in der 74lvc zu geben.

Eine konzeptionelle Entscheidung zwischen der Ausführung der Input Stage als Komparator oder 74xx basierend ist also noch nicht getroffen.

Einigkeit besteht jedoch in der notwendigen Schutzschaltung, z.B. mit einem Dioden-Array. Auch darf die Eingangsspannung den Input Voltage Range (je nach Typ) nicht überschreiten.

== Clock Rate Generierung ==

Aufgrund seiner Bandbreite bietet sich die Generierung des Systemtaktes durch den CPLD an. Dieser benutzt einen 1/N Teiler um den Sample Takt zu generieren.

Prinzipiell kann er auch gleichzeitig den Takt für den uC erzeugen - dieser wird also extern getaktet und man erhält dadurch Synchronität zwischen CPLD und uC und spart den Quarz am uC. Allerdings bieted sich auch ein eigener Quarz für den uC an. Man sieht - hier wird noch diskutiert.

Zur Generierung des Mastertaktes bieten sich zwei Weg an:
* Quarz, bei 50-64 MHz dürfte da wegen Verfügbarkeit/Preis wohl Schluss sein, auch sind Obertonquarze nicht ganz unkritisch. Auch kann man dann nur noch durch umlöten und wecheln den Mastertakt ändern, falls es Probleme gibt.
* VCO/PLL ggf. per uC programmierbar, damit kann man dann echt die Grenzen des Designs austesten. Die Chips dazu gibt's bei Maxim/AD und den anderen üblichen Verdächtigen, stehen also noch nicht fest. Als aussichtsrechster Kandidat sticht derzeit der [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22150_5.pdf CY22150] hervor, der mehrere synchrone Freq. mit einem einfachen Quarz erzeugen kann. Dadurch wird der Freq.teiler im CPLD nicht mehr benötigt und hat wieder einige MC frei.

Die Grenzen der Samplefreq. liegen zum einem in den verwendeten Bauelementen (>100MHz), aber vielmehr wird der begrenzende Faktor das Layout und die Leiterplatte sein. Ein 4-Layer-PCB ist aus technischer Sicht sicher das optimale, nur schaut der Geldbeutel danach sehr leer aus; auch wird ein Komparatoreingang ca. 45 Euro teurer werden als eine Lösung mit 74xxx.

== Stromversorgung ==

Tja, auch ein LA braucht Strom. Bei Verwendung eines USB kann dieses elegant gelöst werden, da dieser (nach Anforderungen an das OS) bis zu 500mA liefern kann. Eine kurze worst-case "Stromrechnung" zeigt:

* XC95144XL CPLD pauschal 150mA lt. DB
* 61LV25616 SRAM 2x 320mA
* ATMega ???
* FT245 ????

mit Max964 8mA/Comparator x 16 kommen 128 mA hinzu.

Die FTDI-Chips haben für Geräte, die über 100mA ziehen (darin wird wohl der LA u.U. fallen ), aber noch bus-powered sein sollen, einen Schaltausgang, an den z.B. ein p-Kanal-FET angeschlossen werden kann, der den stromhungrigen Teil der Schaltung erst nach der Registrierung beim Computer einschaltet. Dazu hat er einen "sleep"-Ausgang, mit dem man den angeschlossenen AVR schlafen legen kann. In den FTDI-Docs bzw. Application Notes finden sich dazu genüg Beispiele mit kompletten Schaltbildern. Allerdings ergibt die Überschlagsrechnung, dass ein externes Steckernetzteil notwendig wird.

Einsetzbar wäre auch ein LM2575S-3.3 [http://www.national.com/ds/LM/LM1575.pdf] für 2,47€ (Farnell), der sieht gut und einfach in der Handhabung aus im Falle einer externen Stromversorgung.

= Programmierung =

== AVR ==
Recht früh hat sich in dem Forum heraus kristallisiert, dass der AVR per Bootloader vom Computer her programmiert werden sollte. Hierdurch sind Firmware Updates sehr einfach möglich und verschiedene Bootloader sind verfügbar. Die Bootloader Option setzt damit einen AVR der ATMega Serie vorraus.

Der AVR braucht folgende Anschlüsse:
* JTAG (4 Pins)
* SPI (3 Pins + ~4 CS Leitungen)
* FTDI (12 Pins)
* LEDs (2 Pins)

Demnach ist ein 40poliger nötig. Es wird ein ATMega16 angesetzt.

== CPLD ==

Die Programmierung des CPLD ist dagegen noch nicht konkret. Wünschenswert wäre es, ebenfalls seine Firmaware über den Computer zu updaten.

Der Standardweg der Programmierung der Xilinx CPLD sieht einen JTAG Stiftsockel vor. Dann kann die Programmierung z.B. über ein Xilinx JTAG/Parallel Download Cable [http://www.xilinx.com/support/programr/jtag_cable.pdf] aus dem ISE/impact geschehen.

Einen möglichen Weg stellt die XApp058 [http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf] dar, darin wird beschrieben, wie der CPLD mittels uC beschrieben wird.
Dieses Thema wurde bereits im Forum "AVR Ethernet Platine" aufgegriffen. In diesem Thread [http://www.mikrocontroller.net/forum/read-1-138024.html#157356] kam man allerdings zu der Überzeugung, dass die XSVF Datei mit 45kByte für uC Verhältnisse extrem groß ist und somit nur in einen ATMega128 (und größer) [http://www.atmel.com/dyn/products/devices.asp?family_id=607#760] reinpassen würde da das SVF JTAG Protokoll riesige Datenbuffer im SRAM benötigt. Dies ist protokollbedingt - es wurden 10kByte für ein FPGA genannt. Dabei sind die Xilinx CPLD Speicherplatz effezienter als welche von Altera. Leider sind die Xilinx CPLD eben nur über JTAG programmierbar.

Allerdings wurde in diesem Zusammenhang auch auf den XSVF Executor [http://www.ethernut.de/en/xsvfexec/index.html] verwiesen.
Auch ist die Frage noch offen, inwiefern die XSVF Datei über die RS232/USB geladen werden kann, ebenso das Timing der JTAG Schnittstelle.

Aufgrund der vielen offenen Fragen ist die schnellste und sicherste Lösung die Anbindung über den JTAG Stecker um den CPLD per JTAG/Parallel Download Cable zu programmieren. Zusätzlich wird eine JTAG Verbindung zum AVR Port eingerichtet, falls das Problem irgendwann 'mal später gelöst wird.

Bisher existiert in VHDL für den CPLD LA Core:

* Trigger (bit pattern, rising/falling/any edge) verifiziert mit TB
* SRAM Interface

= PCB =

Dieses Thema kommt noch intensiv.

Dabei sind u.a. die folgenden Appl. Notes nützlich:

für AVR:

* AVR040: EMC Design Considerations [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf]
* AVR042: AVR Hardware Design Considerations [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf]

für CPLD:

* Device Package User Guide [http://www.xilinx.com/bvdocs/userguides/ug112.pdf]
* XAPP112 - Designing With XC9500XL CPLDs [http://www.xilinx.com/bvdocs/appnotes/xapp112.pdf]
* XAPP114 - Understanding XC9500XL CPLD Power [http://www.xilinx.com/bvdocs/appnotes/xapp114.pdf]
* XAPP115 - Planning for High Speed XC9500XL Designs [http://www.xilinx.com/bvdocs/appnotes/xapp115.pdf]
* XAPP784 - Bulletproof CPLD Design Practices [http://www.xilinx.com/bvdocs/appnotes/xapp784.pdf]

= Resumee =

Keep-It-Simple ist ein Grundsatz hier. Je komplexer, desto schwerer zu beherrschen. Sicher hat jeder von Komplexität eine andere Vorstellung, aber wir arbeiten daran und hoffen ein nachbaufähiges, stabiles Gerät zu bekommen. Dennoch kommt man bei diesem Projekt um SMD löten mit 0.5mm Beinchen nicht umhin!

= Und was soll das kosten? =

Schwierig, da noch nicht alles feststeht - als Ziel steht aber im Forum mehr oder weniger ungeschrieben die 100€ Marke einschließlich PCB.

== Datenblätter, Bezugsquellen und Preise (allg.) ==

... oder was bisher so zusammengetragen wurde.

{| border="1"
|-
| align="center" | '''IC'''
| align="center" | '''Gehäuse'''
| align="center" | '''Kommentar'''
| align="center" | '''Datenblatt/Appnotes'''
| align="center" | '''Bezugsquelle'''
| align="center" | '''Preis'''
|-
| ''CPLD'' / XC95144XL10TQ144
| align="center" | TQFP144
| align="center" | -
| align="center" | [http://www.mhl.tuc.gr/data_books/Xilinx/Xc9500/95144XL.pdf], [http://www.xilinx.com/xlnx/xweb/xil_publications_index.jsp?category=Publications/CPLD+Device+Families&iLanguageID=1]
| align="center" | [http://www.darisus.de/Elektonikshop/Framesets/Shopset1.php Darius.De]
| align="center" | ca. 10?
|-
| ''USB'' / CP1202
| align="center" | -
| align="center" | -
| align="center" | [http://www.silabs.com/public/documents/tpub_doc/dshort/Microcontrollers/Interface/en/CP2102_short.pdf]
| align="center" | -
| align="center" | -?
|-
| ''USB'' / FT232BM
| align="center" | LQFP-32
| align="center" | -
| align="center" | [http://www.ftdichip.com/Documents/DataSheets/ds232b17.pdf], [http://www.ftdichip.com/Documents/AppNotes.htm]
| align="center" | -
| align="center" | -?
|-
| ''USB'' / FT245BM
| align="center" | LQFP-32
| align="center" | -
| align="center" | [http://www.ftdichip.com/Documents/DataSheets/ds245b16.pdf], [http://www.ftdichip.com/Documents/AppNotes.htm]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / Max964 (Maxim)
| align="center" | SO-16
| align="center" | '''Quad''' Beyond-the-Rails Comparators, 4.5ns, 3V/5V
| align="center" | [http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / AD8564 (Analog Devices)
| align="center" | TSSOP-16
| align="center" | '''Quad''' 7 ns Single Supply 5V Comparator
| align="center" | [http://www.analog.com/UploadedFiles/Data_Sheets/155150085AD8564_a.pdf]
| align="center" | [http://www.spoerle.de Spörle.de]
| align="center" | 8,80? Netto
|-
| ''Comp'' / LT1715 (LT)
| align="center" | -
| align="center" | Dual 4ns, 5V/3V, Independent I/O Supplies
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1154,C1004,C1012,P1908,D2821]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / LT1720/LT1721 (LT)
| align="center" | -
| align="center" | Dual/Quad 4.5ns, 3V, Rail-to-RailOut, Quad schlecht für's Layout
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1154,C1004,C1012,P1707,D3080]
| align="center" | -
| align="center" | -?
|-
| ''Comp'' / TLV3502 (TI/BB)
| align="center" | SOIC-8
| align="center" | 4.5ns Rail-to-Rail, Dual High-Speed Comparator
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv3502.pdf]
| align="center" | -
| align="center" | -?
|-
| ''ECL-Comp'' / Max9600
| align="center" | -
| align="center" | Schwierig zu realisieren: 2 "Wandlungsstufen" notwendig. 1x Inputpegel -> ECL, 1x ECL -> Logikpegel CPLD
| align="center" | [http://pdfserv.maxim-ic.com/en/ds/MAX9600-MAX9602.pdf]
| align="center" | -
| align="center" | -?
|-
| ''DAC'' / TLV5626 (TI)
| align="center" | SOIC-8
| align="center" | 8-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5626.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 5.29?
|-
| ''DAC'' / TLV5637 (TI)
| align="center" | SOIC-8
| align="center" | 10-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5637.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 6.35?
|-
| ''DAC'' / TLV5638 (TI)
| align="center" | SOIC-8
| align="center" | 12-Bit Dual, 3.3V, int. Uref 1.024V
| align="center" | [http://focus.ti.com/lit/ds/symlink/tlv5638.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 7.44?
|-
| ''DAC'' / LTC1446L (LT)
| align="center" | SO-8
| align="center" | Dual 12-Bit, 3.3V, int. Uref=2.5V
| align="center" | [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1155,C1005,C1156,P1507,D1746]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 12.35?
|-
| ''Clk'' / CY22393,CY22394,CY22395
| align="center" | -
| align="center" | -
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22393_4_5_5.pdf] ,[http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Layout%20Recommendations%20for%20the%20CY2239x%20Devices]
| align="center" | -
| align="center" | -?
|-
| ''Clk'' / ICD2053B
| align="center" | -
| align="center" | -
| align="center" | [http://www.commtech-fastcom.com/data_sheets/icd2053b.pdf]
| align="center" | -
| align="center" | -?
|-
| ''Clk'' / CY22150FC
| align="center" | 16-lead TSSOP
| align="center" | Taktgeber, Three-PLL, SPI progr. Taktgenerator
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy22150_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 3,94?
|-
| ''SRAM'' / IC61LV25616
| align="center" | TSOP-2
| align="center" | asynchroner SRAM 256KB x 16
| align="center" | [http://www.glyn.de/data/glyn/media/doc/IS61LV25616.pdf],[http://www.icsi.com.tw/english/products/products-frame.asp?Title=Datasheet-Async%20SRAM&URL=http%3A//web.icsi.com.tw/English/Datasheets/ASYNCHRONOUSSTATICRAM.html]
| align="center" | [http://www.glyn.de Glyn.De] ???
| align="center" | ???
|-
| ''SRAM'' / AS7C34098-12TCN
| align="center" | TSOP, SOJ
| align="center" | asynchroner SRAM 256K x 16, 12ns
| align="center" | [http://www.alsc.com/pdf/sram.pdf/fa/AS7C4098.pdf]
| align="center" | [http://www.farnell.de Farnell.De]
| align="center" | 13,17?
|-
| ''SRAM'' / CY7C1327B
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18, 3.3V, 4ns
| align="center" | [http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598266]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 11,60?
|-
| ''SRAM'' / CY7C1327G
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327g_5.pdf]
| align="center" | -
| align="center" | -?
|-
| ''SRAM'' / CY7C1327F
| align="center" | TQFP100
| align="center" | synchr SRAM 256k x 18
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1327f_5.pdf]
| align="center" | -
| align="center" | -?
|-
| ''SRAM'' / CY7C1351F-100AC
| align="center" | TQFP100
| align="center" | Burst, synchron, Durchfluss, NoBL, 4MB, 128Kx36, 3.3V
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1351f_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 11,25?
|-
| ''SRAM'' / CY7C1381B-100AC
| align="center" | TQFP100
| align="center" | Burst, synchron, Durchfluss, 18MB, 512Kx36, 3.3V
| align="center" | [http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1524_209_259_43/http%3B/sjapp20.mis.cypress.com%3B7001/publishedcontent/publish/design_resources/datasheets/contents/cy7c1381c_5.pdf]
| align="center" | [http://www.rsonline.de R&S (DE)]
| align="center" | 48,75?
|-
| ''IC'' / Dummy
| align="center" | -
| align="center" | -
| align="center" | -
| align="center" | -
| align="center" | -?
|}

= Literatur =

* [http://web.mit.edu/6.111/www/s2005/HANDOUTS/LA.pdf] Agilent XYZs of Logic Analyzers
* [http://cp.literature.agilent.com/litweb/pdf/5988-9125EN.pdf] Agilent Logic Analyzer Probing Techniques for High-Speed Digital Systems
* [http://www.home.agilent.com/USeng/nav/-536898184.0/pc.html] Agilent Logic Analyzer Probing Solutions
* [http://www.designcon.com/2003/marketing/HP3-5.pdf] Logic Analyzer Probing Techniques for High-Speed Digital Systems (DesignCon 2003)
* [http://www.signalintegrity.com/Pubs/straight/probes.htm] Probing High-Speed Digital Designs (Electronic Design Magazine, March, 1997)
* [http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf] Handheld Pocket Logic Analyzer (XApp368)
* [http://www.xilinx.com/bvdocs/appnotes/xapp369.pdf] Handheld 1553 Bus Data Analyzer (XApp369)
* [http://www.amateurfunkbasteln.de/pcla/pcla.html] PC-basierter 32-Kanal-Logik-Analysator
* [http://www.bitscope.com] bitscope
* [http://www.rockylogic.com/products/ant8spec.html] Ant8 (mit fixer Treshold) und
* [http://www.rockylogic.com/products/ant16spec.html] Ant16 (mit variabler Treshold)
* [http://alternatezone.com/electronics/pcla.htm] PC LA
* [http://eebit.com/] FPGA-based Logic Analyzer
* [http://www.nci-usa.com/default.htm] Kommerziell: GoLogic, mit guten Texten und Videos
* [http://www.ethernut.de/en/xsvfexec/index.html] XSVF Executor
* [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Jitter%20in%20PLL%20Based%20Systems:%20Causes,%20Effects,%20and%20Solutions] Jitter in PLL Based Systems: Causes, Effects, and Solutions

* [http://www.standardics.philips.com/packaging/handbook/pdf/pkgchapter5.pdf] SMD Mounting Methods

[[Kategorie:Logic Analyzer Project|Hardware]]

Projekt: Labornetzteil

2005-08-21T22:56:43Z

Clemens Helfmeier:

[[Category:Projekte]]

Diese Wiki-Seite soll als Entwicklungsmedium für ein Labornetzteil fungieren. Es wird ein modulares Labornetzteil entworfen und die Ergebnisse hier präsentiert.

=Aufbau (Zusammenfassung)=
Das Netzteil soll modular aufgebaut werden, so dass zusätzliche Erweiterungen einfach anzubinden sind. Dafür werden eine [[Projekt: Labornetzteil#Kontrolleinheit|Kontrolleinheit]] und eine oder mehrere [[Projekt: Labornetzteil#Regeleinheit(en)|Regeleinheit(en)]] beötigt. Die Verbindung wird duch eine [[Projekt: Labornetzteil#Schnittstelle (Zusammenfassung)|(noch zu definierende) Schnittstelle]] hergestellt.

==Kontrolleinheit (Zusammenfassung)==
Die Kontrolleinheit (später auch "Master" oder "Mastereinheit" genannt) ist für die Interaktion mit dem Benutzer zuständig. Nebenbei soll sie noch mit anderer digitaler Hardware (z.B. PC) interagieren können. Dazu werden folgende Schnittstellen benötigt:
* LC-Display: Dieses ist zum Anzeigen von Informationen nötig. Es wird ein [[HD44780|HD44780-Kompatibles]] Display eingesetzt. (Alternativ kann auch ein Grafikdisplay eingesetzt werden, um Ladungskurven etc direkt anzuzeigen)
* Taster: Zum Eingeben der Ausgangsspannung und des Ausgangsstrom werden Taster oder Drehgeber benötigt.
* RS232 oder USB für die Verbindung zum PC: Beides wird in das Layout aufgenommen und kann mit einem Jumper auf der Platine ausgewählt werden.

==Regeleinheit(en) (Zusammenfassung)==
Die Regeleinheiten (später auch "Slaves" oder "Slaveeinheiten" genannt) sind für das Regeln der Ausgänge zuständig. Sie brauchen eine Schnittstelle zur Kontrolleinheit, die ihnen die Sollwerte liefert und über die sie auch die Ist-Werte zurückgeben können. Weiterhin muss es eine Möglichkeit geben, die Kontrolleinheit über Statusänderungen zu informieren (z.B. kurzgeschlossener Ausgang, Überhitzung, etc.).
Die Slaves sollen im Grunde auch alleine Arbeiten und von der Kontrolleinheit NUR Sollwerte bekommen bzw IST Werte zu dieser senden.

Regeleinheiten müssen aus folgenden Blöcken bestehen:
* Galvanische Trennung von der Schnittstelle zur Kontrolleinheit (z.B. über Optokoppler)
* Verarbeitung der Informationen, ggf. Umwandlung in analoge Spannungen
* Regelung des Ausgangs

==Schnittstelle (Zusammenfassung)==
Die Schnittstelle zwischen Kontroll- und Regeleinheiten muss folgendes Leisten:
* galvanische Trennung
* Möglichekeit zur Anbindung mehrerer Regeleinheiten
* ggf. Interrupts

Zur Auswahl standen unterschiedliche Schnittstellen wie [[CAN|CAN]], [[SPI|SPI]], [[UART|UART]], [[I2C|I2C]].
Ausgewählt wurde eine etwas modifizierte UART-Schnittstelle. Diese wird von den meisten µControllern in Hardware unterstützt und kann somit besonders einfach und Rechenleistungsarm verwendet werden. Der Master muss seinen Empfänger mit Hilfe eines Multiplexers auf mehrere Slaves schalten können. Das Protokoll bestimmt den Slave, für den das Signal ist und auf den gehöhrt werden soll.

Eine andere (und unter umständen einfachere) Methode ist ein I2C Bus.
Hier wären keine Multiplexer notwendig und die Verwendung von 0815 Optokopplern wäre auch möglich...

Mehr zur Schnittstelle unter [[Projekt: Labornetzteil#Schnittstelle|Schnittstelle]].

=Schnittstelle=
==Elektrischer Aufbau==
Elektrischer Aufbau der Schnittstelle:
[[Bild:netzteil_interface.png|thumb|right|300px|Schnittstelle]]

Die elektrische Seite der Schnittstelle zwischen Master und Slave ist sehr einfach. Es werden nur zwei Optokoppler verwendet, einer davon braucht einen Tri-State-Ausgang.

==Protokoll==
Die Datenkommunikation geschieht paketorientiert. Ein Paket besteht immer aus 8 Byte.
Aufbau des Pakets:
{| border=1 cellpadding=2 cellspacing=0
!Offset
|align="center"| 0
|align="center"| 1
|align="center"| 2
|align="center"| 3
|align="center"| 4
|align="center"| 5
|align="center"| 6
|align="center"| 7
|-
!Inhalt
| Slave Addresse
| Reserviert
| Befehl low
| Befehl high
| Daten
| Daten
| Daten
| Daten
|}
Das Feld "Slave Addresse" ''muss immer'' mit der Addresse des Slaves gefüllt sein, der an der Übertragung beteiligt ist (er ist entweder Sender oder Empfänger). Für den Befehl sind folgende Werte vorgesehen:
{| border=1 cellpadding=2 cellspacing=0
! Wert
! Bedeutung
! genauere Beschreibung (Link)
|-
| 0x0000 - 0x00FF || Reserviert || [[Projekt: Labornetzteil#Reservierte Befehle|Reservierte Befehle]]
|-
| 0x0100 - 0x01FF || Information || [[Projekt: Labornetzteil#Informative Befehle|Informative Befehle]]
|-
| 0x1000 - 0xFFFF || Gerätspezifisch || [[Projekt: Labornetzteil#Geräte Befehle|Geräte Befehle]]
|}

===Reservierte Befehle===
Bereich: 0x0000 bis 0x00FF (Befehl high = 0x00)
Dieser Befehlsbereich wird reserviert und darf nicht genutzt werden.

===Informative Befehle===
Bereich: 0x0100 bis 0x01FF (Befehl high = 0x01)
Informative Befehle vermitteln dem Master, welche Gerätespezifischen Befehle der Slave unterstützt.

===Geräte Befehle===
Bereich: 0x1000 - 0xFFFF
Dieser Befehlsbereich wird vom System genutzt, um dem Slave mitzuteilen, welche Ausgangskonditionen anliegen sollen, und vom Slave zu erfahren, welche wirklich anliegen.

=Regeleinheiten=
Das Netzteil ist absichtlich modular aufgebaut. Dadurch kann sich der gewillte Nachbauer genau die Einheiten nachbauen, die er braucht. Die Modularität soll in erster Linie aber nicht dazu verwendet werden, aus dem Netzteil eine eierlegende Wollmichsau zu machen. Sattdessen sollen dadurch sinnvolle Vereinfachungen getroffen werden.

==Längsregler==
Längsregler haben viele gute Eigenschaften. Am deutlichsten hervorzuheben ist die gerine Ausgangswelligkeit (z.B. gegenüber Schaltnetzteilen) und das schnelle Regelverhalten. Dem gegenüber stehen hohe Verlustleistugen.
Das (chronologisch) erste Netzteilmodul ist ein Längsregler für Ausgangsspannungen bis 40V und Ausgangsströmen von 1A. Zugegebener Maßen ist das nicht viel, doch für den Anfang soll es reichen (immerhin schon 40W!)

'''Wer mit den Eckdaten (Ausgangsspannung/Ausgangsstrom) der folgenden Regeleinheiten nicht einverstanden ist, sollte eine neue Regeleinheit anlegen und nicht willkürlich die Werte ändern!'''

===Längsregler 40V 1A===
Diese Längsregeleinheit ist für eine Ausgangsleistung von 40W bei 40V ausgelegt.
Berechnung der Eingangsglieder:
* Ausgangsspannung 40V, es werden also mindestens 45V Versorgung gebraucht
* Der Gleichrichter hat 1V Spannungsabfall.
* Der Trafo braucht also (45+1)/sqrt(2) = 36V
* Damit wird der Ausgangselko im Leerlauf auf 36*1.5=55V aufgeladen
* Der Ausgangskondensator darf auf minimal 45V bei 1.5A (aufgerundet, wir wollen auf der sicheren Seite sein) abfallen. Das entspricht einer Kapazität von 1.5mF. Auch nach 10 Jahren sollte das Netzteil noch arbeiten, also nehmen wir Kondensatoren 2mF, 63V, Radial für Platinenmontage (2x RAD1.000/63)
* Die Ausgangsleistung (Gleichstrom) beträgt 36V*sqrt(2)*1.5A=78W, es wird ein Ringkerntransformator mit 80W, 2x18V gewählt (RKT8018). Dieser Liefert 2.22A
* Der Gleichrichter muss 1.5A gleichrichten, Sperrspannung 100V (B100C5000-3000) (ggf. etwas zu groß)

Damit hätten wir schonmal den ersten Teil (hier nur das, was nicht auf die Platine gelötet wird):
[[Bild:linear_trafo.png|500px|Trafo mit Netzfilter]]

Projekt: Labornetzteil

2005-06-14T16:28:55Z