Wie man die Batterielebensdauer in Dual-Mode Wi-Fi/Bluetooth IoT-Designs maximiert

Von Stephen Evanczuk

Zur Verfügung gestellt von Nordamerikanische Fachredakteure von DigiKey

Entwickler von batteriebetriebenen Geräten für das Internet der Dinge (Internet of Things, IoT) und anderen damit verbundenen Produkten werden aufgefordert, die widersprüchlichen Anforderungen an eine kontinuierliche drahtlose Konnektivität und eine verlängerte Batterielebensdauer zu erfüllen. Eine weitere Ausdehnung der bereits eingeschränkten Leistungsgrenzen ist die wachsende Nachfrage nach sowohl Bluetooth 5 als auch Wi-Fi-Konnektivität in ein und demselben Gerät. Obwohl Wi-Fi- und Bluetooth-Protokolle Standardprotokolle zur Reduzierung des Stromverbrauchs zur Verfügung stellen, gibt es eine direktere Unterstützung in Form einer Architektur, die Funk-Subsysteme, die Aufgaben der Netzwerkverarbeitung entlasten können, mit einem stromsparenden Mikrocontroller kombiniert.

In diesem Artikel wird die Bedeutung von Dual-Mode-Wi-Fi/Bluetooth-Konnektivität umrissen und wie sie IoT-Designs erschwert. Anschließend wird gezeigt, wie ein Entwicklungsboard und die dazugehörige Software von Cypress Semiconductor für die Entwicklung von Dual-Mode Wi-Fi/Bluetooth IoT-Geräten verwendet werden kann, die eine kontinuierliche Konnektivität und eine längere Batterielebensdauer ermöglichen.

Der wachsende Bedarf an kontinuierlicher Dualmodus-Wi-Fi/Bluetooth-Konnektivität

Bluetooth-Konnektivität gilt als eine Standardanforderung für viele IoT-Geräte, die für die Interaktion mit Benutzern über Bluetooth-fähige Smartphones und andere mobile Geräte entwickelt wurden. Für viele IoT-Anwendungen benötigen IoT-Geräte jedoch eine Wi-Fi-Konnektivität, um auf ein drahtloses lokales Netzwerk (WLAN) zuzugreifen und direkt ins Internet zu gelangen oder um mit anderen Peer-Geräten und Host-Systemen im selben Netzwerk zu interagieren.

In vielerlei Hinsicht wäre es für die Entwickler viel einfacher, die Akkulaufzeit zu verlängern, wenn diese IoT-Geräte nur dann eine Verbindung zum WLAN- oder Bluetooth-Host herstellen müssten, wenn sie ihre Daten oder andere Nachrichten übertragen müssen. Da der aktive Arbeitszyklus für viele IoT-Bausteine typischerweise gering ist, könnten diese Bausteine die Batterielebensdauer verlängern, indem sie vorwiegend im Niedrigverbrauchs-Schlafmodus betrieben werden, lange genug aufwachen, um Sensormessungen durchzuführen, entsprechende Verarbeitungsaufgaben zu erledigen und die resultierenden Daten zu übertragen, bevor sie wieder in den Niedrigverbrauchsmodus zurückkehren. In Wirklichkeit müssen die meisten IoT-Geräte schnell auf asynchrone eingehende Befehle und Daten von Peer-Geräten, Hostsystemen und Endbenutzern reagieren.

