Ein falsch gewählter Mikrocontroller in einem Wearable-Design erzwingt typischerweise ein PCB-Redesign nach dem ersten Prototyp – mit 8–16 Wochen Verzögerung und Mehrkosten von 15.000–40.000 € je nach Komplexität. Die Entscheidung fällt früh, aber ihre Konsequenzen treffen das Team erst in der Validierungsphase. Zwei grundlegende Pfade stehen zur Wahl: ein dedizierter Ultra-Low-Power-MCU mit externem Funk-Modul, oder ein integriertes SoC mit eingebetteter Konnektivität. Beide Pfade haben unterschiedliche Implikationen für Zertifizierungsaufwand, Lieferkette und Energiebudget.

Dieser Artikel liefert einen strukturierten Mikrocontroller-Vergleich für Wearables mit konkreten Entscheidungskriterien für Teams, die ein IoT-Wearable oder ein anderes tragbares Embedded-System entwickeln.

Anforderungsprofil: Was ein Wearable vom Mikrocontroller fordert

Wearable-Designs erzwingen gleichzeitige Optimierung über vier Dimensionen: Sleep-Strom unter 5 µA für Laufzeitziele jenseits einer Woche, ausreichend Rechenleistung für Sensorfusion oder Signalverarbeitung, PCB-Footprint unter 5 × 5 mm in vielen Formfaktoren, und integrierte oder angebundene Konnektivität. Kein einzelner Chip optimiert alle vier gleichzeitig – jede Auswahl ist ein Kompromiss.

Anwendungsspezifische Anforderungen verstärken diesen Konflikt. Ein industrieller Asset-Tracker mit LoRa-Konnektivität priorisiert Sleep-Strom und Lieferkettenstabilität über Rechenleistung. Ein medizinisches Patch-EKG benötigt deterministische Interrupt-Latenz unter 10 µs und IEC 62304-konforme Toolchain-Dokumentation – beides schränkt die Chipauswahl unabhängig vom Energieprofil ein. Weitere Parameter, die die Auswahl direkt einschränken:

• Schnittstellenanzahl und -typ (I2C, SPI, UART, ADC) gegen verfügbare Pins im Zielgehäuse
• Hardware-Kryptografie-Engine für BLE-Pairing oder Cloud-Authentifizierung ohne CPU-Overhead
• RTOS-Kompatibilität (Zephyr, FreeRTOS) und Qualität des BSP-Supports
• Bestätigte Langzeitverfügbarkeit – mindestens 7 Jahre für Medizin- und Industrieprodukte
• Zertifizierungsrelevanz: Vorhandene CE/FCC-Modulzertifizierungen reduzieren RF-Qualifizierungsaufwand um 6–12 Wochen

Teams, die diese Parameter nicht vor der Chipauswahl in einem Lastenheft fixieren, treffen die Entscheidung implizit – und bemerken die Konsequenzen erst beim Design-Review. Eine frühe Zusammenarbeit mit erfahrenen Embedded-Entwicklern, wie dem Team von Oxeltech, hilft, diese Parameter systematisch zu erfassen.

Architekturauswahl: ARM Cortex-M und die relevanten Varianten

ARM Cortex-M-basierte MCUs dominieren Wearable-Designs, weil das Ökosystem aus Toolchains, RTOS-Ports und zertifizierten Softwarekomponenten den Entwicklungsaufwand gegenüber proprietären Architekturen messbar reduziert. Relevante Varianten unterscheiden sich in Leistung, Sicherheitsfunktionen und Stromverbrauch erheblich.

Cortex-M0+ vs. M4 vs. M33

Der Cortex-M0+ erreicht typisch 9–30 µA/MHz im Aktivbetrieb und ist für einfache Sensordatenerfassung ohne DSP-Anforderungen geeignet. Sobald das Design FFT-basierte Herzfrequenzanalyse oder PPG-Signalverarbeitung erfordert, fehlt die Hardware-Multiply-Accumulate-Pipeline – die Verarbeitung dauert 4–8× länger, was das Energiebudget trotz niedrigerem Aktivstrom verschlechtert. Der Cortex-M4 mit FPU löst dieses Problem, verbraucht aber 20–50% mehr Strom im Aktivbetrieb. Der Cortex-M33 mit TrustZone ist die richtige Wahl, wenn das Design Secure Boot, attestierbare Firmware-Updates oder PSA-Zertifizierung benötigt – nicht als generelles Upgrade.

