KI-Beschleuniger¶

Einführung¶

Der KI-Beschleuniger, im SDK NNACC genannt, übernimmt unterstützte Operationen neuronaler Netze auf ausgewählten SF32-Geräten. Er ermöglicht Edge-KI mit lokaler Inferenz, die nicht von einem Cloud-Dienst abhängt. Ob Latenz, CPU-Auslastung oder Energiebedarf sinken, hängt vom Modell, der Speicherzuordnung, der Softwareimplementierung und der gesamten Produktlast ab.

Wearables, Gesundheitsmonitore, intelligente Displays, Sprachzubehör, Sensorfusionssysteme und kompakte AIoT-Produkte sind mögliche Anwendungen. Solche batteriebetriebenen Geräte verbinden häufig Bluetooth, Grafik, Audio, Sensorerfassung und Benutzerinteraktion. Das Delegieren unterstützter Operationen an die Hardware kann CPU-Zeit für andere Aufgaben freigeben; Reaktionsfähigkeit und Energieeinsparung müssen jedoch gemessen werden.

Der genaue Funktionsumfang der KI hängt vom jeweiligen SF32-Gerät und der Unterstützung durch das SDK ab. Prüfen Sie stets das Datenblatt, das Referenzhandbuch und die SDK-Dokumentation für den Zielchip, bevor Sie sich auf eine Modellarchitektur oder Speicheraufteilung festlegen.

Die folgenden Angaben zu CMSIS-NN-Operationen und zur NNACC-Anzahl je Gerät beruhen auf der Dokumentation zu SiFli-SDK v2.5.1. Der NNACC-Leitfaden dieser Version nennt Ressourcen für SF32LB55x/56x/58x, belegt aber keine Verfügbarkeit für SF32LB52x oder SF32LB57x; die fehlende Angabe beweist nicht, dass diese Familien keinen NNACC haben. Die Prüfungen von Adressfenstern, das Warteverhalten und die GC032A-Konfiguration sind Beobachtungen aus den HAL- oder Treiberquellen dieser Version, keine allgemeingültigen Garantien für alle Chiprevisionen oder SDK-Versionen. Der zitierte NNACC-Leitfaden und die Beispiele belegen weder einen durchgängigen Modellkonverter oder eine Graph-Laufzeitumgebung noch einen automatischen CPU-Fallback noch Kameraerfassung für jedes Gerät und jede Platine. Prüfen Sie vor der Festlegung des Designs die genaue SDK-Version und -Konfiguration, Chiprevision, Laufzeitumgebung und Platine.

Diese Seite hilft Ihnen zu beurteilen, ob eine lokale KI-Funktion zum gewählten SF32-Gerät passt und wie sich die Inferenz auf Sensoren, CPU, Speicher und Beschleuniger verteilen lässt. Für die Integration und Bereitstellung von Modellen lesen Sie die ergänzende KI-Übersicht.

Warum KI auf dem Gerät wichtig ist¶

Viele eingebettete Produkte müssen intelligent reagieren, ohne fortlaufend Rohdaten an ein Smartphone oder einen Cloud-Dienst zu übertragen. KI auf dem Gerät kann ein Produkt auf mehrere Arten verbessern:

• Potenziell geringere Latenz: Lokale Inferenz kann den Umweg über ein Smartphone oder einen Cloud-Dienst vermeiden. Messen Sie dennoch die Latenz vom Sensoreingang bis zur Entscheidung am vollständigen Produkt.
• Bessere Privatsphäre, da rohe biometrische, Audio- oder Bewegungsdaten lokal bleiben können.
• Geringerer Funkverkehr, da nur Ereignisse oder Zusammenfassungen übertragen werden müssen.
• Besseres Offline-Verhalten, da Kernfunktionen ohne Netzwerkzugang funktionieren können.
• Geringere durchschnittliche Leistungsaufnahme, aber nur, wenn die vollständige Funktion bei gleicher Genauigkeit und Erkennungsabdeckung über denselben Nutzungszeitraum weniger Energie benötigt, einschließlich des Auslagerungsaufwands.

