Guide to CMSIS-Packs in Arm-Keil-MDK
Teil 3: Workflow Management und Best Practices
CMSIS-Packs sind ein zentraler Bestandteil der Arm Keil MDK Toolchain. Die Erstellung eigener CMSIS-Packs erfordert jedoch ein Workflow Management. Wie lässt sich dies am ehesten umsetzen, wie sehen Best Practices aus, und wo liegen etwaige Stolpersteine?
CMSIS-Packs bieten eine strukturierte Möglichkeit, standardisierte Code-Bausteine und weitere Ressourcen in Entwicklungsprojekte einzubinden. Die Einsatzmöglichkeiten sind breit gefächert – von Low-Level-Silizium-Startcode über Board Support Packages bis hin zu hochentwickelten Protokollen und Services. Die Artikelreihe über CMSIS-Packs beleuchtet deren Grundlagen sowie die Erstellung eines eigenen CMSIS-Packs. Nach den einführenden Hintergrundinformationen in Teil 1 (Elektronik 1/2026) und den grundlegenden Schritten zur Erstellung eines CMSIS-Packs in Teil 2 (Elektronik 3/2026), widmet sich der dritte und abschließende Teil dem Workflow-Management.
Der Beitrag zeigt Anwendern, wie sie die Verwaltung und Weiterentwicklung eigener CMSIS-Packs optimieren und typische Herausforderungen meistern können. Dabei stellt er Best Practices vor, die Anwendern helfen, effizientere Prozesse zu etablieren und zugleich die Qualität ihrer Packs zu sichern. Der Beitrag bietet Anwendern praktische Hinweise, um CMSIS-Packs nicht nur zu erstellen, sondern als zentralen Bestandteil ihrer Entwicklungsprojekte nachhaltig und problemlos einzusetzen.
Was wird benötigt, um ein CMSIS-Pack zu erstellen?
Kurz gesagt: Die benötigten Tools für mehrere Plattformen sind im CMSIS-Toolbox-Repository zu finden. Sobald die verwendete Entwicklungsumgebung die entsprechenden Skripte ausführen kann und eine sorgfältig erstellte Pack-Beschreibungsdatei (.pdsc) vorhanden ist, kann das Tool CMSIS-Packs erstellen.
Die Umsetzung ist allerdings mit einigen Herausforderungen verbunden. Eine Schritt-für-Schritt-Anleitung ist im zweiten Teil der Artikelserie (»Grundlagen zur Erstellung eines eigenen CMSIS-Packs«) zu finden, auf dem dieser Leitfaden aufbaut.
Erstellung und Verwaltung von Dokumentation und Beispielen
CMSIS-Packs bestehen aus vielen Komponenten, doch zwei der nützlichsten weit über den Code hinaus sind Dokumentation und Beispiele. Beide gehen Hand in Hand: Beispiele zeigen die Funktionsweise des Systems in der Praxis, während die Dokumentation die grundlegenden Konzepte sowie Systemdesigns verständlich erläutert.
Allein durch die Bereitstellung isolierter Quellcodedateien wird der Nutzen eines CMSIS-Packs oft stark reduziert. Daher sollten Dokumentation und Beispiele früh in den Entwicklungsprozess integriert werden. CMSIS-XML-Tags wie file category= »doc« und »examples« ermöglichen eine Beschreibung der zugrundeliegenden fundamentalen Konzepte.
Ein strukturierter Workflow für die Erstellung eines CMSIS-Packs
Ein nützlicher Ansatz zur Entwicklung eines eigenen CMSIS-Packs besteht darin, den Prozess wie ein eigenständiges Mini-Projekt mit klar definierten Phasen zu behandeln. Selbst ein einfacher, schriftlicher Plan für die wesentlichen Aufgaben schafft Überblick und hält den Fokus auf die Endziele gerichtet.
Mögliche Schritte für den Planungsabschnitt sind:
- Wunschliste: Anwender sollten zunächst eine einfache Übersicht dessen erstellen, was ihr CMSIS-Pack umfassen soll. Neben ihren eigenen Anforderungen lassen sich auch Wünsche von Kollegen oder Anwendern berücksichtigen. Die Liste hilft dabei, potenzielle Features und funktionale Schwerpunkte für die Entwicklung zu identifizieren.
- Roadmap: Nicht alle Wünsche lassen sich gleichzeitig umsetzen. Daher empfiehlt es sich, die Wunschliste in Entwicklungsphasen zu unterteilen. Dies hilft, klare Prioritäten zu setzen und Änderungen am Plan nachverfolgbar zu gestalten. Die Roadmap ermöglicht auch eine iterative Entwicklung, bei der jede Phase ein funktionstüchtiges CMSIS-Pack hervorbringt, bevor die nächste beginnt.
- Versionskennzeichnung und schrittweise Entwicklung: CMSIS-Packs nutzen ein dreistelliges semantisches Versionsschema (z. B. 1.2.3). Dieses Schema vereinfacht die inkrementelle Weiterentwicklung. Statt eine übergreifende »Alles-auf-einmal«-Lösung anzustreben, lohnt sich die Aufteilung in kleinere Entwicklungsstufen. Jede Phase sollte ein gut funktionierendes Pack hervorbringen, auch wenn es noch nicht alle gewünschten Funktionen umfasst.
Entwicklung: Technische Umsetzung
Sobald die Planung steht, kann die eigentliche Entwicklung beginnen. Dabei ist zu beachten, dass klare Zielvorgaben die Umsetzung erleichtern und übermäßig komplexe Anforderungen verhindern, die den Prozess erschweren. Um Qualität sicherzustellen und langfristige Wartbarkeit zu gewährleisten, ist es empfehlenswert, auf systematische Ansätze wie testgetriebene Entwicklung (Test Driven Development, TDD) zurückzugreifen. Anwender sollten sich an Release-Zyklen halten, um wichtige Begleitdokumentationen, Beispiele und Vorlagen aktuell zu halten. Erfahrungsgemäß wird dies oft zugunsten funktionalen Codes vernachlässigt, was später zusätzliche Arbeit erzeugt.
Prüflisten zur Qualitätssicherung
Bei kleineren Projekten ist es oft verlockend, ein Pack »schnell fertigzustellen« und direkt einzusetzen. Doch solche Eile führt meist zu unausgereiften Lösungen, die später zeitaufwendig ausgebessert werden müssen. Eine Checkliste hilft, offensichtliche, aber wichtige Schritte vor der Veröffentlichung nicht zu übersehen, etwa:
- Aktualisierung von Versionskennzeichnungen
- Validierung der TDD-Tests
- Sicherstellen, dass neue Features in der Dokumentation erfasst sind
- Codebereinigung und
- Entfernung von Kommentaren wie //TODO
Changelogs: Dokumentation von Fortschritten
Ein gut geführtes Changelog ist hilfreich, um zu zeigen, was während der Entwicklung wirklich passiert ist. Es dient als Referenz, um den Fortschritt mit der Roadmap abzugleichen, und dokumentiert Verbesserungen, sodass Anwender nachverfolgen können, wie sich das Pack entwickelt hat. Anwender sollten daran denken, dass sie das Changelog nicht nur für sich führen, sondern dass es auch Transparenz fördert und ihre Arbeit für andere Entwickler greifbarer macht.
Arbeiten mit temporären Packs für Beispielprojekte
Ein häufiger Stolperstein ist die Verwendung eines CMSIS-Packs in einem Beispielprojekt, das selbst Teil desselben Packs ist. Dieser scheinbare »Henne-und-Ei«-Effekt lässt sich mit temporären Packs umgehen.
Dazu erstellt und validiert man eine .pdsc-Datei. Zuerst öffnet man den »Pack Installer« in Keil µVision und wählt »Manage Local Repositories…«. Man wählt die .pdsc-Datei aus – µVision erkennt das Pack und aktualisiert seine Ansicht.
Nun ist zu sehen, dass das Pack wie jedes andere Pack in der Auswahl der Runtime-Umgebung erscheint - und zwar bevor das endgültige pack_gen ausgeführt wird. Dies erspart das Herumspielen mit der Pack-Generierung, bevor man wirklich fertig ist, und bietet eine Möglichkeit, die Verwendung des Packs im »Dummy-Modus« zu testen. Durch das Erstellen eines Beispielprojektes, das das Pack wie vorgesehen verwendet, können Benutzerprobleme ausgebügelt werden, bei denen das Design nicht ganz perfekt ist.
Zu beachten ist jedoch, dass ständige Änderungen am Code durch erneutes Laden der Softwarepakete bestätigt werden müssen.
Sobald das CMSIS-Pack finalisiert ist, lässt es sich wie jedes andere externe Pack nutzen und installieren. Dabei sollte nicht vergessen werden, die lokale temporäre Version zu entfernen, um Verwirrungen zu vermeiden.
Nebeneffekt: Verbesserte Codequalität
Ein erfreulicher Nebeneffekt der Erstellung eines CMSIS-Packs ist, dass die Codequalität oft beträchtlich steigt. Dies geschieht, weil Entwickler sich bemühen, ihren Code sauber und verständlich zu halten, wenn er von anderen verwendet wird und ein strukturierter Veröffentlichungsprozess – einschließlich Reviews, Dokumentation und Checks – Teil der Entwicklung wird. Darüber hinaus verbessert TDD die Wartbarkeit und stellt sicher, dass Änderungen bestehende Funktionen nicht beeinträchtigen. Mit einer Roadmap wird zudem vermieden, dass ungeplante Codefragmente in das Projekt aufgenommen werden, was die Robustheit des Produkts steigert – und gut in die Arbeit im V-Modell oder im agilen Arbeitsablauf passt.
Zusammenfassung
Die Erstellung eigener CMSIS-Packs für wiederverwendbaren Code bringt zahlreiche Vorteile mit sich. Obwohl dies mit einem gewissen Mehraufwand verbunden ist, zahlt sich dieser durch die verbesserte Qualität und Wartbarkeit der Software aus. Egal ob für große Organisationen, die von konsistenten Prozessen profitieren, oder kleine Teams, die durch strukturierte Ansätze bessere Ergebnisse erzielen – CMSIS-Packs sind ein wertvolles Werkzeug im modernen Softwareentwicklungsprozess.
Jobangebote+ passend zum Thema
Der Autor
Colin Funnell, Absolvent der Coventry University, begann seine Karriere in der Telekommunikationsbranche und war an der Entwicklung von Hochgeschwindigkeitsprodukten mit elektrischen, optischen und photonischen Technologien beteiligt. Für seine Leistungen erhielt er den Preis »Outstanding Contribution to Optical Networks«. Seit 15 Jahren arbeitet er bei Hitex, wo er Schaltungen entwickelt und Software schreibt, mit einem Fokus auf Arm-Systeme und deren praktische Anwendungen. Hitex ist offizieller Distributor von Arm in Deutschland und den Niederlanden und seit über 35 Jahren Partner für Arm/Keil-Technologie, Beratung, Schulungen und Arm-Entwicklungswerkzeuge sowie bewährte, einsatzbereite Software-Komponenten.
Übersetzt aus dem Englischen von Anna Brotzer, Senior Marketing Manager bei Hitex.
Hitex auf der embedded world 2026: Halle 4, Stand 205
Lesen Sie mehr zum Thema
