Anforderungsszenarien für ARM-Entwicklungstools mit Lösungen

8. September 2008, 10:21 Uhr | Andreas Willert
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 6

Variante 2: Viele Tasks, hoher Qualitätsanspruch – C reicht gerade noch aus, aber ein RTOS muss sein

Die Bestandteile der Lösung im Einzelnen:

  • Keil RV ARM Compiler mit Speicher-Einschränkungen
  • PC-Lint
  • Doxygen (nicht im Lieferumfang enthalten – Nutzung als GNU General Public License)
  • U-Link
  • Evaluation-Board
  • ARM-Schulung (Drei Tage)
  • Gesamtkosten: 4000 EUR

Ergänzend zu dieser Umgebung ist der Einsatz eines Tools zum Konfigurationsmanagement empfehlenswert.

Diese Variante basiert auf folgenden Anforderungen:

  • Hardware Architektur: Die Produktionsstückzahl der Applikation liegt bei ca. 10000 Stück pro Jahr bei einem Produktpreis von ca. 400 €. Aus Kosten- und EMV-Gründen ist die Architektur als Single Chip (kein externer Speicher) geplant. Aufgrund der komplexen Bedienung und Mehrsprachigkeit des Systems und einer daraus resultierenden Speicheranforderung für die Texte steht noch nicht fest, ob es bei diesem Konzept bleiben kann oder doch externer Speicher benötigt wird.
  • Echtzeitanforderungen: Die Echtzeitanforderungen sind lediglich in zwei Nebenläufigkeiten hoch, es gibt jedoch weitere Nebenläufigkeiten wie z.B. ein komplexes GUI und mehrere Kommunikationskanäle, die als Bus realisiert werden müssen (darunter CAN und USB).
  • Lebensdauer des Produktes: Der Hersteller rechnet mit sieben Jahren Produktlebensdauer. Erfahrungsgemäß steigen die Anforderungen in dieser Zeit, und es wird Weiterentwicklungen geben. Wartbarkeit und Erweiterbarkeit müssen über den ganzen Lebenszyklus gesichert sein. In der Vergangenheit hat sich gezeigt, dass auch nach der Produkteinführung die Entwicklung kontinuierlich weiter geht und neue Anforderungen umzusetzen sind, Eine Tool-Lösung muss dies in besonderem Maße gewährleisten.
  • Time To Market: Bis zur geplanten Markteinführung sind es noch elf Monate. Es stehen zwei Software-Entwickler zur Verfügung.
  • Qualität: Ausfälle des Systems sind nicht dramatisch und können nachgebessert werden. Trotzdem sind sie zu vermeiden, da der Ruf des Unternehmens leiden könnte.
  • Erfahrung: In der Anwendung der Hochsprache ANSI-C auf verschiedenen Hardwareplattformen ist Erfahrung vorhanden, jedoch nicht mit der ARM-Architektur. Es gibt keine Erfahrungen mit dem Einsatz eines RTOS oder anderen Werkzeugen zum Architekturdesign. Als Werkzeug für das Konfigurationsmanagement ist Microsofts »Visual SourceSafe« im Einsatz.
  • Budget: Mit der bisherigen Vorgehensweise entsprachen die Komplexität und Qualität nicht dem gewünschten Ziel. Es steht ein Budget für die Anschaffung der üblichen Entwicklungstools (Compiler, Debugger, Evaluation-Board) zur Verfügung. Darüber hinaus ist das Management bereit, in notwendige Software-Engineering-Maßnahmen zu investieren, wenn sie im Rahmen liegen und ihre Einführung nicht zu viel wertvolle Entwicklungszeit kostet.

Und so sieht der Vorschlag einer Entwicklungsumgebung aus, welche sich an den obigen Anforderungen orientiert:Die Umgebung ist für die Entwicklung von Applikationen mittlerer Komplexität gedacht. Durch die Integration eines RTOS, das Unterstützung beim Design der Laufzeitarchitektur bereitstellt, werden Wiederverwendung und Wartbarkeit der Software verbessert. Außerdem vereinfacht das RTOS die Schnittstellen zu einem gut entkoppelten »Hardware Abstraction Layer« über asynchrone Kommunikations-Mechanismen.

In diesem Fall fiel die Wahl auf die »RealView Real-Time Library« von Keil bzw. ARM. Sie beinhaltet neben einem RTOS auch ein CAN- und USB-Device-Interface. Diese Umgebung stellt einen Mittelweg zwischen der reinen Programmierung auf C-Ebene und der Modellierung auf UML-Ebene dar. Während weiterhin wie gewohnt in C programmiert wird, liefert das RTOS wertvolle Mechanismen für das Architekturdesign. Die Einarbeitungszeit in ein RTOS liegt bei weinigen Tagen, welche sich oft bereits durch die Erstellung eines Architekturdesigns im maßgeschneiderten RTOS-Start-up-Workshop wieder reinholen lassen. Auf Grund der sehr kurzen Entwicklungszeit ist auch eine Schulung für die Nutzung der CAN- und USB-Treiber eingeplant. Gleichzeitig wurde in Erwägung gezogen, die Realisierung von CAN und USB als Auftragesentwicklung extern zu vergeben, wenn der Zeitpunkt für die Produkteinführung gefährdet sein sollte. Für das effiziente Design des GUI kommt der »Embedded-Display Builder« als Designhilfe zum Einsatz.

passend zum Thema


  1. Anforderungsszenarien für ARM-Entwicklungstools mit Lösungen
  2. Andreas Willert
  3. Diese Tools sind immer ratsam
  4. Variante 4: Viel IP im Spiel, komplexe Anforderungen, Dokumentation existenziell – das ganz große Paket
  5. Anforderungsszenarien für ARM-Entwicklungstools mit Lösungen
  6. Variante 3: Große Komplexität, viele Änderungen – Hier kommt die UML ins Spiel
  7. Variante 2: Viele Tasks, hoher Qualitätsanspruch – C reicht gerade noch aus, aber ein RTOS muss sein

Jetzt kostenfreie Newsletter bestellen!