Für tragbare Geräte und AIoT-Produkte sind diese Vorteile konkret: Eine Uhr kann Gesten klassifizieren, Aktivitätszustände erkennen, Gesundheitssignale überwachen, einfache Sprachtrigger erkennen oder Sensordaten verarbeiten, während Display, Bluetooth und Anwendungsprozessor reaktionsfähig bleiben.

Diese Vorteile gelten nicht ohne Bedingungen. Lokale Verarbeitung reduziert Funkverkehr nur, wenn das Produkt auf die Übertragung der Rohdaten verzichtet. Datenschutz erfordert weiterhin geeignete Speicherung, Zugriffskontrollen und Schutz übertragener Daten. Die folgenden Anwendungen sind Entwurfsmöglichkeiten, keine Zusage, dass das SDK alle Modelle mitliefert.

Position im SF32-System¶

Eine vereinfachte Edge-KI-Verarbeitung auf SF32 sieht so aus:

Sensors / Audio / Camera
        │
        ▼
Pre-processing
  - filtering
  - framing
  - normalization
  - feature extraction
        │
        ▼
Firmware / Inference Runtime
  - model graph orchestration
  - supported operations on NNACC
  - other operations on CPU, if implemented
        │
        ▼
Post-processing
  - thresholding
  - smoothing
  - event detection
  - application decisions
        │
        ▼
Application, UI, Bluetooth, or Storage

Der Beschleuniger ist nur ein Teil der vollständigen KI-Verarbeitungskette. Produkte benötigen weiterhin Datenerfassung und -pufferung, Vorverarbeitung, die Planung der Inferenz, Nachverarbeitung und Entscheidungslogik auf Anwendungsebene. Die beste Leistung ergibt sich meist, wenn die gesamte Verarbeitungskette auf die Speicherhierarchie und die verfügbaren Beschleuniger abgestimmt wird, statt Inferenz als isolierten Funktionsaufruf zu behandeln.

Aufgaben des KI-Beschleunigers¶

KI-Beschleuniger sind nützlich, weil viele Anwendungen neuronaler Netze dieselben mathematischen Muster tausend- oder millionenfach wiederholen. Dazu können Faltungen, Matrixmultiplikationen, Vektoroperationen, Aktivierungsfunktionen, Pooling oder andere Festkomma-Rechenoperationen gehören. Dedizierte Hardware kann ausgewählte Rechenoperationen energieeffizienter ausführen als eine Allzweck-CPU.

Dies sind Beispiele für Berechnungen neuronaler Netze, keine Liste der von SF32 NNACC unterstützten Operationen. Der NNACC-Leitfaden des SiFli SDK v2.5.1 dokumentiert die NNACC-Beschleunigung für drei CMSIS-NN-q7-Faltungsfunktionen, darunter kanalweise Faltung (Depthwise Convolution), und gibt an, dass die NNACC-beschleunigte CMSIS-NN-Implementierung achtmal schneller ist als die ARM-DSP-Implementierung in CMSIS-NN. Der Leitfaden nennt für diesen Wert keine Testbedingungen; behandeln Sie ihn als Herstellerangabe und nicht als Garantie für eine geringere Latenz oder Energieaufnahme des Gesamtmodells. Prüfen Sie jeden Modelloperator und sein Zahlenformat auf Kompatibilität mit der gewählten Implementierung. Matrixmultiplikation, Aktivierung und Pooling sind nicht automatisch jeweils eigenständig beschleunigt. Das SDK bietet außerdem HAL-APIs zur direkten Steuerung des Beschleunigers; gehen Sie jedoch nicht davon aus, dass eine dieser Schnittstellen einen vollständigen Modellkonverter oder eine Laufzeitumgebung für den Rechengraphen bereitstellt. Firmware oder eine separate Inferenz-Laufzeitumgebung muss die Schichten orchestrieren und Puffer verwalten. Für einen CPU-Fallback ist zudem eine Implementierung der nicht unterstützten Operationen erforderlich.

