Software-Entwicklung Schneller für XMC4000 mit DAVE 3 entwickeln

Wenn man bei der Software-Entwicklung auf bereits existierende und getestete Software-Komponenten zurückgreift, kann man sich einiges an Entwicklungszeit sparen. Allerdings birgt das einige Tücken, wenn es sich bei den Komponenten um Hardware-nahe Software für Mikrocontroller handelt.

Stellen Sie sich vor, Sie sind Software-Entwickler für Embedded-Mikrocontroller und Ihr Chef legt Ihnen ein Evaluation-Board mit einem interessanten neuen Mikrocontroller auf den Tisch mit der Bitte, damit so schnell wie möglich einen BLDC-Motor zum Laufen zu bringen. Sie schauen sich das Board an, sehen schnell, um welchen Typ und Hersteller es sich handelt und Sie wissen, dass jeder Mikrocontroller-Hersteller, der etwas auf sich hält, Unterstützung für Motorsteuerung anbietet.

Schnell haben sie Zugriff auf eine Projektsammlung mit fertigen Treibern für die Peripherie. Glücklicherweise wird der von Ihnen benutzte Motor unterstützt und nach 1 bis 2 Tagen können Sie Ihrem Chef Vollzug melden. Im Überschwang der Freude über das gute und schnelle Ergebnis soll nun die Steuerung um eine weitere Achse erweitert werden und die Regeldaten sollen über eine SPI-Schnittstelle auf einem LC-Display dargestellt werden.

Mit dem ersten Erfolgserlebnis im Rücken durchstöbern Sie Projektsammlungen, Bibliotheken und Referenzbeispiele aufs Neue und werden höchstwahrscheinlich fündig: Für jede der einzelnen Problemstellungen gibt es Referenzprojekte oder Software-Module, mit denen Sie eine jeweils individuelle Lösung entwickeln können; allein, das war nicht das, was Ihr Chef möchte. Er wollte, dass alles zusammen gleichzeitig auf einem Chip funktioniert: Die unabhängige Regelung zweier Motoren, plus Ein-/Ausgaben plus ein bisschen Kommunikation.

Um dies zu erreichen, muss man sicherstellen, dass sich die verwendeten Software-Module und die darunterliegende Hardware nicht in die Quere kommen, und dies kann aufwendig werden. Man muss die verfügbaren Hardware-Ressourcen inklusive der Pin-Zuordnung richtig aufteilen; dann muss man in den benutzten Software-Modulen den Initialisierungscode und die Registerzugriffe entsprechend der Hardware-Ressourcenaufteilung anpassen und wenn das dann alles erledigt wurde und Ihr Chef vorbeikommt und noch eine Zusatzfunktion fordert, kann es sein, dass man mit der Ressourcenfrage wieder von vorne beginnen muss.

Die Lösung: „Constraint Logic Programming“

Die beschriebene Situation soll das Dilemma zeigen, in der man sich als Embedded-Software-Entwickler befindet, wenn man bei der Entwicklung neuer Hardware-orientierter Software-Projekte auf vordefinierte Komponenten zurückgreift. Diese Methodik wird üblicherweise „Component based Programming“ oder „Component based SW Engineering“ genannt und basiert darauf, dass eine Problemstellung in weitgehend unabhängige Teile zerlegt wird, die dann mit vordefinierten und getesteten SW-Komponenten gelöst werden kann. Dieses Konzept steht auch eng in Zusammenhang mit der objektorientierten Programmierung.

Die Kombination dieser Software-Komponenten sollte laut Theorie konfliktfrei möglich sein. Dies ist auch weitgehend der Fall, wenn die Software-Komponenten keine Hardware-Ressourcen exklusiv beanspruchen. Dies ist jedoch bei der Programmierung von Mikrocontrollern genau nicht der Fall; ein PWM-Kanal ist üblicherweise fest einem Motor zugeordnet und kann nicht gleichzeitig den zweiten Motor ansteuern.

Will man die Vorteile von „Component based Programming“ wie einfache, schnelle, sicherere und flexible Software-Entwicklung auf die Hardware-orientierte Programmierung von Mikrocontrollern konsequent anwenden, muss man sich der Frage nach der Hardware-Ressourcenaufteilung aufgrund sich ändernder Randbedingungen stellen. Viele aktuelle Ansätze auf Basis von normalen Bibliotheken oder Beispielprogrammen tun dies nicht. Aber auch die AUTOSAR-Methode, auch eine komponentenbasierte Entwicklungsmethode aus der Automobiltechnik, hat diese Problematik mehr oder weniger elegant ausgelagert.

Dort wurde der komponentenbasierte Ansatz bewusst von der Mikrocontroller-Hardware getrennt. Die Schnittstelle zur Hardware wird über die MCAL-Programmierschnittstellen (Mikrocontroller Abstraction Layer) definiert und muss in der Konfigurationsphase manuell den jeweils verfügbaren Hardware-Ressourcen zugeordnet werden.

FPGA-Design-Tools dagegen haben sich der Herausforderung der Ressourcenzuordnung nach sich ändernden Randbedingungen bereits früh gestellt. Ein einfaches FPGA-Design für eine blinkende LED könnte im Schematic-Editor wie in Bild 1 aussehen: eine Takterzeugung, ein Zähler und ein Multiplexer, der über einen externen Taster gesteuert wird und an dessen (bestimmten) Ausgang LEDs angeschlossen sind.

Bei der Erzeugung des VHDL-Code und des FPGA-Bitstreams prüft das Tool die Hardware-Anforderungen und bildet diese auf die verfügbaren Ressourcen des gewählten FPGA-Chips ab, unter Berücksichtigung aller Randbedingungen wie Signalverbindung, elektrische Eigenschaften und Pin-Zuordnung.

Eine Erweiterung des FPGA-Designs oder eine Übertragung auf ein anderes FPGA ist jederzeit möglich, solange es eine Auflösung zwischen geforderten und verfügbaren Ressourcen gibt. Das dahinterliegende Software-Konzept, um eine solche Auflösung zu finden, wird in der Literatur als “Constraint Logic Programming“ bezeichnet.

Ohne Dilemma mit DAVE 3

Die neue Entwicklungsplattform DAVE 3 hat sich von den FPGA-Tools inspirieren lassen. Mit DAVE 3 kann der Programmierer je nach Anforderung applikationsorientierte Software-Komponenten in sein Projekt einfügen, konfigurieren und verbinden. Ein Ressourcen-Auflöser findet automatisch eine funktionierende Ressourcenzuordnung, unter Berücksichtigung aller Randbedingungen wie Signalverbindung zwischen der Peripherie oder der Pin-Zuordnung.

Entsprechend der Ressourcenzuordnung erfolgt dann die automatische Code-Generierung, so dass der Programmierer nur noch die definierten Hardware-ressourcenunabhängigen APIs in seiner Software einsetzen muss, um die gewünschte Funktionalität zu erreichen. Nun kann Ihr Chef mit neuen Anforderungen vorbeikommen, so oft er will, Sie instanziieren einfach neue Komponenten, genannt DAVE-Apps, um die zusätzlichen Anforderungen zu erfüllen und um das leidige Ressourcen-Management und entsprechende Code-Generierung kümmert sich DAVE 3.