Fahrplan für Neueinsteiger im ME7 Team

K3/EES-Homepage, K3/EES3
1 Allgemeines
1.1 Über dieses Dokument
1.2 Der Aufbau von Steps-ME7
2 Vorgehen beim Laden eines Programmstandes mit Codewright
3 Die Dateien eines Programmstandes
3.1 Verarbeitung der Programmstandsbeschreibung
3.2 Die Programmstandsbeschreibung (.PSB)
3.2.1 Kopfinformation
3.2.2 Verzeichnisstruktur
3.2.3 Zielbaum
3.2.4 Link-Invocation
3.3 Die Regeln (.RUL)
3.3.1 Aufbau einer Regel

1 Allgemeines

1.1 Über dieses Dokument

Diese Arbeitshilfe ist als Fahrplan für Neueinsteiger im ME7 Team gedacht und soll die schnelle Einführung in die Handhabung der Werkzeuge unterstützen. Die Handhabung von DAMOS++ kann in einem separaten Handbuch, das bei Herrn Hünerfeld (K3/EES4) zu erhalten ist, nachgelesen werden und wird daher hier nicht berücksichtigt.

1.2 Der Aufbau von Steps-ME7

Als Basis der Entwicklungsumgebung wird der Editor Codewright der Firma Premia eingesetzt. Die Offenlegung der Programmierschnittstelle durch Premia macht es möglich, eigene Funktionalität in die Umgebung zu integrieren und dabei auf eine Vielzahl bereits vorhandener Funktionen zurückzugreifen.
Vorhandene Werkzeuge Steps-ME7 integriert die Softwarewerkzeuge im ME7 Entwicklungsprozeß unter einer Oberfläche. Sie können mit Steps-ME7 den gesamten Prozeß der Programmerstellung abdecken:
  • Versionsverwaltung
  • Einsatz von Damos++
  • Compilierung
  • Debugging
  • Erzeugung von Dateien f�r Test-, Me�- und Applikationswerkzeuge
  • Listings mit absoluten Adressen
  • ...
Kurzanleitungen zur Bedienung verschiedener Werkzeuge der ME7 finden Sie im ME7 Info Center.

2 Vorgehen beim Laden eines Programmstandes mit Codewright

Der Ort, von dem die Programmstände geladen werden müssen, sind von Team zu Team verschieden. Dies sollte deshalb mit den jeweiligen Teamkollegen abgestimmt werden. Im Allgemeinen sind die Programmstände auf Laufwerk (S:) abgelegt. Dieses Laufwerk weist folgende Struktur auf:

Die Hauptverzeichnisse �M79", �Me71" usw. stehen für die Hardwarekennung. "Me71" kennzeichnet z.B. Steuergeräte-Hardware. Darunter liegen die Verzeichnisse �fest" und �int", die die diversen Programmstände enthalten. Das Verzeichnis �fest" enthält festgeschriebene Programmstände, die ablauffähig sind und nicht mehr verändert werden dürfen. Im Verzeichnis �int" (Integrationsstand) stehen die Programmstände, an denen noch gearbeitet wird. Ein Projektverzeichnis für einen Programmstand besitzt einen Namen wie z.B. 7103115c. Hieraus lassen sich Informationen über die Hardwarekennung (71), den Kunden (03), die Kundenprojektnummer (1) und die Revisionsnummer (15c) ablesen. Die wichtigsten Verzeichnisse eines Projektes sind �progst" mit den projektspezifischen Dateien, �outabgab" mit den Compilerausgaben und �d_files" mit den Ausgabefiles von Damos.
Einlesen eines Programmstandes Um nun einen Programmstand in Codewright einzulesen, ist der Menüpunkt �projekt/open" auszuwählen. In dem daraufhin geöffneten Dialogfenster muß in das Verzeichnis �progst" des gewünschten Programmstandes gewechselt werden. Hier findet sich eine Datei mit der Extension ".psb". Sie enth�lt alle Informationen �ber die Dateien und den Aufbau eines Programmstandes. Durch Doppelklicken auf diese Datei wird das Einlesen der Programmstandsbeschreibung gestartet. Hiernach wird der Benutzer gefragt, ob die Abhängigkeiten automatisch ermittelt werden sollen. Es gibt vier Fälle, in denen dies notwendig ist:
  1. Ein Programmstand wurde kopiert.
  2. Ein weiteres Modul wurde in die Programmstandsbeschreibung (.psb) aufgenommen.
  3. Im Projekt wurden Includeanweisungen hinzugefügt.
  4. Ein neues Projekt wird erzeugt.