SF32-Geräte haben begrenzte Speicher- und Bandbreitenressourcen. Beginnen Sie daher mit einem kompakten eingebetteten Modell. Prüfen Sie die NNACC-Verfügbarkeit und die Operatorunterstützung für das genaue Bauteil und messen Sie anschließend Speicherbedarf, Latenz und Energieverbrauch der gesamten Verarbeitungskette. Leiten Sie die Unterstützung nicht allein aus dem Familiennamen ab.

Typische KI-Anwendungen sind:

• Erkennung von Schlüsselwörtern oder einfache Erkennung von Sprachereignissen.
• Gestenerkennung anhand von Beschleunigungssensor- und Gyroskopdaten.
• Aktivitätsklassifikation und Bewegungszustandserkennung.
• Sensorfusion für Wearables und Gesundheitsgeräte.
• Biometrische Signalanalyse, abhängig von Sensor- und Algorithmusunterstützung.
• Einfache Bild- oder kameragestützte Klassifikation bei Geräten mit Kameraeingang.
• Anomalieerkennung und lokale Ereignisfilterung.

Rollen von CPU, Beschleuniger und Speicher¶

Als Orientierung gilt: Die CPU steuert den Ablauf, während der Beschleuniger ausgewählte, besonders rechenintensive Operationen übernimmt.

Der Beschleuniger ersetzt die CPU nicht und führt nicht jedes beliebige Modell eigenständig aus. Die Firmware bereitet Eingaben vor, konfiguriert unterstützte Operationen, wartet auf deren Abschluss, verarbeitet Ergebnisse und steuert die Anwendung. Eine nicht unterstützte Operation kann nur dann auf der CPU laufen, wenn die gewählte Laufzeitumgebung oder Anwendung eine entsprechende Implementierung bereitstellt. Andernfalls kann die Bereitstellung des Modells scheitern. Vorhandene Hardware bedeutet nicht, dass automatisch auf die CPU zurückgegriffen wird.

Einordnung nach Gerätefamilie¶

Wählen Sie das Gerät anhand der Operatoren, des Speicherbudgets und der gesamten Produktlast, nicht anhand einer pauschalen Leistungsrangfolge der Familien. Der SDK-v2.5.1-Leitfaden dokumentiert jeweils einen NNACC im HCPU-Subsystem von SF32LB55x und SF32LB56x sowie jeweils einen im HCPU- und LCPU-Subsystem von SF32LB58x. Diese Ressourcen helfen bei der Auswahl, garantieren aber weder eine schnellere Ausführung des gesamten Modells noch weniger Energieverbrauch. Prüfen Sie Verfügbarkeit, zugänglichen Speicher und Softwareunterstützung für das konkrete Bauteil und die Konfiguration.

Diese Tabelle dient der Produktauswahl und ersetzt nicht das Datenblatt. Prüfen Sie für die gewählte Teilenummer die genaue Verfügbarkeit des Beschleunigers, die unterstützten Operatoren, die Speichergrenzen und die verfügbaren SDK-Werkzeuge.

Ablauf der Modellentwicklung¶

Ein typischer Entwicklungsablauf für eingebettete KI umfasst mehrere Phasen:

