CO-Design von Hardware und Software
Änderungen an der Hardware abfangen
Fortsetzung des Artikels von Teil 1
Einblicke in die Hardware möglich
Ein wichtiger Aspekt für den Austausch der Hardware-Definition ist die Fähigkeit, periphere Register zu definieren und Zugriffsberechtigungen für Felder in diesen Registern bereitzustellen. Hierdurch wird gewährleistet, dass der Debugger per Lese-/Schreibzugriff modifizierbare Bits vorsichtig behandelt. Die Hardware bietet »Clear-on-read«-Bits, »0-to-toggle«-Bits sowie alle möglichen anderen transistorsensiblen Methoden, um Status-Schnittstellen handzuhaben.
Leider sind diese per Software nur schwer auszulesen und darzustellen. Nur eine gut definierte, maschinell generierte Definition der Hardware kann Benutzer beim Debugging von Registern oder einzelnen Bits in peripheren Blöcken vor Zeitverschwendung und unerwarteten Ergebnissen schützen. Durch diese ausgefeilten Einblicke in programmierbare Hardware lassen sich mehr als nur Statusregister und Fehlerbedingungen prüfen.
Wenn die Hardware beispielsweise registergesteuerte Switches unterstützt, um periphere Ein-/Ausgänge zu Bausteinpins flexibel zu routen, kann der Softwareentwickler die interne Verdrahtung des Bausteins durch den Debugger manipulieren. Das klingt vielleicht ein bisschen beängstigend, aber wenn die SVD-Informationen richtig generiert werden, müsste es möglich sein, die erlaubten Änderungen auf »sichere« Änderungen zu begrenzen, beispielsweise Multiplexkanalauswahl auf digitalen Signalen oder Umschaltung analoger Eingänge zwischen zwei physischen Pins.
Wenn die Hardware-Werkzeuge Debug-Informationen für den Softwareentwickler generieren, lässt sich hierdurch die für die Anwendungsentwicklung benötigte Zeit erheblich verkürzen. Ein weiterer Vorteil ist, dass sich Hardware-Designfehler frühzeitig auffinden lassen, da der Softwareentwickler ein unerwartetes Verhalten viel eher erkennt, wenn der Code nicht laufend überarbeitet wird.
Ganzheitlicher Ansatz führt zum Ziel
Das Konzept eines »ganzheitlichen Produkts« ist heute in weiten Kreisen bekannt und wird als ein Schlüsselfaktor für den Erfolg akzeptiert. Die programmierbaren Lösungen, die wir heute einsetzen, können viele Formen annehmen. Sie können vollständig benutzerdefinierte ASICs sein, die ARM-Kerne und mehrere IP-Blöcke in hoch spezialisierten Lösungen integrieren. Oder sie können allgemeinere Plattformen sein, die aus programmierbaren Silizium- und Designwerkzeugen wie zum Beispiel den FPGA-Lösungen von Altera und Xilinx oder den PSoC-Bausteinen von Cypress Semiconductor bestehen.
So unterschiedlich diese Umgebungen auch sind, sie behindern alle die Anwendungsentwicklung, weil sie Änderungen in der Hardware nicht effizient in die Softwaredomäne migrieren. Dieses Problem ist in einem nicht umfassenden Ansatz für Hardware-Designwerkzeugen und IDEs verwurzelt, die in diesen Projekten eingesetzt werden.
Es ist zwar sehr verlockend, Hardware-Tools und Entwicklern die ganze Schuld zu geben, aber die Realität ist, dass sich beide sowohl die Werkzeuge als auch die Entwickler zu sehr auf ihre jeweiligen Disziplinen konzentrieren. Die Realität beim Kunden sieht jedoch ganz anders aus. Produkte wie »PSoC Creator«, welche die Bausteinkonfiguration auf der programmierbaren Hardware unterstützen, sowie die Einbindung von IDEs von Drittanbietern wie die integrierte Entwicklungsumgebung »Keil µVision« von ARM kann diese Situation ändern. Entwickler können Anwendungen in der von ihnen gewählten IDE entwickeln, und das Tool bietet einen Einblick in die Hardware-Plattform sowie Kontrolle. Das ist damit sicherlich der richtige Weg zu einer effizienteren Produktentwicklung und einer kürzeren Time-to-Market.
Über den Autor:
Mark Saunders ist Senior Product Marketing Manager bei Cypress Semiconductor.
Jobangebote+ passend zum Thema
- Änderungen an der Hardware abfangen
- Einblicke in die Hardware möglich
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