Um reaktionsfähig zu bleiben, müssen IoT-Geräte den Anschein kontinuierlicher Konnektivität erwecken und auf eingehenden Datenverkehr aufmerksam bleiben, damit sie innerhalb einer akzeptablen Zeitspanne reagieren können. Wenn Entwickler versuchen, diese grundlegende Anforderung zu erfüllen, indem sie ihre Geräte wiederholt aufwecken, um eingehenden Datenverkehr zu empfangen, wird der Akku ihres Geräts schnell leer sein. Tatsächlich verbrauchen Funkempfänger in batteriebetriebenen Wi-Fi-Geräten im Laufe der Zeit typischerweise mehr Strom als Funksender, trotz des höheren Stromverbrauchs, der mit einem einzelnen Sendevorgang verbunden ist. Natürlich trägt die Leistung, die der Host-Prozessor des Geräts für seinen Teil bei jedem Empfangsvorgang verbraucht, zu einer erheblichen Belastung des Energiebudgets bei. Glücklicherweise definieren Wireless-Standards Protokolle, die es Entwicklern ermöglichen, den Stromverbrauch zu reduzieren und gleichzeitig die Illusion einer kontinuierlichen Konnektivität aufrechtzuerhalten.

Wie Wireless-Konnektivitätsstandards Geräte bei der Reduzierung des Stromverbrauchs unterstützen

Im Normalbetrieb sparen Wi-Fi-Empfangsstationen (STAs) Strom, indem sie den größten Teil ihres Wi-Fi-Subsystems abschalten. Da Access Points (APs) Pufferrahmen für schlafende STAs puffern, gehen keine Nachrichten verloren. Als Teil ihres normalen Netzwerkmanagements senden APs regelmäßig Baken aus, die eine Bitmap, eine so genannte Traffic Indication Map (TIM), enthalten, die anzeigt, ob der AP für jede STA wartenden Verkehr hat. APs senden auch periodisch eine Bake, die eine Delivery Traffic Indication Map (DTIM) enthält, welche die Verfügbarkeit von gepufferten Multicast- oder Broadcast-Daten anzeigt. Es wird erwartet, dass STAs innerhalb des DTIM-Periodenwertes, der ein gewisses Vielfaches des normalen Leuchtfeuerintervalls beträgt, regelmäßig aufwachen. Ein IoT-Netzwerk, das mit einem hohen DTIM-Periodenwert konfiguriert ist, würde es den Geräten in seinem Netzwerk ermöglichen, den Stromverbrauch zu reduzieren, da sie länger schlafen könnten, bevor sie ihren Empfänger wecken, um ein Signal zu empfangen, das anzeigt, dass der AP Frames für ihn hält. Dies ist der grundlegende Ansatz hinter dem Standard 802.11 Stromspar-Abstimmungsmechanismus, der weiter unten diskutiert wird.

Mit Bluetooth low energy (BLE) können Geräte den Stromverbrauch durch Optimierung der Bluetooth-Werbefrequenz und der Nutzlast senken. Durch Erhöhung des Werbeintervalls können IoT-Geräte den Senderbetrieb verzögern; durch Verringerung der Nutzlast können IoT-Geräte die Dauer von Senderereignissen verkürzen. Natürlich kann nicht jede Anwendung lange Werbeintervalle oder minimale Nutzlasten vertragen. In einem Audio- oder Echtzeiterfassungsgerät zum Beispiel bedeuten lange Werbeintervalle verzögerte Verbindungen, die das Verhalten der Anwendung als Ganzes beeinträchtigen könnten.

Peripheriegeräte können eine weitere BLE-Funktion namens Slave-Latenz nutzen, die es dem Peripheriegerät ermöglicht, Verbindungsereignisse zu überspringen. Wie beim Wi-Fi DTIM ermöglicht die BLE-Slave-Latenzzeit, dass Geräte über einen längeren Zeitraum im Energiesparmodus bleiben können. Anstatt einfach nur das Verbindungsintervall zu erhöhen, ermöglicht dieser spezielle Modus dem Peripheriegerät, Verbindungsereignisse mit einem Host zu überspringen, aber dennoch Daten bei Bedarf zu wecken und zu senden, ohne zusätzliche Latenzzeiten zu verursachen.

Unterstützung für Dual-Mode-Konnektivität und verlängerte Akkulaufzeit