1. Trainieren oder wählen Sie ein Modell anhand repräsentativer Daten auf einem Entwicklungsrechner aus.
2. Passen Sie das Modell durch sorgfältige Auswahl, Ausdünnen weniger relevanter Parameter (Pruning), Quantisierung oder Architekturänderungen an die Grenzen des eingebetteten Systems an.
3. Wählen oder implementieren Sie Inferenz-Laufzeitumgebung und Modelldarstellung. Prüfen Sie Operatorabdeckung und numerische Kompatibilität mit den gewählten SDK-Kerneln. Setzen Sie keinen Konverter für vollständige Modelle in der NNACC-HAL voraus.
4. Überprüfen Sie die numerische Genauigkeit nach der Konvertierung und Quantisierung.
5. Integrieren Sie Vorverarbeitung, Inferenz und Nachverarbeitung in die Firmware.
6. Messen und profilieren Sie Latenz, Speicherbedarf, Energieverbrauch und Genauigkeit auf der Zielhardware.
7. Testen Sie realistische parallele Bluetooth-, Display-, Audio- und Sensorlasten einschließlich der Übergänge in die vorgesehenen Energiesparzustände und zurück.

Der häufigste Fehler besteht darin, nur das neuronale Netz zu optimieren und den Rest der Verarbeitungskette zu vernachlässigen. In vielen eingebetteten Produkten sind Vorverarbeitung, Speichertransfers, das zeitliche Verhalten der Sensoren und Nachverarbeitung ebenso wichtig wie der Beschleuniger selbst.

Quantisierung und Modellgröße¶

KI auf Mikrocontrollern hängt in der Regel von kompakten Modellen und effizienten numerischen Formaten ab. Quantisierte Modelle, oft mit 8-Bit-Ganzzahldaten, können Speicherbedarf, erforderliche Speicherbandbreite und Rechenkosten im Vergleich zu Fließkommamodellen reduzieren.

Ein 8-Bit-Modell ist nicht automatisch mit NNACC kompatibel. Die HAL-Konfiguration des SDK v2.5.1 verwendet int8_t-Puffer und die Felder bias_shift / out_shift. Daraus folgt keine Unterstützung für beliebige Nullpunkte, kanalweise Skalierungen oder alle heutigen int8-Operatoren. Prüfen Sie Tensorlayout, Vorzeichenbehandlung, Schiebeoperationen und Bias-Darstellung anhand der konkreten Kernelimplementierung. Vergleichen Sie anschließend deren Ausgaben mit einer Softwarereferenz, einschließlich repräsentativer Eingaben und Grenzwerte.

Quantisierung bringt Kompromisse mit sich:

• Sie kann die Effizienz erheblich verbessern.
• Sie kann Modellgröße und Tensorspeicher reduzieren.
• Sie kann die Genauigkeit verringern, wenn das Modell nicht sorgfältig trainiert oder kalibriert wurde.
• Manche Operatoren lassen sich möglicherweise nicht direkt auf dem Beschleuniger oder in der Laufzeitumgebung ausführen.

Messen Sie für den Produktionseinsatz sowohl die Genauigkeit als auch die Systemleistung nach der Konvertierung. Ein Modell, das in einer Trainingsumgebung auf dem Entwicklungsrechner gut abschneidet, kann sich nach der Quantisierung, bei Sensorrauschen und mit der eingebetteten Vorverarbeitung anders verhalten.

Speicher- und Bandbreitenbedarf¶

KI-Anwendungen können speicherintensiv sein, selbst wenn das Modell klein wirkt. Das System benötigt möglicherweise Speicher für:

• Modellgewichte.
• Eingabetensoren.
• Puffer für Zwischenaktivierungen.
• Ausgabetensoren.
• Audio-Frames, Sensorfenster oder Kamerabilder.
• Vor- und Nachverarbeitungspuffer.
• Daten der Benutzeroberfläche, von Bluetooth und der Anwendung, die gleichzeitig verarbeitet werden.

Platzieren Sie häufig genutzte Tensoren und Zwischenpuffer entsprechend der internen SRAM-, Flash-, PSRAM- und Cache-Konfiguration des Zielgeräts so, dass CPU und Beschleuniger effizient darauf zugreifen können. Budgetieren Sie externen Speicher, Arbeitspuffer und Kopien gemeinsam statt nur die Modellgröße zu optimieren.

