Die folgende Darstellung zeigt die grobe Struktur des PEC-Framework als Paketdiagramm. Das Basispaket bildet die eigentliche PEC-Bibliothek (Portable Embedded Classes). Alle portablen Elemente (Klassen, Templates, Interfaces, Strukturen, VariationPoints, Varianten, Definitionen und Modifier) sind mit dem Präfix pec versehen. Dieser Präfix zeigt an, dass bei diesen Elementen keine plattformspezifischen Befehle, Bezeichner, Register etc. verwendet wurden. Sie können in allen Zielplattformen gleichermaßen angewendet werden.

Auf der Basis der PEC-Bibliotheken werden plattformspezifische Realisierungen aufgebaut. Die hier gezeigte Version des PEC-Framework gliedert sich in die Realisierungen für 8 Bit AVR Controller und 32 Bit ARM Controller. Das ARM Paket enthält die für alle ARM gültigen Spezifikationen. Die ARM Controller werden wiederum in konkrete ARM-Familien aufgeteilt. Hier finden sich vor allem familienspezifische Realisierungen der herstellerabhängigen IP (internal peripherals). Möglich wird diese Portabilität durch die Verwendung von VariationPoints. Dabei stellt ein PEC-Interface (Klasse, Template oder Struktur) lediglich die abstrakte Definition zum Beispiel eines Bausteins ohne konkrete Realisierung dar.

Die innere Struktur des PEC-Paketes gibt zum Beispiel einen Überblick welche Peripherie plattformübergreifend spezifiziert wurde. Alle Lösungen die auf die hier festgelegten Interfaces aufsetzen und somit gegen die PEC-API (Application Programming Interface) programmiert wurden sind hoch portabel. Die Portierung von einem AVR auf einen STM32 ist faktisch add hoc möglich. Lediglich die konkrete Hardware muss neu zugewiesen werden.

Über das Anbinden von plattformspezifischen Varianten werden zum Zeitpunkt der Codegenerierung durch das UML Werkzeug die für das Target benötigte Realisierung ausgewählt (vgl. Constraint an der Realisierungsbeziehung). Die plattformspezifischen Realisierungen sollen nicht in den Benutzermodellen verwendet werden. Damit die durch den Anwendungsentwickler nicht zu verwendende Elemente erkannt werden tragen Sie den Präfix sys.

Die folgende Skriptstruktur erlaubt es, dass SiSy die so beschriebenen Strukturen automatisiert in das Klassenmodell einfügen kann.

NEW class BASED_ON template.
BIND parameter TO class.
AGGREGATION class IN class.
ATTRIBUTE name TYPE type IN class.
OVERWRITE virtual operation IN class FROM base.
OPERATION name PARA C like parameter list TYPE return type IN class. 

Problembeschreibung: Ich brauche einen Trigger am Besten mit Timer16 der einen Zählerwert hochzählt und an ein den PC-Terminal überträgt.

Lösungsvorschlag:

NEW Trigger BASED_ON PecTimer.
BIND timer16stm32f0 TO Trigger.
OVERWRITE onTimerEvent IN Trigger FROM PecTimer.
ATTRIBUTE counter TYPE uint8_t IN Trigger.
 
NEW Terminal BASED_ON PecUart.
BIND baudrate19200 TO Terminal.
BIND uart1portA9_stm32f0 TO Terminal.
 
AGGREGATION Trigger IN Controller.
AGGREGATION Terminal IN Controller.

Erläuterung:

• NEW = neue Klasse anlegen
• BASED_ON = Verweis auf Bibliotheksbaustein dessen Eigenschaften übernommen werden, in der Regel ein Template
• BIND = Zuordnung eines Parameters
• ATTRIBUTE = ein neues Attribut in eine Klasse einfügen
• OPERATION = eine neue Operation in eine Klasse einfügen
• PARA = parameterliste einer neuen Operation
• TYPE = Rückgabetyp einer neuen Operation
• OVERWRITE = eine virtuelle Operation überschreiben
• FROM = Quellelement einer virtuellen Operation
• AGGREGATION = eine Klasse in einer Klasse aggregieren (der Codegenerator macht daraus ein Klassen-Attribut in C++)
• IN = Ziel für das Einfügen eines neuen Elementes
• TO = Ziel für eine neue Verbindung

Bibliotheksklassen, Templates, Parameter und virtuelle Operationen sind ausschließlich auf der Datenbasis des PEC-Framworks vorzuschlagen.
Basistypen müssen sich an den Typgerüsten für Mikrocontroller-Anwednungen orientieren z.B. uint8_t, uint16_t, …
Die Anwendungsklasse mit dem Namen Controller und der globalen Instanz ist in der Regel bereits angelegt und darf nicht mehr als neu anzulegen vorgeschlagen werden. Die für eine Problemlösung empfohlenen Bibliotheksbausteine sind Pec-Templates diese beginnen mit dem Präfix „Pec“ (großes P). Die Binding-Parameter für die Templates beginnen mit einem kleinen Buchstaben. Elemente mit dem Präfix „Sys“ sind für einen Lösungsvorschlag zu ignorieren.

maschinelesbare Datenbasis für die Analyse des PEC-Framework

Protokolle ausgewählter ChatGBT Sitzungen mit geeigneten Ergebnissen

• pec_AppManagement _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Utils _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Debug _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Strings _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_InOut _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Gpio _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Lcd _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Uart _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Spi _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Adc _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_I2C _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Timer _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Sound _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_Servo _{(nur über eine SiSy-Lizenz verfügbar)}
• pec_CAN _{(nur über eine SiSy-Lizenz verfügbar)}
• avr_Commons _{(nur über eine SiSy-Lizenz verfügbar)}