Für die automatische Ermittlung der Abhängigkeiten werden zunächst die Regeldatei (.rul), die die Regeln mit allen f�r das �bersetzen der Dateien ben�tigten Informationen enth�lt, und die Programstandsbeschreibung (.psb) eingelesen. Danach werden die Quellfiles von einem Parser auf Includefiles hin untersucht. Kommentare werden hierbei ausgenommen. Bedingte Includes werden nicht erkannt. Nach dem Parsen der Quellfiles wird schließlich das im weiteren Verlauf für die Compilierung benötigte Makefile, das den gesamten Erzeugungsbaum eines Programmstandes enthält, generiert. Gibt es für den gewünschten Programmstand mehrere Konfigurationen, d.h. der Stand kann in angepaßter Form z.B. sowohl in Turbo- als auch für Saugmotoren eingesetzt werden, muß im nun angezeigten Dialogfenster die benötigte Konfiguration ausgewählt werden. Nach Abschluß des Einlesens des Programmstandes sind in Codewright zwei Editierfenster geöffnet, die die Dateien für die Regeln und die Programmstandsbeschreibung enthalten. Für die Beschreibung der Bedienoptionen, die Codewright bietet, sei auf die integrierte Hilfe bzw. auf die Bedienungshandbücher verwiesen.

Tips und Tricks zu Codewright
Shortcuts für die Bedienung von Codewright 5.0

3 Die Dateien eines Programmstands

Vorbemerkung: Ein Projekt heißt hier alle Dateien eines Programmstandes plus Dateien, die diesen Programmstand für Steps-ME7 beschreiben. Ein offenes Steps-ME7 Projekt ist also eine eingelesene Programmstandsbeschreibung - zu erkennen an einem Fenster mit gleichnamigem Titel.

Neben den Source-, Kenngrößen- und anderen Dateien, die Programmcode enthalten gibt es im wesentlichen zwei Dateien, die den Programmstand und seine Übersetzung beschreiben; die Programmstandsbeschreibung (.psb) und die Regeldatei (.rul).

3.1 Verarbeitung der Programmstandsbeschreibung

Programmstandsbeschreibung und Regeln sind ASCII-Dateien, die direkt mit einem Texteditor bearbeitet werden können. Durch das Verwenden von symbolischen Namen (Makros) ist es möglich, einen Programmstand ohne jede Änderung in einem anderen Verzeichnis auf einem anderen Rechner zu übersetzen - sofern gewisse Regeln eingehalten werden. Beim Einlesen wird ihr Inhalt sofort interpretiert, d.h. alle Symbole, die benutzt werden (Operator [ ]) müssen vorher definiert sein, angegebene Dateien existieren usw.. Danach wird eine Projektinstanz angelegt und ein Makefile generiert, das von einem Standard Make Utility (bei Steps-ME7 ist dies GNU Make) verarbeitet werden kann.

