Es gibt nun den Befehl „Plausibilitätsprüfung durchführen“ („Perform Sanity Check“), zu finden unter Hauptmenü „Optionen“. Dabei wird unter anderem überprüft:
Optional wird die Plausibilitätsprüfung auch automatisch bei der Quellcodegenerierung und bei der Switch-Case-Generierung durchgeführt. Dazu gibt es eine Checkbox unter Menü Optionen > Zustandsdiagramm-Einstellungen > Validierung/Einschränkungen.
Bislang mussten die Einstellungen zur Codegenerierung prinzipiell für jedes Zustandsdiagramm einzeln vorgenommen werden. Jetzt können die Codegenerierungseinstellungen auch projektabhängig gesetzt werden. Dazu gibt es den neuen Menüpunkt Projekt > Einstellungen für das aktuelle Projekt > Codegenerierung aus Statecharts. Diese Einstellungen gelten für alle im Projekt enthaltenen Zustandsdiagramme und werden angewendet, wenn der Befehl „Code aus allen Statecharts des Projekts generieren“ ausgeführt wird. (Die dem jeweiligen Zustandsdiagramm zugeordneten Einstellungen werden dabei ignoriert.) Wenn der Anwender dagegen den Befehl „Code generieren“ für ein einzelnes im aktuellen Projekt enthaltenes Zustandsdiagramm aufruft, wird per MessageBox nachgefragt, welche Einstellungen verwendet werden sollen. In den Beispielprojekten (EasyCODE-Unterverzeichnis Samples) werden nun projektweite Codegenerierungseinstellungen verwendet.
In den Codegenerierungseinstellungen können nun Einfügemarkierungen (Beginn-Markierung und End-Markierung) für die Zieldatei angegeben werden. (Dies war bislang nur eingeschränkt innerhalb der Benutzerdefinierten Erstellung möglich.) Die Einfügemarkierungen erlauben es,
Die Wirkungsweise bei der Codegenerierung:
Wenn die Zieldatei Zeilen mit Einfügemarkierungen enthält, dann wird nur der Bereich zwischen diesen Zeilen durch den generierten Code ersetzt. Wenn die Zieldatei mehrere solcher Bereiche enthält, dann wird die Ersetzung entsprechend mehrmals durchgeführt. Wenn die Zieldatei nur die Endmarkierung enthält, dann wird der generierte Code direkt vor dieser Zeile eingefügt, ohne bestehenden Code zu überschreiben. Andernfalls, d.h. wenn die Zieldatei die Markierungen nicht oder nicht vollständig oder nicht in der richtigen Reihenfolge (zuerst Beginn-, dann Endmarkierung) enthält, wird der generierte Code nicht eingefügt. (Beschreibung in Hilfekapitel 13.6.)
Neben XSLT-Skripts können nun auch C#-Skripts für die Codegenerierung aus Statecharts verwendet werden. Die neue interne Komponente EcCodeGenerator dient zur Kompilierung und Ausführung solcher C#-Skripts. Sie wird automatisch verwendet, wenn die für die Codegenerierung angegebene Skriptdatei anstelle ".xsl" die Erweiterung „.cs“ besitzt.
(Optional kann an den Pfad der Skriptdatei - nach einem Doppelpunkt - der Name der im Skript aufzurufenden Methode angehängt werden.)
Die angegebene C#-Datei wird zur Laufzeit kompiliert; dabei werden die Fehlermeldungen des C#-Compilers ggfs. in EasyCODE ausgegeben (im Ausgabefenster bei Benutzerdef. Erstellung, sonst in einer MessageBox). Wurde einmal ein Kompilat erstellt, dann wird es bei weiteren Codegenerierungen wiederverwendet, solange die EasyCODE-Instanz geöffnet ist und die Skriptdatei nicht zwischenzeitlich geändert wurde.
Im EasyCODE-Unterverzeichnis EcFramework finden Sie für jede XSLT-Skriptdatei (*.xsl") ein Pendant in C# ("*.cs").
Die Verwendung von C#-Skripts ist für Sie dann interessant, wenn Sie unsere Standardskripts ändern/erweitern möchten, sei es, um Details zu ändern, um Ihren besonderen Anforderungen Rechnung zu tragen, sei es, um ein komplett anderes Entwurfsmuster für Zustandsautomaten zu implementieren. C#-Code lässt sich nämlich wesentlich leichter lesen und schreiben als XSLT-Code und bietet darüber hinaus wesentlich bequemere und umfangreichere Möglichkeiten, die aus dem XML-Baum ausgelesenen Diagrammdaten zu verarbeiten. Und nicht zuletzt versorgt Sie der C#-Compiler mit sehr aussagekräftigen Fehlermeldungen. (Beschreibung in Hilfekapitel 13.6 und 13.11.)
Die Funktion Generate All generiert alle SPX-Dateien eines in der Kommandozeile angegebenen Verzeichnisses. Der Verzeichnispfad wird mit dem Kommandozeilenparameter „GI=“ angegeben. Die generierten Dateien werden im gleichen Verzeichnis gespeichert, es sei denn man verwendet den Parameter „GO=“, mit dem ein alternatives Ausgabeverzeichnis festgelegt werden kann.
Im Multithreading-Modus (d.h. wenn USE_MULTITHREADING definiert ist) laufen inkludierte Subautomaten jetzt nicht mehr in einem eigenen Thread, sondern im Thread des Containerautomaten.
Bei der Codegenerierung werden deaktivierte Ereignisse, Guards und Aktionen jetzt mit dem Attribut disabled nach XML exportiert. Die Generierungsskripts wurden angepasst, so dass nur noch für Ereignisse, Guards und Aktionen, die nicht das Attribut disabled haben, Code generiert wird.
Die Anzeige von Zustandsvariable, Triggervariable und Transitionscode unterhalb des Zustandsdiagramms kann jetzt abgeschaltet werden. (Diese Angaben spielen nur bei der Generierung eines switch-case-Konstrukts eine Rolle.) Die entsprechende Checkbox finden Sie unter Menü Optionen > Zustandsdiagramm-Einstellungen > Ansicht. Diese Einstellung wird mit dem jeweiligen Zustandsdiagramm gespeichert. Optional kann die aktuelle Einstellung als Standard für neue Zustandsdiagramme gespeichert werden.
Standardmäßig werden beim Öffnen einer C/C++-Datei auch die meisten Präprozessor-Anweisungen (z.B. #ifdef ...) erkannt, analysiert und dann im Struktogramm in Form eines speziellen Elements angezeigt. Hin und wieder jedoch stoßen EasyCODE-User auf Situationen, in denen es besser wäre, wenn Präprozessor-Anweisungen als solche ignoriert und stattdessen nur in einem einfachem Textelement dargestellt würden.
Beispiel:
Eine Datei wurde mit einer älteren EasyCODE-Version bearbeitet, die noch keine Präprozessoranweisungen erkennen konnte. Die Datei enthält jedoch Präprozessoranweisungen, die sich über mehrere Struktogrammelemente erstrecken und diese quasi "zerschneiden". Beim Einlesen einer solchen Datei mit einer neueren EasyCODE-Version kommt es dann zwangsläufig zu Problemen. In diesem Fall wäre es sinnvoll, die Erkennung von Präprozessor-Anweisungen zu deaktivieren. Diese Option ist nun einstellbar: Öffnen Sie dazu das Tool EasyCODE Configuration, wählen Sie dann den Bereich CPP und scrollen Sie zum Bereich Einstellungen. Dort finden Sie die Auswahlbox "Präprozessor-Anweisungen parsen..."
In den Erstellungsstufen kann nun angegeben werden, dass der Exit Code des per Kommandozeile aufgerufenen Prozesses (z.B. Compiler) überprüft und gegebenenfalls als Fehler gewertet werden soll.
Wenn ein Dokumentfenster vom Benutzer verschoben oder in der Größe geändert wird, dann werden Größe und Position automatisch gespeichert, um sie beim nächsten Öffnen des Dokuments wiederherstellen zu können. (Diese Daten werden für die 20 zuletzt verschobenen oder in der Größe geänderten Dokumente in der Windows Registry abgelegt.)
Änderung im Generierungsskript statemachine2.xsl (in allen Varianten):
Das statische lokale Array chain wird nun explizit mit 0 initialisiert:
static StateFunc chain[CHAIN_TOTAL_LENGTH] = { 0 };
Gemäß C-Norm sollten statische Variablen eigentlich automatisch mit 0 initialisiert werden. Wir erhielten jedoch Hinweise von EasyCODE-Anwendern, dass dies bei einigen Compilern nicht der Fall sei.
Beim Generieren von Code aus einem SPX-Struktogramm werden nun die resultierenden Zeilennummern ins Struktogramm-Dokument übernommen. Dies ist unter anderem eine wichtige Voraussetzung für die Verwendung der Debug-Schnittstelle mit SPX-Struktogrammen. Bei der Generierung wird gefragt, ob das mit den Zeilennummern aktualisierte Struktogramm-Dokument sofort gespeichert werden soll.
Bislang war bislang die Reihenfolge wichtig, in der die Zustandsdiagramme eines Projekts mit den Standardskripts generiert werden:
Zuerst mussten diejenigen Zustandsdiagramme generiert werden, die in anderen Zustandsdiagrammen als Submachines eingebunden sind. Dies ist jetzt nicht mehr nötig, d.h. es muss nicht mehr auf die Generierungsreihenfolge geachtet werden.
Beim (automatischen) Einlesen der Signal-Batch-Datei wird nun überprüft, ob die Werte noch zu den Bezeichnern passen.
(Die Bezeichner-Wert-Zuordnung kann sich ändern, wenn Statecharts aus dem Projekt entfernt werden oder wenn ihre Reihenfolge im Projekt geändert wird.) Gegebenenfalls wird der Wert an den Bezeichner angepasst. Beim Schließen des SimulationController wird der geänderte Signal-Batch automatisch gespeichert.
Einige C/C++-Compiler akzeptieren Funktionen, die enum oder union als Rückgabetyp besitzen. Dem C/C++-Standard folgend hat EasyCODE in solchen Fällen versucht, anstelle einer Funktion eine enum- oder union-Deklaration zu konstruieren, was natürlich zu Problemen führte. Jetzt wurde der Parser erweitert, so dass EasyCODE auch Funktionen mit enum oder union als Rückgabetyp akzeptiert.
Man kann nun in Struktogrammen mit Strg+Pos1 bzw. Strg+Ende an den Anfang bzw.an das Ende der aktuellen Struktogrammebene scrollen.
Wenn in EasyCODE ein Projekt geöffnet ist, dann wird bei Betätigung von Strg+Tab vorübergehend das Sichten-Fenster angezeigt (solange die Strg-Taste gedrückt ist). Dies dürfte die Navigation durch die geöffneten Dokumente deutlich erleichtern.
Für SPS-Struktogramme wurde .exp als mögliche Dateierweiterung hinzugefügt. Das bedeutet unter anderem:
Jetzt genügt auch schon ein Doppelklick auf einen Dokumenttyp in der linken Liste, um ein entsprechendes Dokument (mit der Standarderweiterung für diesen Typ) zu erzeugen.
In der Titelleiste des EasyCODE-Hauptfensters werden nun auch die EasyCODE-Versionsnummer und der Name des aktuellen Projekts angezeigt.
Ab der Version 4 muss in Keil uVision der Port für die UVSOCK-Schnittstelle an anderer Stelle eingestellt werden als bislang in EasyCODE beschrieben: Unter Menü „Edit > Configuration > Other“. Zusätzlich muss dort die Checkbox „Enabled“ aktiviert werden. In EasyCODE wurde der Dialog „UVSOCK > Verbindung konfigurieren“ mit diesen Informationen aktualisiert.
Größere Erweiterungen und Änderungen betreffen vor allem die Kapitel über Zustandsdiagramme: Neu hinzugekommen sind die Kapitel 13.14 (Kreuzungsknoten) und 13.15 (Beispielprojekte). Mehrere Änderungen und neue Absätze finden Sie in den Kapiteln über Codegenerierung und Framework. In den übrigen Bereichen der Hilfe wurden zwar zahlreiche, aber eher kleinere Ergänzungen vorgenommen.
Das Verhalten eines DeepHistory war nicht ganz wie erwartet, wenn sein Vaterzustand gleichzeitig ein anderes Zustandsdiagramm als Subautomat inkludierte. Die Generierungsskripts und das Framework wurden nun entsprechend verbessert.
In inkludierten Zustandsautomaten wurden Clock Ticks in einigen Konstellationen nicht korrekt behandelt. Die Generierungsskripts und das Framework wurden nun entsprechend verbessert.
Es wurde ein Fehler beseitigt, der in einigen Fällen beim Schließen des Struktogramms zu einem Absturz führte.
Das Hinzufügen und Entfernen von Dateien hatte aufgrund einer Änderung im Projekt zwischenzeitlich in bestimmten Fällen nicht mehr funktioniert.
Beim Entfernen aus SourceSafe wurden Dateien nicht zwangsläufig aus SourceSafe entfernt, sondern nur als "entfernt" markiert. Beim Laden eines Projekts führt dies zu starken Verzögerungen, wenn zuviele dieser nur als "gelöscht" markierten, aber nicht permanent gelöschten Dateiversionen existierten, da EasyCODE auch diese fälschlicherweise bei jedem Vorgang berücksichtigt hat.
In der Framework-Datei EcBaseStatemachine.c/cpp wurde (in allen Varianten) in der Funktion
CEcBaseStatemachine::reinit () eine Zeile geändert:
Bislang:
while ( NULL == INIT_STATE(s) )
Jetzt:
while ( NULL == INIT_STATE(s) && s != m_stateFunc /*maybe changed by INIT_STATE()*/ )
Ohne diese Änderung kommt es zu einer Endlosschleife, wenn in einem Zustand, der Ziel einer Initialtransition ist, ein Statechart inkludiert ist.
Beim Verschieben von Zuständen wurden in einigen Fällen die umschlossenen Junctions und/oder die Start-/Endpunkte der mit diesen Junctions verbundenen Transitionen nicht entsprechend mit verschoben.
Wenn in einer Erstellungskonfiguration kein Pfad für den Platzhalter %FRAMEWORK_DIR% angegeben ist, dann soll das in den Zustandsdiagramm-Einstellungen angegebene Standard-Framework-Verzeichnis verwendet werden. Dies geschah jedoch in einigen Situationen nicht.
Bei SPS-Struktogrammen kam es in einigen Fällen zu ungewollten Einrückungen einzelner Codezeilen (insbesondere in Zeilen, denen ein Kommentar vorangeht).
Dieser Fehler ist nun behoben.
Die Komponente "EasyCODE Zustandsdiagramme" kann auch einzeln, also ohne "EasyCODE Struktogramme" erworben werden.
Saskia Kühner
Vertrieb
+49 (0)911 - 99840-61
E-Mail
EasyCODE Debug Plugin für MPLAB X. im Download-Bereich
EASYCODE GmbH, Löwenberger Str. 50, 90475 Nürnberg | Tel: +49 (0)911 / 99 840 60 | Fax: +49 (0)911 / 99 840 97 | info(at)easycode.de