Prüfen Sie zunächst, ob der gewählte NNACC jeden Puffer erreichen kann. Daten in externem Flash oder PSRAM können eine Kopie in Arbeitspuffer erfordern. Berücksichtigen Sie Kopierzeit, Arbeits-RAM und Energiebedarf. Die HAL-Implementierung des SDK v2.5.1 rundet die geprüften Puffergrößen auf 4-Byte-Vielfache auf und lehnt einen Puffer ab, wenn Beginn und geprüftes Ende in unterschiedlichen 1-MiB-Adressfenstern (1 048 576 Byte) liegen. Eingabe und Bias müssen ebenfalls dasselbe Fenster nutzen. Ein Ende genau an der Grenze zum nächsten Fenster besteht die Prüfung nicht. Planen Sie die Speicherzuordnung nach diesen tatsächlichen Prüfbedingungen und behandeln Sie Fehlerrückgaben vor der nächsten Operation.

Teilt die CPU Puffer mit DMA oder NNACC, darf während jeder Übertragung oder Operation nur der jeweils zuständige Teilnehmer darauf zugreifen. Schreiben Sie CPU-Eingaben vor dem Lesen durch die Hardware aus dem Cache zurück. Bereiten Sie die Cache-Zeilen des Zielpuffers vor dem Hardware-Schreibzugriff gemäß SDK vor, damit noch nicht zurückgeschriebene CPU-Cache-Zeilen später nicht das Ergebnis überschreiben. Nach bestätigtem Hardware-Abschluss invalidieren Sie veraltete CPU-Kopien vor dem Lesen der Ausgabe. Die Cache-Wartung muss vollständige Cache-Zeilen abdecken; vermeiden Sie gemeinsame Zeilen mit anderen noch verwendeten Daten. Das Zurückschreiben alter Ausgabedaten nach dem Hardware-Schreibzugriff kann das Ergebnis zerstören. Zurückschreiben und Invalidieren sind nicht austauschbar.

Audio-, Sensor- und Kameraverarbeitung¶

KI-Beschleunigung arbeitet selten allein. Sie ist meist Teil einer Sensor-, Audio- oder Kameraverarbeitungskette.

Audio und Sprache¶

Die Erkennung von Sprache oder Audioereignissen kann Mikrofoneingang, DMA-Pufferung, Framebildung, Filterung, Merkmalsextraktion, Inferenz und Glättung der Ergebnisse umfassen. NNACC führt unterstützte neuronale Operationen aus; Firmware oder die gewählte Laufzeitumgebung verarbeitet den übrigen Graphen. CPU oder Audio-Subsystem verwaltet Abtastwerte und Merkmale. Modell und validierte Softwareimplementierung werden weiterhin benötigt.

Typische Beispiele sind:

• Erkennung von Schlüsselwörtern.
• Erkennung eines Aktivierungsworts, sofern die Software dies unterstützt.
• Klassifikation von Audioszenen oder -ereignissen.
• Sprachaktivitätserkennung.

Bewegung und Sensorfusion¶

Bei tragbaren Produkten stammen Sensordaten häufig von Beschleunigungssensoren, Gyroskopen, Herzfrequenzsensoren, SpO2-Sensoren, EKG-Frontends oder anderen Peripheriegeräten. KI kann Bewegungszustände, Gesten, Aktivitätsmuster oder gesundheitsbezogene Signalmerkmale klassifizieren.

Bündeln Sie Abtastwerte und verwenden Sie Interrupts, soweit Erkennungsabdeckung und Latenz dies erlauben. Geeignete Hintergrundaufgaben auf einen benutzerprogrammierbaren Low-Power-Prozessor zu verlagern, kann die Anwendungs-CPU seltener aufwecken. Berücksichtigen Sie jedoch dessen Aktivität, Sensorabtastung und Weckkosten im Vergleich. Schalten Sie die für die Ereigniserkennung nötige Erfassung nicht ab.

Kamera- und Bildeingang¶