Diese Methoden tragen dazu bei, die Dauer und Häufigkeit des Betriebs bei voller Leistung in Wi-Fi- und Bluetooth-Geräten zu reduzieren. Entwickler können jedoch viel mehr tun, um die Batterielebensdauer zu verlängern, indem sie die Hardware- und Software-Fähigkeiten nutzen, die im Cypress Semiconductor CY8CKIT-062S2-43012 Wi-Fi BT Pioneer Kit demonstriert werden. Das Cypress-Kit enthält neben Überbrückungsdrähten und einem USB-Kabel das Wi-Fi BT Pioneer-Board PSoC 62S2 Wi-Fi BT, das eine umfassende Entwicklungsplattform und ein voll funktionsfähiges Hardwaresystem zur Implementierung von IoT-Designs mit geringem Stromverbrauch bietet. In Verbindung mit der Cypress-Software ermöglicht das Cypress-Kit Entwicklern die sofortige Evaluierung und den schnellen Einsatz einer Vielzahl von hochentwickelten Energieverwaltungsfunktionen.

Neben mehreren Schnittstellen-Steckverbindern, Tasten und LEDs ist auf der Platine des Kits ein CY8C5868LTI-LP038 PSoC 5LP Baustein integriert, der Cypress KitProg3 Onboard-Programmierung und -Debugging ermöglicht. Für zusätzlichen Onboard-Speicher integriert Cypress seinen S25FL512S 512 Megabit (Mbit) seriellen NOR-Flash-Speicherbaustein und seinen CY15B104 4 Mbit seriellen ferroelektrischen Direktzugriffsspeicher (FRAM) (Abbildung 1).

Diagramm des PSoC 62S2 Wi-Fi BT Pioneer-Boards von Cypress PSoC 62S2 (zum Vergrößern anklicken)Abbildung 1: Das Cypress PSoC 62S2 Wi-Fi BT Pioneer Board bietet eine umfassende Reihe von Systemfunktionen, die um ein Trägermodul herum aufgebaut sind, das einen PSoC 6 Mikrocontroller und ein drahtloses Wi-Fi/Bluetooth-Verbindungsmodul integriert. (Bildquelle: Cypress Semiconductor)

Im Herzen der Baugruppe integriert ein Trägermodul einen Mikrocontroller von Cypress Semiconductor PSoC 6 und einen Mikrocontroller Murata Electronics Type 1LV LBEE59B1LV Wireless-Konnektivitätsmodul mit passiven Komponenten. Ein Radiofrequenz (RF)-Schalter und eine Dual-Band 2,45 Gigahertz (GHz)/5 GHz Mini-Chip-Antenne runden die unterstützenden Geräte ab.

Das PSoC 6 wurde speziell entwickelt, um den konventionellen Kompromiss zwischen Rechenleistung und Stromverbrauch zu eliminieren. Der PSoC 6 integriert einen 150 Megahertz (MHz) Arm® Cortex®-M4, der als primärer Anwendungsprozessor dient, und einen 100 MHz-Arm Cortex-M0+, der einen Betrieb mit geringem Stromverbrauch ermöglicht. Neben integriertem Flash und statischem RAM (SRAM) umfasst das PSoC6 eine Kryptographie-Engine, programmierbare analoge und digitale Peripheriegeräte, CapSense-Touch-Sensing-Unterstützung und mehrere Systemschnittstellen (Abbildung 2).

Diagramm des Trägermoduls des PSoC 62S2 Wi-Fi BT Pioneer-Boards von Cypress PSoC 62S2 (zum Vergrößern anklicken)Abbildung 2: Ein PSoC 6-Mikrocontroller, der in das Trägermodul des Cypress PSoC 62S2 Wi-Fi BT Pioneer-Boards eingebaut ist, verwendet eine Multicore-Architektur, um sowohl die Anforderungen an die Anwendungsverarbeitung als auch an die stromsparende Echtzeitausführung zu erfüllen. (Bildquelle: Cypress Semiconductor)