Erlaubte Konstrukte Unter anderem sind folgende Konstrukte erlaubt:
  • C++-Kommentare (also: /* */ und //)
  • Definieren von symbolischen Namen
    define-name(can-modul, �can71051.c")
  • Auswerten von symbolischen Namen mit []
    [C166] [can-modul]
  • Extrahieren von Pfad, Dateiname und/oder Dateierweiterung
    [a166-5.5] [source] to [pn, source].obj
  • Auswerten von Umgebungsvariablen
    define-name(MY_PATH, �[$, PATH];N:\Programme\Diverses")
  • Setzen von Umgebungsvariablen
    set-environment(MY_ENV, �N:\Programme\Diverses")
  • Verwendung von Variablen-/Symbole-Namen in Zeichenketten
    [out-dir]\ercdl00.c

3.2 Die Programmstandsbeschreibung (.PSB)

Die Namenskonvention für eine Programmstandsbeschreibung lautet: .psb, also zum Beispiel: 71051.psb.

3.2.1 Kopfinformation

Diese Information muß immer am Anfang der Datei (Kommentare ausgenommen) in genau dieser Reihenfolge auftreten.
Projekt-Manager-Version(1.0) Programmstand([project]10a) PVCS-Version-Label(int[pst-id]) Rules([project].rul)
Vordefinierte Symbole Das Symbol project gehört zu einer Reihe von vordefinierten Symbolen und wird mit dem Namen der Programmstandsbeschreibungsdatei als Wert vorbelegt - in unserem Beispiel also mit 71051. Nach dem Einlesen von Programmstand() ist das Symbol pst-id gesetzt. Es wird verwendet, um die Namen der Ergebnisdateien festzulegen (Bsp.: hexfile, binärfile etc.).

3.2.2 Verzeichnisstruktur

Als nächstes sollten die Verzeichnisse des Programmstandes aufgeführt werden, die Source Dateien (keine Header) enthalten. Diese Angabe erfolgt über
add-search-path([.]\asic)
add-search-path([.]\ercos)
Auch hier wird wieder ein vordefiniertes Symbol verwendet, nämlich �.�. Es steht für das Verzeichnis eine Stufe über dem Verzeichnis, in dem die Programmstandsbeschreibung liegt.

Beispiel: Für
S:\sw\int\7105110A\Progst\71051.psb
ist [.] gleich
S:\sw\int\7105110A.
Die Pfade werden in der Reihenfolge ihrer Angabe durchsucht. Die Include-Verzeichnisse für den Compiler werden in den Regeln angegeben, eine Angabe mittels add-search-path() wäre nutzlos.

Hinweis: Die Pfade können auch absolut angegeben werden - also zum Beispiel add-search-path(u:\sw\int\fuellerf). Vor dem Einchecken des Programmstandes sollten jedoch alle Pfade relativ, d.h. mit [.] angegeben werden, da nur so gewährleistet ist, daß der Programmstand unter einem beliebigen Verzeichnis ohne Änderung übersetzt werden kann.

3.2.3 Zielbaum

Der Zielbaum gibt an, wie der Programmstand zusammengebaut werden muß, das heißt welche Source Dateien zu TASKs oder Bibliotheken zusammengefaßt werden und wie diese Unterziele dann letztlich zur Binär Datei gebunden werden. Syntaktisch wird ein Ziel folgendermaßen definiert:
ZielName
{
Datei
:
}
Es darf insgesamt nur einen Zielbaum, also nur ein Hauptziel geben. Jedes Ziel dieses Zielbaums darf aber beliebig viele Unterziele haben, die auch wieder Unterziele haben dürfen.

Beispiel:
[pst-id].66				// Hauptziel Binärfile
{
	[bso-5.0-crtlib]		// Standardlib dazubinden
	
	[out-dir]\ercos08.lno	// Unterziel: Ercos Task
	{
	cstart1.asm			// Assembler Source Datei
	ercdl00.c			// C Source Datei
	7x000t.c
	7x000c.c
	}

	[out-dir]\zahn001.lno	// Unterziel Zahn Task
	{
	task(ZAHN)			// Angabe des Tasknamens
	zahn001.a66
	}

	[out-dir]\tnot001.lno
	{
	tnot001.a66
	xyz.lib			// Unterunterziel Bibliothek xyz
		{
		modul1.c		// Source Datei für xyz
		modul2.c
		}
	}
}
Spezialziele [kgs-files] und [special] Es sind zwei spezielle Unterziele eingerichtet, um Kenngrößendateien zu bearbeiten und zusätzlich Dateien, die nicht im Übersetzungsprozeß auftreten, wie zum Beispiel Word-Dokumente (Integrationsdoku), zu archivieren:
  1. [kgs-files]:
    Unterziel f�r die Kenngr��endateien. Es werden hier alle Kenngr��endateien aufgef�hrt, die zu diesem Programmstand geh�ren. Dabei ist darauf zu achten, da� Dateien, die von anderen Funktionen ben�tigt werden (z.B. St�tzstellenberechnung) vor diesen aufgelistet werden.

  2. [special]:
    Dateien, die in die Dateiliste des Projektes �bernommen werden, obwohl sie f�r die Erzeugung des Programmstandes nicht ben�tigt werden. Hier sollten solche Dateien eingetragen werden, die keine Sourcedateien o.�. sind, aber dennoch zum Programmstand geh�ren. Die Dateiliste des Projektes ist die Grundlage f�r verschiedene Aktionen, unter anderem zum Generieren eines Programmstandes.

3.2.4 Link-Invocation

Der letzte Bereich legt den Inhalt der Link-Invocation Datei fest. Für eine ausführliche Erklärung der einzelnen Anweisungen wird auf das Tasking Reference Manual Volume II verwiesen. Alles was zwischen den Schlüsselworten begin-of-file und end-of-file steht, wird beim Öffnen des Projektes in eine Datei mit dem Namen, der über file name angegeben wurde, geschrieben. Dieser Mechanismus wird momentan nur benutzt, um die Link-Invocation Datei zu schreiben. Er könnte aber auch verwendet werden, um andere Dateien anzulegen.
file [project].inv
begin-of-file
TEXT
end-of-file
erzeugt eine Datei Namens 71051.inv, die die Zeile TEXT enthält.

3.3 Die Regeln (.RUL)

Die Regeldatei sollte im Normalfall so heißen wie die Programmstandsbeschreibung und die Erweiterung .rul haben. Trägt sie einen anderen Namen, so muß man diesen im Kopf der Programmstandsbeschreibung bekannt machen. Dies entspricht allerdings nicht dem Standardvorgehen und sollte vor dem Einchecken wieder korrigiert werden. Wenn Sie verschiedene Regeln definieren wollen - z. B. um einmal für den ETK (Emulator Tastkopf) und ein anderes Mal für den �richtigen" Programmstand zu compilieren - dann sollten Sie besser die Möglichkeit verschiedener Konfigurationen nutzen.

Aufbau der Regeldatei

Die Regeldatei besteht aus einer Kopfinformation und einer beliebigen Anzahl von Regeln. Die Kopfinformation enthält lediglich die Zeile

Projekt-Manager-Version(1.0)

- danach folgen die einzelnen Regeln.

3.3.1 Aufbau einer Regel

Eine Regel hat einen Typ, einen Namen, genau einen Zieltyp, 1 bis N Quelltypen, optional Abhängigkeiten und 1 bis M Kommandos, die in der Reihenfolge ihrer Angabe abgearbeitet, d.h. in den Makefile geschrieben, werden.

Es gibt zwei Typen von Regeln, die sich in der Kardinalität ihrer Quelldateien unterscheiden:

  1. Die 1-1-rule (abgekürzt rule) bekommt eine Quell- und eine Zieldatei (Bsp.: Regel für C Sourcen).
  2. Die 1-N-rule kann mehrere Quelldateien verarbeiten (Bsp.: Regel für den Linker).

Die Ziel- und Quelltypen einer Regel werden über ihre Dateierweiterungen angegeben. Jede Regel kann mehrere Quelltypen haben. Das heißt eine 1-1-rule kann zum Beispiel für die Quelltypen .src, .asm, .a66 definiert sein, verarbeitet aber nur eine Quelldatei nach der anderen.

Ist eine Abhängigkeit angegeben, wird sie für jeden Knoten des Zielbaumes, der mit dieser Regel verknüpft ist, eingetragen. Auf diese Weise kann man Abhängigkeiten definieren, die nicht automatisch festgestellt werden können. Zum Beispiel sollte so die Abhängigkeit aller Assembler Sourcen von der Portdefinitionsdatei reg167me.def festgelegt werden.

Ein Kommando steht zwischen doppelten Hochkommas und kann sich über mehrere Zeilen erstrecken. Müssen innerhalb des Kommandos doppelte Hochkommas verwendet werden, so kann man diese mittels einfachen gefolgt von doppelten Hochkommata angeben, z. B. -DPROJECT_H='"[project].h'".

Innerhalb einer Regel - also auch innerhalb der Kommandos - sind symbolische Namen erlaubt. Drei spezielle symbolische Namen werden automatisch belegt:

[source] steht für die (Menge der) Quelldatei(en).
[target] steht für die Zieldatei.
[dep-n] wird definiert, um auf die angegebenen Abhängigkeiten referenzieren zu können, wobei n für eine Zahl zwischen 1 und N steht und die Position der referenzierten Abhängigkeit innerhalb der angegebenen N Abhängigkeiten darstellt.

Ein führender Klammeraffe (@) im Kommando unterdrückt die Ausgabe des Kommandos im Ausgabefenster von CodeWright.

Beispiele für Regeln:
1-N-rule
1-N-rule obj-2-lno
.lno : .obj .lib
"echo ---- Linking [ne, target]"
"@[BSO-5.0-Linker] [source] CASE nowa(118) to [target]"
end-rule
1-1-rule
rule c-2-obj
.obj : .c  [.]\progst\[project].h
"echo ---- Compiling [ne, source]"
"@[BSO-5.0-CC] [more-options]
   -DPROJECT_H='"[project].h'"
   -I[.]\Include
   -I[.]\header
   -I[.]\d_files
   -I[.]\ercos
   -I[.]\progst
   -g -x -Ms -Hreg167me.h -H[dep-1] 
   -o [out-dir]\[n,source].src [source]"
"@[BSO-5.0-Asm] [out-dir]\[n,source].src EX SN(reg167me.def)
NOM166 EP([pn,target]) PR([pn,target]) TO [target]"
end-rule

Diverses

Programme für die ME7-Entwicklungsumgebung
Wichtige Verzeichnisse der ME7
Bei Fragen und Problemen

Schaubilder

Ablauf & Komponenten des Makefiles
Übersicht des Datenflußes in der ME7
Vorgehen bei der Änderung eines Modules


K3/EES3 Fa. ISS - Mohring Michael
Letzte Änderung: August 1997