Ein Board Support Package, kurz BSP, ist eine Softwareschicht für ein bestimmtes Computerboard oder eingebettetes System. Es initialisiert die Hardware und stellt Schnittstellen bereit, über die Betriebssystem, Middleware oder Anwendungscode auf Prozessor, Speicher und Peripherie zugreifen können.
Inhalt
Was bedeutet Board Support Package?
Ein Board Support Package bündelt Board-spezifischen Code. Dieser Code beschreibt, wie ein bestimmtes Hardwaredesign gestartet, konfiguriert und angesprochen wird. Dazu gehören Treiber, Initialisierungsroutinen und häufig auch Komponenten für Speicherverwaltung, Energieverwaltung und Boot-Ablauf.
Der Begriff wird vor allem bei Embedded-Systemen verwendet. Dort ist die Software eng mit Prozessor, Speicherbausteinen, Schnittstellen und Peripheriegeräten des jeweiligen Boards verbunden. Ein BSP trennt diese Hardwareabhängigkeiten von höheren Softwareschichten.
Wie funktioniert ein Board Support Package?
Beim Einschalten eines Boards führt zunächst ein Bootloader oder ein vergleichbarer Startcode grundlegende Schritte aus. Er bereitet den Start weiterer Software vor und kann ein Betriebssystem oder ein Software-Image laden. Danach sorgen Initialisierungsroutinen dafür, dass Speicherbereiche, Taktquellen und Peripherie in einen definierten Zustand gebracht werden.
Gerätetreiber stellen anschließend die Verbindung zwischen Software und Hardwarefunktionen her. Sie erlauben den Zugriff auf Komponenten wie GPIO, UART, Timer, ADC, Speicher oder Kommunikationsschnittstellen. In architektonisch gefassten BSPs erfolgt dieser Zugriff über festgelegte APIs. Dadurch wird geregelt, welche Funktionen aufgerufen werden, welche Parameter zulässig sind und welche Verhaltensweisen die obere Softwareschicht erwarten darf.
Ein BSP kann auf einer Hardware Abstraction Layer aufsetzen. Die HAL stellt meist herstellerspezifische Zugriffe auf Mikrocontroller-Peripherie bereit. Das BSP legt darüber fest, wie diese Zugriffe im Projekt verwendet und begrenzt werden. Dadurch bleibt herstellerspezifischer Code in einer abgegrenzten Schicht.
Wo wird ein Board Support Package verwendet?
Board Support Packages werden in eingebetteten Systemen eingesetzt, bei denen Software auf einer konkreten Hardwareplattform laufen soll. Dazu zählen Systeme mit Betriebssystem, Echtzeitbetriebssystem oder anderer Systemsoftware.
Typische Einsatzkontexte sind:
- Initialisierung eines bestimmten Boards beim Systemstart
- Anbindung von Prozessor, Speicher und Peripherie an ein Betriebssystem
- Bereitstellung von Treibern für board-spezifische Hardware
- Kapselung von Mikrocontroller- oder Prozessorabhängigkeiten
- Migration einer Anwendung auf ein anderes Board mit ähnlicher Funktionsstruktur
- Aufbau wiederverwendbarer Schnittstellen für mehrere Hardwarevarianten
Für Linux-basierte Embedded-Systeme kann ein BSP Teil einer Build- und Integrationsumgebung sein. Das Yocto Project stellt dafür Vorlagen, Werkzeuge und Methoden bereit, um angepasste Linux-Systeme für Embedded-Produkte zu erstellen.
Hersteller wie Toradex, Seco oder PHYTEC stellen für Mikroprozessor-basierte SoMs Linux-, Android- und Yocto-basierte BSPs zur Verfügung.
Eigenschaften
Ein BSP ist an ein konkretes Board gebunden. Es enthält Wissen über die vorhandene Hardware und deren Startbedingungen. Dazu zählen Prozessor, Speicher, Peripheriegeräte, Schnittstellen und board-spezifische Verdrahtung.
Zu den Bestandteilen eines BSP gehören häufig:
- Gerätetreiber für Hardwarekomponenten
- Bootloader oder Startcode
- Initialisierungscode für Speicher und Peripherie
- Code für Speicherverwaltung
- Code für Energieverwaltung
- Kommunikationsprotokolle oder Bibliotheken, soweit sie für die Hardwareanbindung benötigt werden
- APIs für den Zugriff aus höheren Softwareschichten
Die Entwicklung eines BSP setzt Kenntnisse über Hardware und Betriebssystem voraus. Entwickler müssen wissen, wie die Zielplattform aufgebaut ist und welche Anforderungen die darüberliegende Software an Initialisierung, Treiber und Laufzeitverhalten stellt. Nach der Implementierung wird das BSP auf der Zielhardware getestet. Dabei können unterschiedliche Hardwarekonfigurationen und Betriebssystemversionen berücksichtigt werden.
Eine typische Entwicklungsumgebung für ein BSP enthält einen Cross-Compiler, einen Debugger, Build-Werkzeuge und häufig eine integrierte Entwicklungsumgebung. Der Cross-Compiler erzeugt Code für die Zielplattform. Der Debugger unterstützt die Fehlersuche im BSP-Code auf oder für die Zielhardware.
Abgrenzung zu verwandten Begriffen
Ein BSP ist nicht identisch mit einem einzelnen Gerätetreiber. Ein Treiber stellt den Zugriff auf eine bestimmte Hardwarekomponente bereit. Ein BSP umfasst mehrere board-bezogene Bestandteile und beschreibt den Start sowie die Einbindung der Hardwareplattform in die Softwarearchitektur.
Ein BSP ist auch nicht dasselbe wie eine HAL. Eine Hardware Abstraction Layer stellt meist grundlegende, oft herstellerspezifische Zugriffe auf Mikrocontroller- oder Prozessorperipherie bereit. Ein BSP kann diese HAL nutzen, schränkt den Zugriff aber projektbezogen ein und stellt APIs bereit, die von Anwendung, Middleware oder Betriebssystem verwendet werden.
Ein Bootloader ist ebenfalls nur ein Teilbereich. Er startet beim Einschalten und lädt weitere Softwarekomponenten. Das BSP kann einen Bootloader enthalten oder mit ihm zusammenarbeiten, umfasst aber zusätzlich Treiber, Initialisierung und board-spezifische Schnittstellen.
Ein Betriebssystem ist die Laufzeitumgebung für Prozesse, Threads, Speicherverwaltung oder Gerätedienste. Das BSP stellt die board-spezifische Grundlage bereit, damit das Betriebssystem die Hardware des konkreten Boards verwenden kann.
Grenzen und typische Missverständnisse
Ein BSP macht Software nicht automatisch unabhängig von jeder Hardware. Es begrenzt Hardwareabhängigkeiten auf eine bestimmte Schicht. Wenn Anwendungen direkt auf Register, HAL-Funktionen oder board-spezifische Details zugreifen, wird diese Trennung durchbrochen.
Ein weiteres Missverständnis ist die Gleichsetzung eines BSP mit Beispielcode des Herstellers. Beispielcode kann als Ausgangspunkt dienen, ersetzt aber keine definierte Schnittstelle, keine klare Zuständigkeit und keine Validierung auf der Zielhardware.
Ein BSP ist außerdem nicht vollständig generisch. Es enthält bewusst board-spezifische Informationen. Bei einem Wechsel des Mikrocontrollers oder Boards können Teile des BSP neu geschrieben werden. Wenn die APIs stabil bleiben, kann Anwendungscode unverändert bleiben, sofern die neue Hardware dieselben benötigten Funktionen bereitstellt.
Die Qualität eines BSP hängt von Tests auf der Zielplattform ab. Ohne Validierung lassen sich Initialisierungsfehler, abweichendes Peripherieverhalten oder Probleme durch andere Betriebssystemversionen nicht belastbar ausschließen.