Relevante Chip-Familien

STM32L-Serie (STMicroelectronics): Sleep-Strom ab 300 nA, breite Peripherieausstattung, gut dokumentierte HAL. Risiko: STM32-Chips hatten 2021–2023 Lieferzeiten von 52+ Wochen. Zweite Bezugsquelle oder Designalternative muss früh identifiziert werden. NXP i.MX RT und LPC-Familie: starke Sicherheits-IP, etabliert in medizinischen Wearables, höhere Einstiegskosten bei 10K-Stückzahlen (1,80–3,20 € vs. 0,80–1,40 € für vergleichbare STM32). Nordic nRF52-Serie: BLE 5.x integriert, Sleep-Strom ab 1,5 µA mit aktivem RTC, FCC/CE-Modulzertifizierungen verfügbar – reduziert RF-Zertifizierungsaufwand direkt. Nachteil: bei Designs ohne BLE-Bedarf zahlt das Team für ungenutzte RF-Komplexität.

Stromverbrauch bewerten: Duty-Cycle-Modell statt Datenblatt-Vergleich

Der Datenblatt-Minimalwert für den Sleep-Strom gilt unter Laborbedingungen ohne aktive Peripherie, bei 25 °C und mit deaktiviertem internen Spannungsregler. Im realen Wearable-Betrieb mit aktivem RTC, einem I2C-Sensor im Low-Power-Polling und aktiviertem BLE-Advertising liegt der tatsächliche Sleep-Strom 3–10× über dem Datenblattwert. Teams, die ihr Energiebudget auf Basis von Minimal-Specs kalkulieren, verfehlen ihre Akkulaufzeitziele systematisch.

Ein belastbares Energiebudget erfordert ein Duty-Cycle-Modell mit realistischen Betriebszustandsverteilungen. Relevante Kennwerte für den Vergleich:

• Aktivstrom bei Ziel-Taktfrequenz in µA/MHz – nicht bei maximaler Taktrate
• Sleep-Strom mit aktivem RTC und einem aktiven Peripheriemodul
• Aufwachlatenz aus Deep Sleep – relevant für Systeme mit deterministischen Abtastraten
• Strom des integrierten DC/DC-Wandlers vs. externem LDO bei Ihrer Versorgungsspannung

Ein Chip mit 800 nA Deep-Sleep aber 200 µA/MHz Aktivstrom kann bei einem Design mit 10% Duty Cycle schlechter abschneiden als ein Chip mit 3 µA Deep-Sleep und 80 µA/MHz. Die Entscheidung hängt vom konkreten Duty-Cycle-Profil ab – nicht von einem einzelnen Kennwert. Wer dieses Modell nicht vor der Chipauswahl erstellt, entscheidet ohne ausreichende Grundlage.

Integriertes SoC vs. MCU mit externem Modul: Wann welche Architektur

Integrierte SoC-Lösungen wie Nordic nRF52840 oder Espressif ESP32-S3 reduzieren Komponentenanzahl, vereinfachen das Antennenlayout und können bei 10K-Stückzahlen 0,40–0,80 € pro Einheit gegenüber einer diskreten MCU-plus-Modul-Kombination einsparen. Für Designs mit BLE als primärem Kommunikationsweg und engen Footprint-Vorgaben ist das SoC in den meisten Fällen die effizientere Wahl.

Die Integration erzeugt aber spezifische Risiken, die Teams regelmäßig unterschätzen. Erstens: Ein SoC mit integriertem RF-Subsystem unterliegt vollständig den RF-Zertifizierungsanforderungen, auch wenn das Endprodukt nur BLE nutzt. Wird die RF-Schicht modifiziert oder eine eigene Antenne verwendet, entfällt die Modulzertifizierung – FCC/CE-Neuzertifizierung kostet 8.000–25.000 € und 8–14 Wochen. Zweitens: Einzel-Lieferanten-Abhängigkeit. Beim nRF52-Engpass 2022 standen mehrere Wearable-Produktionen still, weil keine pin-kompatible Alternative existierte. Eine separate MCU-plus-zertifiziertes-Modul-Architektur erlaubt unabhängige Beschaffung beider Komponenten.

Die diskrete Architektur ist vorzuziehen, wenn: die Rechenleistung des SoC für die Anwendung nicht ausreicht, unterschiedliche Konnektivitätsoptionen (BLE + LoRa) parallel benötigt werden, oder die Zertifizierungsstrategie auf bestehenden Modulzertifizierungen aufbaut und RF-Änderungen ausgeschlossen sein müssen.

