Automatische Codegenerierung: Mythos und Realität

Die Codegenerierungs-Technologie von
The MathWorks bietet dem Anwender
vielerlei Möglichkeiten, Einfluss auf den
automatisch generierten Code zu nehmen.
So ist es beispielsweise möglich,
bereits vorhandene Bibliotheken anstelle
des automatisch generierten Standard-
Codes einzubinden und/oder eigene
Hilfsprogramme per „Hook-In“ in den
Prozess der Codegenerierung einzubringen.
Auch die angeführte mangelnde
Einflussnahmemöglichkeit auf das Packaging
und das Layout des Codes ist nicht
richtig. Simulink und der Real-Time
Workshop Embedded Coder bieten umfangreiche
Möglichkeiten, beides zu beeinflussen.
So kann beispielsweise der Code für den in
Abbildung 1 gezeigten PD-Regler ganz einfach
mithilfe des in Abbildung 2 dargestellten Dialogs
als Funktion generiert werden. Außerdem
kann auch die Anforderung hinsichtlich eines
bestimmten Dateilayouts durch die Verwendung
frei gestaltbarer Vorlagen (Templates) für
den Code und die Daten erfüllt werden (vgl.
Abbildung 3).
degenerierung um rund 30 Prozent über der
Produktivität bei einer Programmierung von
Hand liegt. Diese Tatsache wiegt die Kosten für
den Codegenerator mehr als auf und spricht
vom Standpunkt des Return-on-Investment aus
gesehen für die automatische Codegenerierung.
Mythos: Leistung
Abb. 2:
Code-Platzierungs-Dialog
Die automatische Codegenerierung für das
Rapid Prototyping kann dem Target-Prozessor
insbesondere im Hinblick auf die Speichernutzung
mehr Ressourcen abverlangen, als zur
Implementierung des nackten (Regelungs-)
Algorithmus nötig wäre. Dies trifft jedoch immer
zu, egal, ob der Code per Hand oder automatisch
geschrieben wurde. Das liegt vor allem
an dem beim funktionalen Rapid Prototyping
hohen Entwicklungskomfort wie Parameter-
Tuning und Signal-Monitoring „on-the-fly“
und der ausschließlichen Verwendung von
Gleitkomma-Datentypen. Geht man jedoch
vom funktionalen Rapid Prototyping zur
Produktion über, ist die freie Einstellbarkeit
jedes einzelnen Parameters nicht gewünscht.
Außerdem müssen die Algorithmen (zumindest
für Massengüter) in Festkomma-Arithmetik
implementiert werden. In Verbindung mit den
mächtigen, vom Codegenerator angebotenen
Optimierungs-Techniken ist der automatisch erzeugte
Code der manuellen Programmierung in
Bezug auf Laufzeitleistung und Speicherbedarf
durchaus ebenbürtig. Aktuelle
Arbeiten unabhängiger Anwender
belegen dies [3], [4].
Mythos: mangelnde
Einflussnahme-möglichkeit
Mythos: mangelnde Integrationsmöglichkeit
Wenn nur ein Teil des Programmcodes eines Projektes
automatisch erzeugt werden soll, ist eine
anwenderfreundliche Schnittstelle zwischen
den automatisch und den manuell erzeugten
Teilen des Codes von allergrößter Wichtigkeit.
Diese Forderung wird von den so genannten
Entry Points und der Datenschnittstelle erfüllt.
Der Real-Time Workshop Embedded Coder erzeugt
drei Entry-Points: Eine Initialisierungs-
Funktion („Initialize“), eine Schritt-Funktion
und eine Beendigungs-Funktion („Terminate“).
Die Datenschnittstelle kann praktisch jede
mögliche Anforderung des Anwenders erfüllen.
Er hat die volle Kontrolle über die Benennung
sämtlicher Variablen auf der Eingangs- und
Ausgangsseite einer automatisch erzeugten
Anwendung. Außerdem können vordefinierte
oder vom Anwender selbst erzeugte Custom
Storage Classes verwendet werden, um auf
nicht standardgemäße Art und Weise auf Daten
zuzugreifen.
Mythos: Ressourcen-Hunger
In der Anfangszeit der automatischen Codegenerierung
traf es durchaus zu, dass dieses
Verfahren überwiegend für große Prozessoren
mit hoher Leistung und großem Speicher geeignet
war. Mittlerweile hat die automatische Codegenerierung
aber ein Reifestadium erreicht, in
dem sie sogar für 8-Bit Mikroprozessoren anwendbar
ist.
Mythos: begrenzte
Einsatzmöglichkeit
Dass die automatische Codegenerierung nur
auf sehr wenige Mikrocontroller anwendbar
ist, ist schlicht und einfach falsch! Auch wenn
bestimmte Mikrocontroller durch Erweiterungspakete
zum Codegenerator („Embedded
Targets“) explizit unterstützt werden, so gilt
jedoch generell: Automatische Codegenerierung
ist für jeden Mikrocontroller möglich, für den
auch manuell Code in C geschrieben werden
kann. Auch die Annahme, dass die modellbasierte
Entwicklung sich nur für zeitkontinuierli-