Der Kameraeingang hängt von Chip, Gehäuse, Platine und Erfassungstreiber ab. Der GC032A-Sensortreiber im SDK v2.5.1 konfiguriert einen 8-Bit-DVP- oder Zwei-Bit-SPI-Sensorausgang. Das belegt nicht, dass beide Erfassungspfade auf jedem SF32-Gerät funktionieren. Prüfen Sie vor der Kameraauswahl Pins, Erfassung über Peripherie oder PTM, Sensortiming und Treiber. Bildverarbeitung benötigt häufig größere Framebuffer und mehr Bandbreite als Audio- oder Bewegungsverarbeitung; vergleichen Sie aber die tatsächlichen Auflösungen und Raten.

Erwägen Sie kleinere Frames, Bildbereiche, niedrigere Bildraten oder ein für eingebettete Systeme ausgelegtes Modell. Zuschneiden in der Firmware nach der Erfassung verkleinert den Modelleingang, nicht zwingend den Kameradatenverkehr oder den Erfassungspuffer. Dafür können sensorinternes Zuschneiden oder eine geringere Datenerfassung nötig sein.

Planung und Energieverwaltung¶

KI-Aufgaben sollten mit Blick auf den Rest des Systems geplant werden. Ein tragbares Produkt muss möglicherweise Bluetooth verbunden halten, das Display aktualisieren, Audio erfassen, Sensoren auslesen und Inferenz ausführen, ohne Energie- oder Latenzziele zu überschreiten.

Beachten Sie bei der Zeitplanung Folgendes:

• Wählen Sie periodische oder ereignisgesteuerte Inferenz passend zur nötigen Erkennungsabdeckung, zum Risiko übersehener Ereignisse und zu den Latenzanforderungen.
• Vermeiden Sie Polling-Schleifen, wenn Interrupts oder Ereignisse die Verarbeitung auslösen können.
• Bündeln Sie Sensorabtastwerte, sofern die Latenzanforderungen dies erlauben.
• Begrenzen Sie die Verzögerung vom Eingang bis zur Entscheidung und erhalten Sie zugleich das für zuverlässige Erkennung nötige Eingabefenster.
• Stimmen Sie die KI-Verarbeitung auf Display- und Bluetooth-Aktivität ab.
• Versetzen Sie CPU und Beschleuniger erst nach bestätigtem Abschluss, Pufferübergabe und Freigabe der nötigen Energiemanagement-Sperren in zulässige Energiesparzustände. Lassen Sie erforderliche Sensorerfassung und ausstehende Arbeiten weiterlaufen.

Ermitteln Sie die Energie der vollständigen Funktion, indem Sie die gemessene Versorgungsleistung (Versorgungsspannung × Strom) über die Zeit integrieren; die Inferenzlatenz allein reicht dafür nicht. Berücksichtigen Sie Sensorerfassung, Vorverarbeitung, Kopien, Beschleunigerbetrieb, CPU-Fallback, Nachverarbeitung und Leerlaufzeiten. Schnellere Ausführung kann aktive Energie sparen, ohne einen früheren Schlafzustand zu ermöglichen; der Nutzen hängt von den übrigen Systemlasten ab. Vergleichen Sie gleichwertige Erkennungsabdeckung und Genauigkeit, bevor Sie die Inferenzhäufigkeit reduzieren.

Im SDK v2.5.1 wartet der blockierende HAL-Start per Polling auf den Abschluss, ohne eigenes explizites Zeitlimit. Der Interrupt-Modus benötigt einen funktionierenden IRQ-Handler und eine Abschlussmeldung. Prüfen Sie Startfehler, begrenzen Sie die Wartezeit der Anwendung und definieren Sie die Wiederherstellung vor Pufferwiederverwendung oder Freigabe von Energiemanagement-Sperren.

Kompromisse zwischen Genauigkeit, Latenz und Energie¶

Bei eingebetteter KI müssen Genauigkeit, Latenz und Energiebedarf gegeneinander abgewogen werden.