Das Murata LBEE59B1LV-Modul bietet ein komplettes Funksubsystem in einem 10,0 x 7,2 x 1,4 Millimeter (mm) großen Gehäuse, das ein Cypress CYW43012 Wireless Internet Connectivity for Embedded Devices (WICED) Wi-Fi + Bluetooth-Gerät, einen Referenztaktgeber und Filter enthält (Abbildung 3).

Diagramm des drahtlosen Murata Typ 1LV LBEE59B1LV-VerbindungsmodulsAbbildung 3: Das drahtlose Verbindungsmodul Murata Type 1LV LBEE59B1LV bietet ein vollständiges, vorzertifiziertes Wi-Fi + Bluetooth-Funksubsystem, das um ein Cypress CYW43012 WICED-Gerät herum aufgebaut ist. (Bildquelle: Murata Electronics)

Das Modul unterstützt 2,4 GHz und 5 GHz drahtlose Konnektivität mit Bluetooth 5.0 und Wi-Fi 802.11a/b/g/n. Darüber hinaus bietet das Modul einen 802.11ac-freundlichen Modus, der die 256-Quadratur-Amplitudenmodulation (QAM) von 802.11ac für die 20-MHz-Kanäle im 5-GHz-Band unterstützt und damit einen höheren Durchsatz und eine geringere Energie pro Bit bietet als reine 802.11n-Produkte. Das Murata LBEE59B1LV-Modul wurde entwickelt, um die Entwicklung zu beschleunigen, und ist in mehreren Regionen vorzertifiziert, so dass die mit Konformitätsprüfungen und Zertifizierungen verbundenen langen Verzögerungen entfallen.

Innerhalb des Moduls integriert das Cypress WICED-Gerät einen Arm Cortex-M3-Prozessor und einen Arm Cortex-M4-Prozessor in die Wi-Fi- bzw. Bluetooth-Subsysteme. Obwohl er nicht für Kundencode verfügbar ist, läuft auf dem Arm Cortex-M3-Prozessor die Cypress-Firmware, die Wi-Fi-Operationen und zusätzliche Funktionen, einschließlich der unten beschriebenen Offload-Funktionalität, unterstützt. Der Arm Cortex-M4 im Bluetooth-Subsystem führt Bluetooth-Controller-Firmware, Bluetooth-Stack und Profile aus. Darüber hinaus kann dieser Kern Kundencode ausführen, der mit dem Software-Entwicklungskit Cypress WICED (SDK) programmiert wurde.

Verwendung von Stromsparmethoden in drahtlosen IoT-Designs

Das PSoC 6 und das Wireless-Konnektivitätsmodul wurden zur Minimierung des Stromverbrauchs entwickelt und verfügen über einen umfassenden Satz von Leistungsmodi und Leistungsreduzierungsfunktionen. Cypress unterstützt diese stromsparende Hardware-Plattform mit einer umfangreichen Software-Ergänzung, die den Einsatz von Stromsparmethoden in drahtlosen IoT-Designs vereinfachen soll. Beispielsweise können Entwickler die oben erwähnte stromsparende Abfragemethode leicht implementieren, indem sie die unabhängige eingebettete Wi-Fi-Host-Treiber (WHD)-Bibliothek verwenden.

Entwickler rufen einfach die WHD Application Programming Interface (API)-Funktion whd_wifi_enable_powersave() auf, um die Stromspar-Abfrage zu aktivieren und whd_wifi_disable_powersave(), um sie später im Gerät zu deaktivieren. Wenn sie aktiviert ist, teilt die STA dem AP mit, dass sie sich schlafen gelegt hat. Wie bereits erwähnt, puffert der AP alle Frames, die für die schlafende STA bestimmt sind, und konfiguriert sein periodisches Leuchtfeuer so, dass es anzeigt, dass Frames verfügbar sind. Wenn die STA aufwacht, um die Bake zu überprüfen, beginnt sie einen Standardprozess, um diese Frames abzurufen.

