Jedes Board wird von den Herstellern mit einem Basis-BSP (Board Support Package) ausgeliefert. In den meisten Fällen müssen jedoch verschiedene Stufen der Anpassung den strengen Anwendungsanforderungen in realen Szenarien entsprechen. Damit wird implizit die Entwicklung eines eigenen BSP gefordert.
Dieser Artikel behandelt die wichtigsten Aspekte des BSP-Entwicklungsprozesses bei der Erstellung von kundenspezifischen BSPs für eingebettete Systeme.
Wichtigste BSP-Entwicklungsschritte
Der Entwicklungsprozess eines BSP beginnt mit der Hardware und dem Betriebssystem, das auf der jeweiligen Embedded-Plattform eingesetzt werden soll. Im Allgemeinen hängt die Wahl der Hardwareplattform von den Anforderungen der Anwendung und dem Zielbetriebssystem ab, das darauf laufen soll.
Es gibt zwei Hauptkategorien des Betriebssystem-Ökosystems für eingebettete Anwendungen: UNIX-ähnliche Betriebssysteme und Echtzeit-Betriebssysteme. Der BSP-Entwicklungsprozess hängt stark vom Zielbetriebssystem ab. Es gibt auch einige Hauptschritte im Entwicklungsprozess, die für beide Arten von Betriebssystemen gleich sind:
Wahl des Betriebssystems Open-Source vs. Proprietär
Die Wahl des Betriebssystems hängt von den spezifischen Anforderungen der jeweiligen Anwendung ab. Diese Wahl wird durch so unterschiedliche Erwägungen wie sicherheitsrelevante oder nicht sicherheitsrelevante Anwendungen, erforderliche Zertifizierungen für das System, Echtzeitanforderungen und Anwendungssoftwarestapel, die unter dem Betriebssystem laufen müssen usw. begründet.
Bootloader- und Bootschema-Entwicklung
Unabhängig vom gewählten Betriebssystem führt der Bootloader die erste Initialisierung des Systems durch. Im Allgemeinen wird ein Bootloader, je nach gewähltem Betriebssystem, von Grund auf oder aus einer Open-Source-Implementierung heraus angepasst. Neben der Entwicklung und Konfiguration der einzelnen Bootloader für jede Bootstufe ist es notwendig, das Bootschema/die Bootstrategie so zu implementieren, dass das System gemäß den strengen Anwendungsanforderungen hochgefahren werden kann und mit anderen SoCs oder Cores auf demselben Board/SoC synchronisiert ist.
Hardware-Abstraktion
Je nach gewähltem Betriebssystem gibt es verschiedene Techniken zur Abstraktion/Beschreibung der Hardware/SoC, auf der das Betriebssystem läuft, sodass der Kernel des Betriebssystems mit einer abstrakten Beschreibung der Hardwarekomponenten arbeiten kann - Peripheriegeräte, CPU-Kerne, Hardwarebeschleuniger, Interruptleitungen usw. Für Unix-ähnliche Betriebssysteme wie VxWorks, Linux usw. gibt es das Baumstruktur-Datenformat - den Gerätebaum. Dieser beschreibt die Hardware in einem binären, kompilierbaren Blob-Format. Außerdem wird er vom Kernel beim Booten geladen. Obwohl nicht so populär in Anwendungen mit RTOSs, beginnt der Gerätebaum mit Echtzeitbetriebssystemen an Popularität zu gewinnen. Andere gängige Methoden zur Abstraktion von Hardware in RTOS-Anwendungen schließen das Schreiben standardisierter C-Routinen, die gut dokumentiert sind, ein.
Die Spezifikation/Dokumentation der verschiedenen APIs dient als To-Do-Liste für Entwickler, die die Hardware-Abstraktionsschichten implementieren. Wir können sie später in den oberen Kernelschichten/Gerätetreibern verwenden. Viele Siliziumhersteller implementieren eine weit verbreitete Spezifikation, den Common Microcontroller Software Interface Standard (CMSIS).
Entwicklung von Gerätetreibern
Nachdem der Bootloader und die Low-Level-Hardwareabstraktionen fertig sind, kann das Betriebssystem auf der benutzerdefinierten Plattform starten. Jetzt kann die Entwicklung der Kernel-Anpassung beginnen. Neue Funktionen werden in Form von Gerätetreibern hinzugefügt, damit die verschiedenen Betriebssystem-Software-Stacks zuverlässig mit den verschiedenen Hardware-Peripheriegeräten, On-Chip-Hardware-Beschleunigern usw. verbunden werden können. Abhängig von der Art des Betriebssystems (Opensource oder proprietär) wird sich der Arbeitsaufwand auf die Anpassung bestehender Open-Source-Treiber oder die Entwicklung neuer Treiber auf der Grundlage von Richtlinien und Beispieltreibern des Betriebssystemanbieters konzentrieren.
Entwicklung und Integration von OS-Stacks
Damit das Betriebssystem in der Lage ist, den Anwendungsdiensten die benötigten Funktionen in Bezug auf Hardware- und Softwareressourcen zuverlässig zur Verfügung zu stellen, müssen wir verschiedene Software-Stacks wie Netzwerke, USB, Video, Audio usw. integrieren oder weiterentwickeln, damit sie den Anforderungen der jeweiligen Anwendung entsprechen. Die meisten proprietären und Open-Source-Betriebssysteme verfügen bereits über gut getestete Standard-Software-Stacks, die die erforderlichen Funktionen für die Anwendungsschicht bereitstellen können. Der einzige Bedarf an kundenspezifischer Entwicklung sind isolierte Anpassungs- und Integrationsarbeiten, sodass nur die erforderlichen Komponenten integriert und entsprechend den Anforderungen der Gesamtanwendung richtig konfiguriert werden.
Anpassung des Stammdateisystems
Eingebettete Anwendungen sind im Allgemeinen auf eine ganze Reihe von Werkzeugen angewiesen, die sie benötigen, damit sie die erforderlichen Funktionen zuverlässig bereitstellen können. Daher ist es erforderlich, dass das rootfs eine benutzerdefinierte Konfiguration hat, um die verschiedenen Pakete, die die Anwendung benötigt, miteinzuschließen.
Testen
Wie jede kundenspezifische Entwicklung muss auch das entwickelte BSP entsprechend den spezifischen Anwendungs-KPIs getestet und bewertet werden. Auf diese Weise hat die gesamte Softwareplattform eine solide Grundlage, auf der sie mit der erwarteten Leistung ordnungsgemäß funktionieren kann. Um alle Tests zuverlässig durchführen zu können, müssen wir die Infrastruktur so einrichten, dass Tests vom Unit- bis zum Systemtest über eine kontinuierliche Integrationspipeline entwickelt und integriert werden können.
Schlussfolgerung
Zusammenfassend lässt sich sagen, dass die Entwicklung eines maßgeschneiderten Board-Support-Pakets eine komplexe Entwicklungsarbeit ist. Sie hängt in hohem Maße von der Art des Betriebssystems und den zugrunde liegenden Eigenschaften der Hardware ab. Außerdem hängt sie von der Anwendung ab, die über dem Betriebssystem ausgeführt wird. Sie diktiert die Funktionen, die sowohl auf der Kernel/BSP-Ebene als auch auf der OS-Middleware-Ebene entwickelt werden müssen.
Weitere Artikel anschauen:
Proc-Dateisystem in Linux
Das Proc-Dateisystem ist eines der am häufigsten verwendeten simulierten Dateisysteme des Linux-Betriebssystems. Wenn das System neu gestartet wird, wird dieses Dateisystem
OpenRC
OpenRC ist ein abhängigkeitsbasiertes Init-System, das für die Arbeit mit Unix-ähnlichen Betriebssystemen entwickelt wurde. Es hält die Kompatibilität mit dem vom System bereitgestellten Init-System aufrecht, das
Yocto-Projekt
Das Yocto-Projekt ist ein Open-Source-Community-Projekt, das Entwicklern hilft, angepasste Systeme auf der Basis von Linux zu erstellen. Es verfügt über ein zugängliches Toolset, das
Software-Tests
Die Untersuchung der Artefakte und des Verhaltens der zu testenden Software wird als Softwaretest bezeichnet. Außerdem wird ermittelt, ob die tatsächlichen Ergebnisse
Platzierung der Komponenten
Die Platzierung von Bauteilen ist einer der kritischsten Teile des PCB-Designs. Zunächst müssen Sie die grundlegenden Kriterien für die Anordnung von
Linux-Systemprogrammierung
Dieser Artikel konzentriert sich auf Linux -Systemaufrufe und andere Low-Level-Operationen, wie zum Beispiel die Funktionen der C-Bibliothek. Systemprogrammierung ist der Prozess der Erstellung von