> For the complete documentation index, see [llms.txt](https://taiphoon-com.gitbook.io/taiphoon.com-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://taiphoon-com.gitbook.io/taiphoon.com-docs/de/support/knowledge-base/mcu.md). # Mikrocontroller (MCU) Was Mikrocontroller, Firmware und Bootloader sind ### Was ist eine MCU? Die MCU (Microcontroller Unit, Mikrocontroller) ist der zentrale Prozessor auf dem Flugcontroller. Sie führt die Firmware aus, liest Sensordaten, berechnet die Fluglage und die Steuerausgaben und kommuniziert mit Peripheriegeräten wie GPS, Telemetrie, Empfänger und ESC. Die MCU kann als „Echtzeit-Steuerzentrale“ des gesamten Flugsteuerungssystems betrachtet werden. Die meisten Funktionen, die Sie in ArduPilot oder einer anderen kompatiblen Flugcontroller-Firmware sehen, etwa Sensorkalibrierung, Lageberechnung, PWM/DShot-Ausgabe, Failsafe-Entscheidung und Datenaufzeichnung, werden letztlich von der MCU koordiniert und ausgeführt. ### Wofür ist die MCU auf dem Flugcontroller zuständig? Die MCU auf einem Flugcontroller ist in der Regel für folgende Aufgaben zuständig: * Lesen der Daten von On-Board-Sensoren wie IMU, Barometer und Magnetometer. * Ausführen der Hauptschleife der Flugcontroller-Firmware, einschließlich Lageschätzung, Reglerberechnung und Missionslogik. * Bereitstellen von Schnittstellen wie UART, I2C, SPI und CAN zum Anschluss externer Module. * Steuern der Motorausgänge, des Summers, der LEDs und anderer On-Board-I/Os. * Abwickeln des Startvorgangs, des Bootloaders, von Firmware-Updates und Debug-Verbindungen. Als normaler Anwender müssen Sie die MCU nicht unbedingt direkt bedienen. Wenn Sie jedoch eine benutzerdefinierte Firmware kompilieren, die Pin-Zuordnung verstehen, Kommunikationsstörungen untersuchen oder per ST-LINK flashen müssen, sind die Grundlagen der MCU wichtig. ### Warum sollten Sie die MCU verstehen? Das Verständnis der MCU soll nicht jeden Anwender zur Low-Level-Entwicklung bewegen, sondern hilft Ihnen, in den folgenden Situationen die Ursache eines Problems schneller einzugrenzen: * Die Firmware lässt sich nicht ordnungsgemäß flashen oder starten. * Ein UART-, I2C- oder CAN-Peripheriegerät funktioniert nicht. * Bei benutzerdefinierten Board-Einstellungen müssen Pins und Ressourcenzuordnung abgeglichen werden. * Wenn die Platine in den Bootloader-, DFU- oder ST-LINK-Flashvorgang wechselt, muss der Zustand der MCU überprüft werden. Beispiel: Wenn Sie in Mission Planner oder einem anderen Werkzeug eine Verbindung zum Flugcontroller herstellen können, das GPS aber keine Daten liefert, liegt das Problem möglicherweise nicht an einer „defekten Firmware“, sondern daran, dass das GPS an den falschen UART angeschlossen ist, die Parameter der seriellen Schnittstelle falsch eingestellt sind oder die diesem UART zugeordneten MCU-Pin-Ressourcen nicht korrekt konfiguriert sind. ### Unterschiede zwischen MCU, CPU und Flugcontroller-SoC In Flugcontroller-Dokumentationen bezeichnet MCU einen Mikrocontroller mit Echtzeit-Steuerfähigkeit, der in der Regel Prozessorkern, Flash, RAM und verschiedene Peripherieschnittstellen auf einem einzigen Chip vereint. Sie unterscheidet sich von der CPU, die in normalen Desktop-PCs oder leistungsstarken Rechenplattformen üblich ist. Eine CPU ist in der Regel auf externen Speicher und ein Betriebssystem angewiesen und eignet sich für anspruchsvolle Berechnungen; eine MCU legt dagegen mehr Wert auf Echtzeitfähigkeit, geringe Latenz, vorhersagbares Verhalten und die direkte Steuerung der Hardware-I/Os. Aus diesem Grund verwenden Flugcontroller eine MCU als Hauptsteuerung. ### Mit welchen Geräten ist die MCU im Flugsteuerungssystem verbunden? Die MCU arbeitet in der Regel nicht allein, sondern bildet zusammen mit verschiedenen Peripheriegeräten ein vollständiges System. Häufige Verbindungen sind: * IMU: Überträgt Beschleunigungs- und Winkelgeschwindigkeitsdaten über SPI oder I2C. * Barometer, Magnetometer: Liefern Höhen- und Kursinformationen. * GPS-/Kompassmodul: Wird häufig über UART, I2C oder CAN angeschlossen. * RC-Empfänger: Gibt Steuersignale über Schnittstellen wie SBUS, CRSF oder IBUS ein. * ESC: Gibt Motorsteuerbefehle über Protokolle wie PWM oder DShot aus. * Verbindung zur Bodenkontrollstation: Kommuniziert über USB oder einen Telemetrie-UART mit Mission Planner / QGroundControl. Deshalb wirken sich die Anzahl der Peripherieschnittstellen der MCU, die Zuordnung der Kommunikationsports und die Planung von Ressourcen wie DMA/Timer direkt auf den Funktionsumfang und die Erweiterbarkeit des Flugcontrollers aus. ### Bootloader und Hauptfirmware Bei einem benutzerdefinierten ArduPilot-Board darf das Kompilieren und Flashen des Bootloaders nicht übersprungen werden; erst danach folgen Konfiguration und Kompilierung der Hauptfirmware. Den Bootloader können Sie sich als „kleines Startprogramm vorstellen, das nach dem Einschalten zuerst ausgeführt wird“. Zu seinen Aufgaben gehören in der Regel: * Initialisieren des grundlegendsten Hardwarezustands. * Bereitstellen eines Einstiegspunkts zum Flashen der Firmware. * Entscheiden, ob zur Ausführung der Haupt-Flugcontroller-Firmware gesprungen wird. Wenn die Platine nicht ordnungsgemäß in die Hauptfirmware wechselt, wird bei der Fehlersuche in der Regel zuerst geprüft, ob der Bootloader vorhanden ist, ob USB/DFU erkannt wird und ob ein erneutes Flashen per ST-LINK erforderlich ist. ### MCU-Ressourcen, auf die Entwickler achten sollten Wenn Sie nicht nur Flugeinstellungen vornehmen, sondern die Board-Unterstützung einer Autopilot-Firmware (Autopilot) oder eine benutzerdefinierte Firmware pflegen möchten, sollten Sie vor allem die folgenden MCU-Ressourcen verstehen: * Flash: Speichert die Images von Bootloader und Hauptfirmware. * RAM: Laufzeitdaten, Puffer und Stack-Speicher für Tasks. * UART: Verbindung zu GPS, Telemetrie, Empfänger oder externem Computer. * SPI / I2C: Kommunikation mit On-Board-Sensoren und externen Peripheriegeräten. * Timer / PWM-Ausgang: Steuerung von Motoren, Servos, Summer usw. * USB / DFU / SWD: Flashen, Debuggen und Wiederherstellung. Im Board-Portierungsprozess von ArduPilot spiegeln sich diese Ressourcen in den hwdef-Einstellungen und der Board-Definition wider. Die MCU ist daher nicht nur eine Hardwarebezeichnung, sondern die zentrale Grundlage der gesamten Board-Unterstützung. ### Wie sollten Sie MCU-Spezifikationen bewerten? Für normale Anwender ist bei den MCU-Spezifikationen nicht der „Modellname an sich“ am wichtigsten, sondern ob die MCU für Ihre Missionsanforderungen und Ihre Peripheriekonfiguration ausreicht. Sie können sich dies folgendermaßen vorstellen: | Kriterium | Bedeutung für Anwender | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | Rechenleistung | Beeinflusst den Spielraum für hochfrequente Regelung, Filterung, Navigation und parallel laufende komplexe Funktionen. | | Speicherkapazität | Beeinflusst den Platz für Firmwarefunktionen, die Aufzeichnung und die künftige Erweiterbarkeit. | | Anzahl UART / CAN | Beeinflusst, wie viele GPS-, Telemetrie-, Empfänger- oder DroneCAN-Peripheriegeräte gleichzeitig angeschlossen werden können. | | SPI- / I2C-Ressourcen | Beeinflusst die Sensorkonfiguration und die Flexibilität beim Anschluss externer Module. | | Flash- und Debug-Methode | Beeinflusst den Komfort bei Firmware-Upgrades, Wiederherstellung sowie Entwicklung und Wartung. | ### Wann müssen Sie direkt mit der MCU arbeiten? Im normalen Montage- und Tuning-Ablauf müssen Anwender die MCU nicht direkt bedienen. In den folgenden Fällen ist jedoch in der Regel eine weitergehende Beschäftigung mit MCU-bezogenen Arbeiten erforderlich: 1. Wenn die Firmware neu kompiliert werden muss. 2. Wenn die Firmware beschädigt ist, USB nicht ordnungsgemäß erkannt wird und ein Wiederherstellungs-Flashen per ST-LINK erforderlich ist. 3. Wenn geprüft werden muss, an welche UART-/SPI-/I2C-Pins ein Peripheriegerät tatsächlich angeschlossen ist. 4. Wenn Board-Anpassungen, Funktionsreduzierungen oder Debugging durchgeführt werden sollen. ### Häufige Missverständnisse **Missverständnis 1: Je neuer die MCU, desto besser ist der Flugcontroller zwangsläufig.**\ Nicht unbedingt. Die Leistung eines Flugcontrollers hängt auch von der Stromversorgung der Platine, der Sensorkonfiguration, der Qualität der Leiterbahnführung, der Reife der Firmware-Unterstützung und der I/O-Planung ab. **Missverständnis 2: Solange sich die Firmware flashen lässt, funktionieren alle Peripheriegeräte zwangsläufig.**\ Nicht unbedingt. Ob Peripheriegeräte ordnungsgemäß funktionieren, hängt auch davon ab, ob MCU-Pin-Zuordnung, Zuweisung der Kommunikationsports, Parametereinstellungen und Verkabelung übereinstimmen. **Missverständnis 3: MCU-Probleme lassen sich nur durch Zerlegen der Platine feststellen.**\ Viele Probleme lassen sich zunächst anhand des Sensorstatus in der Bodenkontrollstation, der Einstellungen der seriellen Schnittstellen, des Startverhaltens und des Flash-Modus vorläufig beurteilen. ### Hinweise **Hinweis:** Stellen Sie keinen MCU-Defekt fest, bevor Sie Verkabelung, Stromversorgung und Firmware-Version überprüft haben. Wenn der Flugcontroller nicht startet, keine Verbindung herstellt oder Sensorfehler auftreten, können häufige Ursachen auch eine instabile Stromversorgung, falsche Verkabelung oder unpassende Parametereinstellungen sein. **Hinweis:** Wenn Sie ST-LINK, SWD oder ein Low-Level-Flashen verwenden müssen, stellen Sie zunächst die entsprechenden Kontaktpunkte, Spannungsbedingungen und Ablaufdokumente zusammen, um bei falscher Verkabelung weitere Risiken für die Platine zu vermeiden.