Obwohl der Energiespar-Abstimmungsmechanismus für STAs mit niedrigen Arbeitszyklen vorgesehen ist, unterstützt eine ähnliche Methode, die als Energiesparen ohne Abfrage bezeichnet wird, STAs mit höheren Durchsatzanforderungen. Hier überträgt die STA einen Datenrahmen mit Nullfunktion, der den Rahmentransfer vom AP initiiert.

Energiesparabfrage und Energiesparen ohne Abfrage ermöglichen es den Geräten, den Empfängerbetrieb zu reduzieren, tragen aber nicht dazu bei, unnötige Transaktionen im Zusammenhang mit dem Overhead des Netzwerkbetriebs zu vermeiden. Beispielsweise wird jedes Netzwerk, einschließlich eines IoT-WLAN, unerwünschten Paketverkehr übertragen, wenn es mit einem externen Netzwerk, insbesondere dem öffentlichen Internet, verbunden ist. Die Fähigkeit, diese Pakete innerhalb des Kommunikations-Subsystems herauszufiltern, ohne den Host-Prozessor des IoT-Geräts einzubeziehen, würde es dem Host-Prozessor ermöglichen, im energiesparenden Schlafmodus zu bleiben.

Neben unerwünschten Paketen kann legitimer Netzwerkverkehr dazu führen, dass der Host-Prozessor unnötig aufwacht. Beispielsweise verwendet das Wi-Fi-Standard-Adressauflösungsprotokoll (ARP) Broadcast-Pakete als Teil seiner Funktion, um eine IP-Adresse, die einem Gerät zugeordnet ist, auf die MAC-Adresse (Media Access Control) des Geräts abzubilden. Dieser Vorgang ist für die normale WLAN-Funktion unerlässlich, da er es den Geräten ermöglicht, andere in ihrem Netzwerk zu erreichen, doppelte IP-Adressen zu erkennen und andere Geräte zu benachrichtigen, wenn eine IP-Adresse aus irgendeinem Grund geändert wird.

ARP-Anfrage- und Antwortpakete sind so grundlegend für den Netzwerkbetrieb, dass der Host-Prozessor eines IoT-Geräts schon bei der Verarbeitung von ARP-Anfragen und -Antworten überlastet werden kann. Wenn die WLAN-Schnittstelle des Geräts lediglich Anfragen und Antworten zwischen dem Host und dem Netzwerk weiterleitet, weckt jede ARP-Anfrage den Host auf, was manchmal unnötig ist.

Im Gegensatz dazu greift das Murata-Modul für drahtlose Verbindungen in diesen Austausch ein und entlastet den PSoC 6-Mikrocontroller von der Bearbeitung von ARP-Anfragen. Wenn das PSoC 6 anderweitig mit seiner primären IoT-Anwendungsfunktionalität beschäftigt ist, bewahrt diese Fähigkeit die Prozessorzyklen für die Anwendungsausführung. Wenn sich das PSoC 6 im Sleep-Modus befindet, trägt diese Fähigkeit dazu bei, den Stromverbrauch der IoT-Geräte insgesamt zu reduzieren. Durch die Aktivierung von ARP-Offload mit Peer-Auto-Antwort weckt das Murata-Modul das PSoC 6 nur dann auf, wenn eine eingehende ARP-Anforderung nicht durch Einträge befriedigt werden kann, die im Murata-Modul zwischengespeichert sind (Abbildung 4, links).

Diagramm des ARP-Offloading fängt ARP-Anforderungen aus dem Netzwerk oder vom Host-Prozessor ab (zum Vergrößern anklicken)<Abbildung 4: Wenn aktiviert, fängt ARP offloading ARP-Anforderungen aus dem Netzwerk (links) oder vom Host-Prozessor (rechts) ab, antwortet automatisch, wenn der Cache die Anforderung erfüllt (oben) und weckt den Prozessor nur bei Cache-Fehlversuchen auf (unten). (Bildquelle: Cypress Semiconductor)