Die richtige Balance hängt vom Produkt ab. Eine Gestenerkennung kann eine geringe Verzögerung tolerieren, wenn dadurch Energie gespart wird. Die Erkennung eines Sprachaktivierungsworts erfordert möglicherweise eine schnelle Reaktion, darf aber keine Fehlaktivierungen auslösen. Ein Algorithmus zur Gesundheitsüberwachung priorisiert möglicherweise Robustheit und lange Akkulaufzeit gegenüber einer sofortigen Klassifikation.

Praktische Design-Hinweise¶

Beginnen Sie bei der Planung eines SF32-KI-Produkts mit dem Produktverhalten, nicht mit dem Modell:

• Welche Entscheidung muss das Gerät lokal treffen?
• Welche Sensoren liefern die Eingabedaten?
• Wie oft muss die Inferenz laufen?
• Welche Latenz ist akzeptabel?
• Wie hoch ist das maximale Speicherbudget für Modellgewichte und Tensoren?
• Kann das Modell quantisiert werden, ohne zu viel Genauigkeit zu verlieren?
• Welche Operationen werden vom gewählten Chip und SDK beschleunigt?
• Was passiert, wenn Bluetooth, Display, Audio und Inferenz gleichzeitig aktiv sind?
• Wie wird die Modellgenauigkeit mit echten Produktdaten validiert?
• Wie wird die Firmware das Modell im Feld aktualisieren oder ersetzen, falls erforderlich?

Ein erfolgreiches eingebettetes KI-Produkt kombiniert in der Regel ein kompaktes Modell, sorgfältige Datenerfassung, eine an die Hardware angepasste Speicherzuordnung, realistische Leistungsmessungen und eine Energiestrategie, die unnötige Weckvorgänge vermeidet.

Typische Anwendungsfälle¶

SF32-KI-Beschleunigung kommt für kompakte lokale Inferenz in vernetzten, batteriebetriebenen Produkten infrage, wenn unterstützte Operatoren und das gemessene Systembudget passen:

• Gestenerkennung bei Uhren, Armbändern und Handgeräten.
• Aktivitätsklassifikation für Fitness- und Gesundheitsprodukte.
• Sprachereignis- oder Schlüsselworterkennung für Audiozubehör.
• Sensorfusionsalgorithmen für tragbare Geräte.
• Biometrische Signalanalyse, sofern von Sensoren und Software unterstützt.
• Lokale Anomalieerkennung für intelligente Geräte.
• Einfache Bildklassifikation oder kameraausgelöste Ereignisse bei Geräten mit Kameraeingang.
• Eine HMI, die ihr Verhalten an den Nutzungskontext anpasst.

Wichtigste Erkenntnisse¶

• NNACC kann unterstützte Operationen übernehmen und die CPU-Auslastung senken; Latenz- und Energievorteile müssen für die vollständige Funktion geprüft werden.
• Er ist Teil einer vollständigen Verarbeitungskette, die auch Sensoren, Audio- oder Kameraeingang, Vorverarbeitung, Speichertransfers, Nachverarbeitung und Anwendungslogik umfasst.
• SDK v2.5.1 dokumentiert NNACC-Ressourcen für SF32LB55x, SF32LB56x und SF32LB58x, belegt die Verfügbarkeit für SF32LB52x oder SF32LB57x jedoch nicht. Prüfen Sie das genaue Bauteil und die Produktlast, statt aus dem Familiennamen auf Unterstützung oder deren Fehlen zu schließen.
• Die tatsächliche Leistung hängt von Modellgröße, Quantisierung, unterstützten Operatoren, Speicherzuordnung, Cache-Verhalten, DMA und Laufzeitunterstützung des SDK ab.
• Lokale Inferenz ist sinnvoll, wenn sie Reaktions-, Offline-, Datenschutz- oder Funkverkehrsziele des Produkts erfüllt. Die Beschleunigerhardware allein garantiert diese Vorteile nicht.

Zuletzt aktualisiert: 2026-10-19