Immer komplexere Mikrocontroller haben die Kosten für Softwareentwicklung sowie die Entwicklungszeiten explodieren lassen. Dabei verbringen Entwicklungsteam viel Zeit mit der Entwicklung und/oder Integration von Komponenten, die das Endprodukt in keinster Weise differenzieren können, z.B. Peripherie-Treiber, Kommunikations-Stacks, Middleware-Bibliotheken, RTOS oder Plattform-Sicherheit.
In einem ähnlichen Ansatz wie im Automotive-Bereich mit AUTOSAR hat Renesas daher eine Software-Plattform entwickelt, bei welcher die MCU-Kunden die Chips über APIs programmieren und sich somit auf die eigentliche - gegenüber dem Wettbewerb differenzierende - Anwendung konzentrieren können (Bild 4).
Das "Synergy Software Package" besteht aus von Renesas getesteter und qualifizierter Software, das über seine APIs Kompatibilität über alle Synergy-MCUs bereitstellt. Es beinhaltet u.a. Express Logic's X-Ware, die ihrerseits das Echtzeitbetriebssystem ThreadX, NetX-Middleware, NetX DUO IPV4 und IPV4/IPv6-TCP/IP-Stacks, den USB-Protokollstack USBX für Host/Device/OTG, das MS-DOS-kompatible Dateisystem FileX und die Grafik-Runtime-Bibliothek GUIX enthält. Diese Komponenten sind in ein Applikations-Framework eingebunden, das den IEC/ISO/IEEE-12207-Software-Lebenszyklus-Prozess-Standards genügt.
Die wohl entscheidene Aussage ist, dass das Package in Gänze von Renesas getestet, gewartet, unterstützt und weiterentwickelt wird. Renesas garantiert die Funktion gemäß der veröffentlichen Spezifikationen. Dafür gibt es erstmalig überhaupt in der Branche Software-Datenblätter, welche als Basis der Garantie konkrete Zahlen wie Benchmark-Ergebnisse, Codeumfänge, Zeiten für Kontextwechsel, Latenzzeiten und Fehlertolerenzen beinhalten. Auch wenn in der vorliegenden Alpha-Version 0.8. noch viele "Tbd" stehen, ist das Konzept in dem derzeit 58seitigen Dokument bereits erkennbar. Erfreulich ist, dass für Benchmark-Messungen der Dhrystone endlich durch CoreMark von EEMBC ersetzt wurde.
Die Abdeckung aller von der Hardware bereitsgestellten Funktionen durch die HAL-Treiber bzw. das SW-Framework beträgt derzeit laut Renesas 85-90 %. Mit anderen Worten: Spezialfunktionen z.B. bestimmte Registerkonfigurationen bei A/D-Wandlern oder Timer-Modi müssen derzeit noch handisch programmiert werden, allerdings wird auch daran noch gearbeitet, das Ziel ist, tatsächlich 100 % aller Hardware-Funktionalität auch mit dem SW-API abdecken zu können.
Bild 5 zeigt eine praktische Anwendung des Frameworks aus dem Bereich Audio. Um Audiodatein abzuspielen und dies über "Start", "Stop", "Pause", "Lautstärkeregelung" zu steuern, werden auf Chipebene Timer, USB, D/A-Wandler, PWM und SRC benötigt. Statt diese nun jede Peripherie einzeln programmieren zu müssen, kann der Entwickler einfach die APIs "Daten holen", "Dekodieren" und "Konvertieren" aufrufen, die ihrerseits über das SW-Framework die genannten IP-Blöcke auf dem Chip steuern.
Neben dem Basis-Software-Framework zeigt Bild 4 noch zwei Arten von Add-Ons. Zum einen gibt es die QSA genannten Add-Ons, die von Renesas selbst verkauft und gewartet werden. Falls eine hinreichende Zahl von Kunden Interesse zeigt, können diese zu einem späteren Zeitpunkt über APIs in das Software-Package-Framework integriert werden.
Desweiteren können Kunden auch von Drittanbietern die VSA genannten Add-Ons einbinden, die z.B. Kommunikations-Stacks für spezifische Protokolle, Steuerungs-Algorithmen oder Sicherheits-Services beinhalten könnten. Diese müssen vor der Freigabe von Renesas auf die Erfüllung der Anforderungen für SSP-Kompatibilität getestet werden, wie es z.B. Apple in einem App-Store für iOS umsetzt. Diese Add-Ons werden von den Drittanbietern gewartet und weiterentwickelt. Renesas nennt seinen App-Store "Gallery", wie bei einer Kunstausstellung können Kunden im Internet Angebote von Drittanbietern analysieren und kostenlose Testversionen herunterladen.
Am SW-Framework vorbeiprogrammieren
Ein Nachteil von AUTOSAR besteht darin, dass die über der darunterliegenden Hardware befindlichen Software-Schichten bis zu 50 % der theoretischen Rechenleistung aus Sicht der Applikation auffressen. Der Kunde muss daher entweder mehr Geld für mehr Rechenleistung (=stärkere MCUs) ausgeben, oder mit den sogenannten "Complex Device Drivern" an dem Framework vorbeiprogrammieren und direkt auf die Hardware zugreifen. Dies wird von Automobilherstellern und Tier-1s sehr gerne genutzt - einerseits spart mal Geld und andererseits kann man "AUTOSAR-Konformität" seiner Software dokumentieren.
In abgeschwächter Form trifft diese Herausforderung auch für Synergy zu. Natürlich ist das SW-Framework viel besser optimiert als AUTOSAR, da ja Hardware und Software aus einer Hand kommt. Nichtsdestotrotz gibt es zeitkritische Routinen wie z.B. für die Motoransteuerung, die über APIs nicht realisiert werden können.
Wie Bild 6 zeigt, kann man bei Synergy anwendungsabhängig mehr oder weniger an den APIs vorbeiprogrammieren. Von dem direkten Zugriff auf die Hardware bis zum Zugriff auf die Low-Level-Hardware-Treiber oder bestimmte Elemente des Applikations-Frameworks ohne Nutzung der API-Aufrufe ist alles möglich. Der Kunde kann sogar einen eigenen Treiber entwickeln und einbinden.Wir nennen es so: Der Entwickler kann bei Synergy soviel Low-Level-Entwicklungsarbeit einsparen wie möglich und soviel selbst programmieren wie nötig. Diese Flexibilität ist AUTOSAR deutlich überlegen, dort kann man ja nur entweder ganz oben (API) oder ganz unten (Complex Device Driver) ansetzen. Hier hat Renesas konzeptionell (und hoffentlich auch praktisch) ganze Arbeit geleistet.