Derselbe Ansatz kann auch zur Senkung des WLAN-Stromverbrauchs beitragen. Im normalen Betrieb kann das Murata-Modul den Netzwerkverkehr überwachen (snoop) und IP:MAC-Paare aus anderen ARP-Antworten zwischenspeichern. Mithilfe der Host-Auto-Antwort kann das Murata-Modul auf ARP-Anfragen vom PSoC 6 antworten und sein Funksubsystem nur dann aufrufen, wenn die Anfrage des PSoC 6 nicht aus dem ARP-Cache befriedigt werden kann (Abbildung 4, rechts).

Einfache menübasierte Implementierung von Energiesparfunktionen

Die Durchführung der ARP-Entladung mit dem Pioneer-Kit ist bemerkenswert einfach. Das in der integrierten Entwicklungsumgebung (IDE) Cypress ModusToolBox (MTB) enthaltene Werkzeug Cypress Device Configurator ermöglicht es Entwicklern, diese Fähigkeit mit einigen wenigen Menüauswahlen einzusetzen. Cypress stellt vorgefertigte Konfigurationsdateien zur Verfügung, die es Entwicklern ermöglichen, schnell verschiedene Konfigurationen einschließlich ARP-Offloading auszuwählen.

Die Verwendung des Gerätekonfigurator-Tools zur expliziten Definition von Konfigurationen ist fast ebenso einfach. Entwickler verwenden die Menüoptionen des Tools, um den Host-Wake-Pin zu aktivieren, den Pin zu benennen (CYBSP_WIFI_HOST_WAKE) und die Pin-Parameter einzustellen (Abbildung 5).

Bild des Cypress Device Configurator-Werkzeugs (zum Vergrößern anklicken)Abbildung 5: Mit dem Cypress Device Configurator Tool können Entwickler über Menüs die Energiesparoptionen einstellen, die mit dem Pioneer-Board verfügbar sind. (Bildquelle: Cypress Semiconductor)

Auf der Wi-Fi-Registerkarte des Tools aktivieren die Entwickler die Host-Wake-Funktion und setzen den Interrupt-Pin auf den zuvor eingegebenen Namen (CYBSP_WIFI_HOST_WAKE). Zusätzliche Menüeinträge aktivieren das ARP-Offloading, stellen die Funktion auf Peer-Auto-Antwort ein, aktivieren Netzwerk-Snooping und legen die Ablaufzeit für Cache-Einträge fest (Abbildung 6).

Abbildung der zusätzlichen Menü-Registerkarten im Cypress Device Configurator-Werkzeug<Abbildung 6: Mit Hilfe zusätzlicher Menüregisterkarten im Cypress Device Configurator-Tool können Entwickler das ARP-Offloading und spezielle Funktionen wie die Peer-Auto-Antwort aktivieren. (Bildquelle: Cypress Semiconductor)

Nach dem Speichern der Konfiguration generieren die Entwickler einfach Quelldateien, bauen das modifizierte Projekt auf und programmieren das Pioneer-Board. Mit einem ähnlichen Verfahren können Entwickler das Murata-Modul so konfigurieren, dass die Wi-Fi-Paketfilterung ausgelagert und andere gängige Arten von Netzwerkoperationen durchgeführt werden können. Derselbe Ansatz ermöglicht es einem IoT-Gerät sogar, das für die Aufrechterhaltung der Wi-Fi-Konnektivität erforderliche Wi-Fi-TCP Keep-Alive-Protokoll auszuführen, ohne den IoT-Host-Prozessor zu wecken.

Im normalen WLAN-Betrieb unterhalten ein Client-Gerät und ein Host-Server TCP-Verbindungen durch den Austausch von Keep-Alive-Paketen. Wenn eine Seite dieses Austauschs nach einigen Versuchen keine Antwort erhält, bricht sie die Verbindung ab. Sogar in IoT-Geräten mit begrenzter Leistung muss der Host-Prozessor ständig aufwachen, um an diesem Austausch teilzunehmen, oder sogar noch mehr Leistung verbrauchen, um ständig neue Verbindungen herzustellen.