Typische Fehler bei der Mikrocontroller-Auswahl für Wearables

Der häufigste Fehler ist die Überprojektion von Rechenleistung ohne gleichzeitige Analyse des Energieprofils. Ein Cortex-M4 mit 80 MHz löst das Signalverarbeitungsproblem, verdoppelt aber unter Umständen den Aktivstrom gegenüber einem M0+ mit optimierter Firmware – bei einem 200 mAh-Akku entspricht das einer Differenz von 30–50% in der Gesamtlaufzeit.

Weitere Fehler mit konkreten Konsequenzen:

• Datenblatt-Optimismus: Sleep-Strom-Minimalwerte gelten ohne aktive Peripherie. Reale Systeme mit RTC, einem aktiven Sensor und BLE-Advertising liegen 3–10× darüber. Wer das Energiebudget auf Minimalwerten aufbaut, trifft die Laufzeitziele nicht.
• Toolchain-Bewertung ausgelassen: Ein Chip ohne JTAG/SWD-Debugger-Support oder ohne gepflegten Zephyr-BSP verlängert die Firmware-Entwicklung um 4–8 Wochen. Das ist kein Komfortproblem, sondern ein Terminrisiko.
• Beschaffungsplanung zu spät: Populäre Chips wie STM32L4 oder nRF52840 hatten 2021–2023 Lieferzeiten von 40–65 Wochen. Wer das erst nach dem Prototyp adressiert, blockiert die Serienanlaufplanung.
• Zertifizierungsanforderungen ignoriert: Für Medizinprodukte nach MDR oder IEC 60601-1 schränken Anforderungen an Toolchain-Qualifizierung und Softwarelebenszyklus die Chipauswahl direkt ein – unabhängig von technischen Parametern.

Diese Fehler entstehen nicht aus mangelndem Fachwissen, sondern aus zu früher Chipfixierung ohne vollständiges Anforderungsprofil. Eine strukturierte Anforderungsanalyse mit erfahrenen Embedded-Entwicklern – idealerweise vor der ersten Schaltplanrevision – verhindert die kostspieligsten Korrekturen. Ein frühes Beratungsgespräch mit dem Oxeltech-Team reduziert dieses Risiko nachweislich.

Wie Oxeltech bei der Mikrocontroller-Auswahl für Wearables unterstützt

Oxeltech begleitet Wearable-Projekte von der Anforderungsanalyse bis zur Serienproduktion. Die Mikrocontroller-Auswahl wird dabei nicht isoliert getroffen, sondern im Kontext von Energiebudget, Zertifizierungsstrategie, Lieferkette und Firmware-Architektur bewertet.

Konkrete Leistungen im Projektverlauf:

• Strukturierte Anforderungsanalyse mit Energiebudget-Modellierung und Konnektivitätsprofil
• Vergleich und Bewertung von Architekturen: ARM Cortex-M0+/M4/M33, STM32L, NXP LPC/i.MX, Nordic nRF52/nRF53
• Firmware-Entwicklung auf Zephyr und FreeRTOS mit dokumentierter Toolchain für regulierte Märkte
• Integration von BLE, Wi-Fi, LoRa und NB-IoT mit Bewertung der Zertifizierungsimplikationen je Konnektivitätsoption
• Energieoptimierung auf Hardware- und Firmware-Ebene mit messbaren Laufzeitzielen
• Begleitung durch CE-, FCC- und MDR-Zertifizierungsprozesse bis zur Serienfreigabe

Für Start-ups mit erstem Produktdesign und für etablierte Teams mit komplexen Redesign-Anforderungen gilt gleichermaßen: Die Chipauswahl ist reversibel, aber nur vor dem ersten Schaltplan-Commit ohne Zusatzkosten. Nehmen Sie jetzt Kontakt auf und besprechen Sie Ihr Wearable-Projekt mit dem Oxeltech-Team.

Ähnliche Beiträge

• Wie schützt man Wearable-Elektronik vor Schweiß und Feuchtigkeit?
• Wie integriert man GPS-Tracking energieeffizient in ein Wearable?
• Was ist der Unterschied zwischen einem Wearable-Prototyp und einem Serienprodukt?
• Wie entwickelt man ein ultra-kompaktes Wearable-Design?
• Welche Rolle spielt das Gehäusedesign bei der Wearable-Entwicklung?