Entwicklung von Embedded-Linux-BSPs und STM32-Firmware

Obeita unterstützt Gerätehersteller dabei, Embedded-Platinen in Betrieb zu nehmen, Firmware anzupassen und Fehler zu beheben, die eine Produktauslieferung verhindern. Ausgangspunkt ist eine klar definierte Entwicklungsaufgabe oder ein reproduzierbares Problem. Softwareänderungen betrachten wir zusammen mit der Platine, den Schnittstellen und den Tests an realer Hardware, die das vereinbarte Verhalten nachweisen.

Embedded Linux, BSP, Treiber und U-Boot

Den Umfang der Platineninbetriebnahme vom Bootvorgang über die Peripherie bis zum Anwendungsstart festlegen. Je nach Platine und verfügbarem Quellcode kann die Arbeit U-Boot-Anpassungen, Device-Tree-Änderungen, Treiberintegration, Buildroot-Konfiguration und das Aufspielen von Systemabbildern umfassen. Die Anpassung eines Android-BSP wird anhand der jeweiligen Herstellerplattform und des Systemabbilds gesondert geprüft.

Bei Boot- oder Stabilitätsproblemen untersuchen wir Stromversorgung, serielle Logs, Start- und DDR-Verhalten, elektrische Pegel, Treiber und das Zusammenspiel mit Anwendungen. Änderungen beziehen sich auf eine definierte Platinenrevision und einen bestimmten Softwarestand. Reproduktionsschritte und ausgeschlossene Ursachen werden dokumentiert.

Zu den abgeschlossenen und gelieferten Projekten gehören die RK3566-Terminal- und BSP-Anpassung, die Linux/Qt-HMI-Entwicklung und die Entwicklung eines RK3528-Linux-Netzwerk-Gateways. Die Fallbeschreibungen legen den gelieferten Umfang dar. Einzelne Anforderungen an Linux, Android und Bootloader müssen weiterhin projektbezogen vereinbart werden.

STM32-Firmware und Planung von RTOS-Projekten

Bei MCU-Projekten werden vor der Umsetzung das Verhalten der Peripherie, Erfassungszeitpunkte, Kommunikationsrahmen, Fehlerbehandlung und Wiederanlauf festgelegt. Wenn Ihre Anwendung ein RTOS benötigt, nennen Sie Kernel und Version, Aufgabenprioritäten, Interrupt-Nutzung, Speichergrenzen und Scheduling-Anforderungen. Auf dieser Grundlage können Umfang und Tests vereinbart werden.

Die Fallstudien zur STM32-Datenerfassung und zum IoT-Gateway mit mehreren Schnittstellen belegen abgeschlossene und gelieferte STM32-Arbeiten. In den veröffentlichten Beschreibungen wird kein RTOS genannt. Sie dienen daher als Referenzen für STM32-Hardware und -Firmware.

Lieferumfang und Verifizierung

• Eine Diagnose oder vereinbarte Firmware-/BSP-Änderungen unter Angabe der relevanten Platinen- und Softwareversionen.
• Build- und Konfigurationshinweise, Anleitungen zum Flashen oder zur Wiederherstellung sowie Prüfprotokolle gemäß dem vereinbarten Projektumfang.
• Quellcode, Patches, Designänderungen und Wartungsverantwortlichkeiten, die vor der Übergabe ausdrücklich festgelegt werden.

Die Abnahme kann unter vereinbarten Testbedingungen den Start, die Peripheriefunktionen, Kommunikation, Fehlerreproduktion und Wiederherstellung abdecken. Testdauer, Last und Bestehenskriterien werden auf die Anwendung abgestimmt. Ein erfolgreicher Start allein weist weder Langzeitstabilität nach noch validiert er jede Schnittstelle.

Die verlinkten Kundenprojekte wurden abgeschlossen und geliefert, nachdem Tests von Hardware und Software an realen Geräten die Erfüllung der vereinbarten Anforderungen bestätigt hatten. Eine neue Platinenrevision, ein anderer Treiber, ein RTOS oder ein neues Softwareabbild erfordert eine eigene Verifizierung.

Unterlagen für eine fundierte Prüfung

Senden Sie Platinenrevision, Schaltplan oder Schnittstellendetails, Angaben zur Stromversorgung, Boot- oder serielle Logs, Reproduktionsschritte, aktuelle Firmware, Informationen zur Quellcodeverfügbarkeit und das erwartete Verhalten. Benennen Sie Einschränkungen beim Quellcode sowie die für Tests verfügbare Hardware. So lässt sich die Diagnose von einer umfassenderen Portierung, Neuentwicklung oder Hardwareänderung abgrenzen.

Passende Embedded-Plattformen

Ihre Firmware- oder BSP-Aufgabe besprechen