Wie beim ARP-Offloading können Entwickler das Tool Device Configurator verwenden, um das TCP Keep Alive Offloading zu aktivieren. Sobald diese Funktion aktiviert ist, führt das Murata-Modul automatisch das Keep-Alive-Protokoll aus, ohne das PSoC 6 aufzuwecken (Abbildung 7).

Diagramm eines WLAN-Geräts, das automatisch das Keep-Alive-Protokoll durchführt (zum Vergrößern anklicken)Abbildung 7: Wenn TCP Keep-Alive-Offload aktiviert ist, führt das Wireless-Konnektivitätsmodul (WLAN-Gerät) automatisch das Keep-Alive-Protokoll aus, wodurch der Host-Prozessor im energiesparenden Ruhezustand verbleiben kann. (Bildquelle: Cypress Semiconductor)

Obwohl Cypress die Verwendung des Gerätekonfigurators als einfachsten Weg zur Implementierung empfiehlt, können Entwickler die Energiesparfunktionen der Cypress-Plattform, einschließlich ARP-Offloading, Paketfilterung, TCP Keep Alive Offloading und andere, auch manuell implementieren.

Beiden Ansätzen liegt die Low Power Assistant (LPA)-Middleware von Cypress zugrunde, die diese Stromsparfunktionen für Wi-Fi, Bluetooth und den Mikrocontroller PSoC 6 sowie weitere, über die hier genannten hinausgehende Funktionen unterstützt.

Nachdem der Entwickler Konfigurationen über Menüs oder durch manuelles Hinzufügen von Konfigurationscode definiert hat, arbeitet die LPA-Firmware für die Anwendung transparent und orchestriert automatisch die Verwendung von Hardware-Funktionen und Software-Fähigkeiten mit geringem Stromverbrauch.

Fazit:

Der Bedarf an kontinuierlicher drahtloser Konnektivität und verlängerter Akkulaufzeit in IoT-Geräten stellt widersprüchliche Anforderungen an Designer, die durch die Notwendigkeit, sowohl Wi-Fi als auch Bluetooth zu unterstützen, nur noch verschärft werden. Wie gezeigt, ermöglicht das Wi-Fi BT Pioneer Kit von Cypress Semiconductor CY8CKIT-062S2-43012 Wi-Fi Pioneer Kit von Cypress Semiconductor durch die Kombination eines Funksubsystems, das in der Lage ist, Netzwerkverarbeitungsaufgaben zu entlasten, mit einem Low-Power-Mikrocontroller, Designern die Erfüllung ihrer IoT-Wireless-Konnektivitäts- und Low-Power-Anforderungen.

DigiKey logo

Haftungsausschluss: Die Meinungen, Überzeugungen und Standpunkte der verschiedenen Autoren und/oder Forumsteilnehmer dieser Website spiegeln nicht notwendigerweise die Meinungen, Überzeugungen und Standpunkte der DigiKey oder offiziellen Politik der DigiKey wider.

Über den Autor

Image of Stephen Evanczuk

Stephen Evanczuk

Stephen Evanczuk hat mehr als 20 Jahre Erfahrung im Schreiben für und über die Elektronikindustrie zu einem breiten Spektrum von Themen wie Hardware, Software, Systeme und Anwendungen einschließlich des IoT. Er promoviertein Neurowissenschaften über neuronale Netzwerke und arbeitete in der Luft- und Raumfahrtindustrie an massiv verteilten sicheren Systemen und Methoden zur Beschleunigung von Algorithmen. Derzeit, wenn er nicht gerade Artikel über Technologie und Ingenieurwesen schreibt, arbeitet er an Anwendungen des tiefen Lernens (Deep Learning) zu Erkennungs- und Empfehlungssystemen.

Über den Verlag

Nordamerikanische Fachredakteure von DigiKey