Risparmio energia Bluetooth per piattaforme standby moderne

Un dispositivo radio Bluetooth consente la comunicazione RF a corto raggio tra un PC e un dispositivo di input, un dispositivo audio o altre periferiche utente collegate tramite Bluetooth. In un PC di standby moderno, il driver per una radio Bluetooth deve gestire gli stati di alimentazione del dispositivo in base alle linee guida presentate in questo articolo.

Radio Bluetooth

In un sistema Windows, il modo in cui lo stato di alimentazione del dispositivo radio Bluetooth viene gestito dipende dal bus a cui è connessa la radio. Nelle piattaforme hardware che supportano il modello di alimentazione standby moderno, Windows supporta le radio Bluetooth connesse a UART o al bus seriale universale (USB). (In teoria, il modello di driver del bus di trasporto Bluetooth introdotto in Windows 8 dovrebbe supportare qualsiasi bus di comunicazione sottostante. Attualmente, Microsoft verifica la compatibilità di standby moderna solo per le radio Bluetooth connesse a UART o USB o sono integrate in un sistema su un chip (SoC).

Proprio come nei tipici stack di driver di Windows, i criteri di alimentazione radio Bluetooth vengono gestiti da un singolo proprietario dei criteri di alimentazione (PPO), in particolare BthPort (bthport.sys). BthPort funziona in combinazione con un driver specifico del trasporto (UART o USB) corrispondente per guidare in modo appropriato la radio nello stato di alimentazione desiderato. Nel caso di USB, questa operazione viene eseguita tramite la sospensione selettiva USB tramite il controller host USB. Nel caso di UART, un driver del bus di trasporto fornito da un fornitore aggiuntivo coordina le richieste da BthPort al dispositivo radio Bluetooth tramite la connessione bus specifica del sistema. Per controllare l'hardware, il driver usa una combinazione di comunicazione tra bus in banda, coordinamento con il plug-in del motore di alimentazione (PEP) e/o segnalazione fuori banda tramite pin GPIO.

I dispositivi radio Bluetooth supportano in genere più modalità a basso consumo, alcune delle quali possono essere proprietarie del dispositivo stesso. Lo stack di driver Bluetooth di Windows richiede che una radio Bluetooth supporti i tre stati di alimentazione del dispositivo seguenti:

• Attivo (D0)
• Sospensione (D2)
• Off (D3)

Il risparmio energia del dispositivo per una radio Bluetooth dovrebbe funzionare in modo coerente in tutti gli stati di alimentazione del sistema. La radio Bluetooth non entra in una modalità di risparmio energia speciale quando il sistema entra in standby moderno. Al contrario, la radio Bluetooth viene passata e fuori dallo stato Sospensione (D2) in base ai timeout di inattività gestiti da BthPort. Per supportare la riattivazione dallo standby moderno nei dispositivi di input HID collegati tramite Bluetooth, la radio rimane nello stato Sospensione (D2) ed è armato per la riattivazione. Solo il dispositivo BLUETOOTH HID associato può riattivare il sistema durante lo standby moderno. La radio Bluetooth dovrebbe avere un consumo di energia molto basso, inferiore a un milliwatt, nello stato sospensione (D2) se nessun dispositivo è connesso tramite collegamenti RF. Il consumo energetico può variare in base al numero di dispositivi associati, ai tipi di tali dispositivi e ai relativi modelli di attività.

La radio Bluetooth deve supportare anche la possibilità di disattivare la radio tramite l'interfaccia utente di gestione radio. Questo controllo dell'interfaccia utente è integrato in Windows. Dopo la disattivazione della radio Bluetooth tramite questa interfaccia utente, la radio viene passata allo stato di alimentazione Off (D3), in cui si prevede di consumare quasi zero watt.

Le versioni precedenti di Windows, tra cui Windows 8 e Windows 8 RT, richiedono al fornitore del dispositivo Bluetooth di fornire una DLL di controllo radio. Tuttavia, a partire da Windows 8.1 e Windows RT 8.1, tutte le radio Bluetooth nelle piattaforme di standby moderne devono supportare la specifica Bluetooth Core versione 4.0. Di conseguenza, i fornitori non sono più tenuti a fornire una DLL software per implementare la funzione di controllo radio on/off. Windows ora gestisce questa funzione e ignorerà qualsiasi DLL di questo tipo, anche se presente.

Modalità di risparmio energia

Dal punto di vista software, la radio Bluetooth supporta tre modalità di risparmio energia, indipendentemente dall'autobus a cui è connessa la radio. Il driver Bluetooth di Windows possiede la definizione delle tre modalità e gestisce le transizioni in e fuori di queste modalità. La tabella seguente descrive le tre modalità di alimentazione radio Bluetooth.

Mode	Descrizione	Stato di alimentazione del dispositivo (Dx)	Consumo medio di energia elettrica	Uscire dalla latenza per l'attività	Meccanismo di transizione
Attivo	La radio Bluetooth comunica attivamente con un dispositivo associato per conto di un'applicazione nel sistema operativo.	D0	Varia, specifica dello scenario e dei dispositivi associati.	N/D	N/D
Sonno (per lo più inattivo con un ciclo di servizio a bassa velocità)	La radio Bluetooth è in uno stato a basso consumo. Il sistema è stato associato a un dispositivo Bluetooth remoto, ma non c'è connessione tra i due. Ovvero, il dispositivo è stato disconnesso. Il controller Bluetooth deve essere in grado di generare un segnale di riattivazione (per il SoC se la radio non è integrata) quando arrivano nuovi dati dal dispositivo associato. In alternativa, la radio Bluetooth non ha associazioni. In alternativa, la radio Bluetooth ha una connessione attiva inattiva (nessun dato inviato/ricevuto) e il collegamento è in modalità di analisi.	D2	< 4 milliwatt	< 100 millisecondi	Il driver Bluetooth di Windows avvia una transizione D2 usando un IRP di alimentazione D2. Il driver Bluetooth di Windows avvia un IRP di attesa in sospeso nel driver del bus di trasporto sottostante. Se il dispositivo Bluetooth è collegato tramite USB, questo stato equivale alla sospensione selettiva. La sospensione selettiva Bluetooth richiede che il dispositivo sia contrassegnato come abilitato per la riattivazione remota e autouso nel descrittore del dispositivo USB.
Off	La radio Bluetooth è completamente disattivata (zero watt) o in uno stato di bassa potenza in cui non viene mantenuto alcuno stato radio. La radio Bluetooth non è in grado di generare un segnale di riattivazione al SoC in questo stato. La radio Bluetooth non è inoltre in grado di emettere o ricevere segnali radio, tutti i componenti RF sono spenti.	D3	0 watt	< 2 secondi	Il driver Bluetooth di Windows avvia una transizione D3 usando un IRP di alimentazione D3. Il firmware ACPI del bus di trasporto può rimuovere l'alimentazione o attivare o disattivare le linee GPIO per trasferire l'hardware radio Bluetooth allo stato Off (D3).

La radio Bluetooth supporta anche una modalità associata in cui il trasmettitore radio può essere spento dal software in risposta a una richiesta dell'utente. Quando la radio è abilitata per il dispositivo Bluetooth, questo dispositivo si trova nello stato Attivo (D0) o Sospensione (D2). Quando la radio per il dispositivo Bluetooth è disabilitata dall'utente, Windows arresta l'attività Bluetooth rimuovendo a sorpresa i driver di protocollo e i relativi figli e quindi passando lo stack di dispositivi radio allo stato Off (D3).

Meccanismi di risparmio energia software

Il risparmio energia di un dispositivo radio Bluetooth è basato sulle transizioni di stato Dx del dispositivo avviate da BthPort come proprietario dei criteri di alimentazione (PPO). Il PPO decide quando il dispositivo passa tra gli stati Attivo (D0), Sospensione (D2) e Off (D3).

Quando la radio non dispone di dispositivi associati, Windows passa il dispositivo a D2 e lo rende persistente in tale stato fino a quando l'utente non avvia il processo di associazione. Quando la radio è associata a uno o più dispositivi, il driver Bluetooth di Windows usa un timeout di inattività per decidere quando eseguire la transizione della radio Bluetooth da D0 a D2. Questo algoritmo usa il modello di utilizzo Bluetooth da parte del sistema operativo e delle applicazioni per determinare quando eseguire la transizione della radio allo stato D2. Ad esempio, la radio passa a D2 diversi secondi dopo l'ultimo tasto premuto su una tastiera Bluetooth se non sono presenti altre attività sulla radio Bluetooth.

Il driver Bluetooth di Windows esegue la transizione del dispositivo a D0 in risposta a una delle operazioni seguenti:

• L'utente avvia un processo di associazione.
• Un'applicazione richiede l'uso della funzionalità Bluetooth.
• La radio Bluetooth ha generato una richiesta di riattivazione in base all'input di un dispositivo associato.

A differenza di altri dispositivi, la radio Bluetooth segue lo stesso modello di risparmio energia durante lo standby moderno (schermo di sistema disattivato) che esegue quando il sistema è normalmente operativo e lo schermo è acceso. Ciò è dovuto al fatto che la radio Bluetooth dovrebbe essere disponibile per riattivare il SoC quando l'input viene ricevuto da un dispositivo associato in qualsiasi momento durante lo standby moderno. Ad esempio, se un utente ha associato una tastiera Bluetooth a un computer Windows, premere un tasto sulla tastiera dovrebbe riattivare il computer dallo standby moderno e attivare lo schermo.

Se nessun dispositivo è associato alla radio, è previsto che la radio sia configurata per utilizzare meno di un milliwatt quando si trova nello stato Sospensione (D2).

Quando la radio Bluetooth è nello stato Off (D3), si prevede di consumare quasi zero watt.

Note sull'implementazione del driver

Se la radio Bluetooth è connessa tramite un UART o integrata nel SoC stesso, il fornitore del dispositivo Bluetooth deve implementare e fornire un driver del bus di trasporto. L'autista del bus di trasporto è responsabile dei seguenti:

• Conversione delle richieste di pacchetti Bluetooth HCI dal driver Bluetooth Di Windows (Bthmini.sys) ai comandi inviati tramite il bus di trasporto alla radio Bluetooth.
• Transizione del dispositivo radio Bluetooth in varie modalità di risparmio energia che eseguono il mapping agli stati di alimentazione del dispositivo Attivo (D0), Sospensione (D2) e Off (D3). Il driver implementa anche routine che gestiscono gli eventi di risparmio energia.
• Configurazione della radio Bluetooth per riattivare il SoC quando un dispositivo genera l'input e modifica lo stato di qualsiasi riga GPIO facoltativa dal SoC alla radio Bluetooth usata per il risparmio energia.
• Enumerazione e gestione alimentazione di altri dispositivi (ad esempio un trasmettitore FM o un dispositivo GPS) che condividono lo stesso bus della radio Bluetooth. Se altri dispositivi sono fisicamente connessi al bus condiviso, ma non sono esposti al sistema operativo, il driver del bus di trasporto deve spegnere completamente questi dispositivi.

Per informazioni dettagliate sull'implementazione di un driver del bus di trasporto, vedere Transport Bus Driver for Bluetooth Power Control Handling Guidelines .For details about implement a transport bus driver, see Transport Bus Driver for Bluetooth Power Control Handling Guidelines. I driver dei bus di trasporto devono essere scritti con Windows Driver Framework (WDF). Un driver di esempio è disponibile in Driver bus HCI seriale Bluetooth.

Per abilitare il risparmio energia radio Bluetooth, il conducente del bus di trasporto deve eseguire le azioni seguenti:

• Abilitare il supporto per il risparmio energia inattivo in fase di esecuzione ed esporre il supporto per gli stati di alimentazione del dispositivo Active (D0), Sleep (D2) e Off (D3).
• Indicare al driver Bluetooth Windows che il dispositivo radio Bluetooth è in grado di segnalare gli eventi di riattivazione dallo stato D2.
• Supportare il braccio del dispositivo radio Bluetooth per riattivare il SoC e disarmare il segnale di riattivazione del dispositivo Bluetooth al SoC. Questo supporto potrebbe richiedere la gestione di uno o più interrupt GPIO ed esecuzione di metodi di riattivazione all'interno di WDF.
• Modificare lo stato di tutte le righe GPIO facoltative dal SoC al dispositivo radio Bluetooth quando il dispositivo passa tra gli stati Attivo (D0), Sospensione (D2) e Off (D3).

Se la radio Bluetooth è integrata nel SoC stesso, il driver del bus di trasporto può registrarsi con il framework di risparmio energia di Windows per comunicare lo stato di alimentazione della radio Bluetooth a un plug-in del motore di alimentazione (PEP) specifico di SoC. A tale scopo, impostare il membro IdleTimeoutType della struttura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS sul valore SystemManagedIdleTimeout.

Se la radio Bluetooth è connessa tramite USB, è necessario usare lo stack di driver Bluetooth USB predefinito. Lo stack gestisce tutte le operazioni di risparmio energia.

Gestione radio

Lo stato del trasmettitore radio Bluetooth è collegato direttamente allo stato di alimentazione del dispositivo. Il trasmettitore radio dovrebbe essere acceso quando la radio si trova nello stato di alimentazione Attivo (D0) o Sospensione (D2). Il trasmettitore radio deve essere disattivato quando la radio passa allo stato Off (D3).

Quando l'utente disattiva la radio Bluetooth, Windows termina l'attività Bluetooth annullando le operazioni di I/O in sospeso e scaricando i driver di protocollo e i relativi figli. Lo stack di driver Bluetooth di Windows invia quindi il comando HCI_Reset al controller per reimpostare lo stato predefinito della radio. Nello stato predefinito, il controller non deve essere in grado di trasmettere o ricevere segnali radio. Infine, il controller passa allo stato Off (D3).

In risposta alla transizione a Off (D3), il conducente del bus di trasporto deve spegnere il dispositivo Bluetooth allo stato di alimentazione più basso usando metodi specifici del dispositivo. Un'implementazione tipica consiste nel modificare lo stato di una linea GPIO dal SoC alla radio Bluetooth per disabilitare l'alimentazione al modulo Bluetooth. Un'implementazione alternativa consiste nel richiedere al firmware ACPI di rimuovere l'alimentazione dal modulo Bluetooth usando _PS0 e _PS3 metodi di controllo.

Quando l'utente attiva la radio Bluetooth, Windows passa la radio allo stato Attivo (D0), inizializza nuovamente la radio e quindi enumera nuovamente i driver del protocollo figlio. Quando la radio passa ad Active (D0), tutte le linee GPIO necessarie devono essere attivate come parte della normale sequenza D0 per la radio Bluetooth. Se il firmware ACPI è stato utilizzato per spegnere la radio, deve ripristinare l'alimentazione utilizzando il metodo di controllo _PS0.

Come parte di questa normale sequenza, il driver del bus di trasporto deve contrassegnare il dispositivo come dispositivo connesso internamente impostando ContainerId della radio Bluetooth su un valore GUID specifico, {00000000-0000-000-000-ffffff-ffffffffffff}. In questo modo gli elementi dell'interfaccia utente radio di Windows possono rilevare che la radio Bluetooth esposta dal driver del bus di trasporto è interna al computer e non una radio collegata esternamente per cui il controllo radio non è appropriato.

Configurazioni di alimentazione hardware supportate

La configurazione hardware di risparmio energia per una radio Bluetooth dipende dal bus di comunicazione. In generale, tutte le radio Bluetooth dovrebbero avere le seguenti funzionalità di risparmio energia hardware in comune:

• Supporto per lo stato Off (D3) come mezzo per disattivare la radio in risposta a una richiesta dell'utente. La disattivazione della radio mette la radio Bluetooth in uno stato di bassa potenza che è quasi zero watt.
• Un meccanismo per entrare in uno stato di sospensione a basso consumo (D2) in cui le connessioni vengono mantenute nei dispositivi associati, ma non sono presenti trasferimenti attivi.
• Un meccanismo per generare un interrupt di riattivazione quando un dispositivo associato dispone di dati per il SoC e il SoC è in uno stato a basso consumo in cui il bus a cui è collegato il dispositivo radio Bluetooth non è attualmente attivo.

Ognuno dei bus supportati (USB, UART e integrazione nel SoC) per il dispositivo radio Bluetooth supporta tutte e tre le funzionalità di risparmio energia hardware di base nell'elenco precedente. Inoltre, ogni radio Bluetooth può avere funzionalità di risparmio energia specifiche del fornitore o specifiche del dispositivo, ma non rientrano nell'ambito di questo argomento.

I fornitori di radio Bluetooth sono invitati a implementare funzionalità di risparmio energia a valore aggiunto in modo autonomo nell'hardware e non richiedono software driver aggiuntivo fornito dal fornitore nel sistema Windows. Inoltre, i fornitori di radio Bluetooth sono invitati a implementare i driver e il software di risparmio energia in modo da astrarre le differenze specifiche della piattaforma nel firmware ACPI di sistema anziché nel codice del driver di dispositivo o nel file con estensione inf del driver. Questo approccio consente di usare nuovamente un pacchetto driver per il dispositivo Bluetooth in piattaforme aggiuntive senza richiedere un aggiornamento all'origine driver, al pacchetto binario o firmato.

Radio Bluetooth connessa tramite UART all'esterno del SoC

Se la radio Bluetooth è connessa tramite un UART e si trova fisicamente all'esterno del SoC, il fornitore della radio Bluetooth deve fornire un driver del bus di trasporto che espone la radio Bluetooth e qualsiasi altra funzione del dispositivo (ad esempio, una radio FM) che condividono lo stesso percorso di comunicazione tramite UART. Il conducente del bus è anche responsabile della gestione di tutte le risorse GPIO che controllano il consumo di energia e la riattivazione della radio Bluetooth.

A differenza di altre classi di dispositivi, le linee GPIO che controllano l'alimentazione e la riattivazione Bluetooth vengono gestite direttamente dal conducente del bus di trasporto invece di essere astratte dai metodi di controllo ACPI. Questo schema di controllo è il risultato della progettazione del driver bus multifunzione che enumera la radio Bluetooth e altre funzioni che condividono la stessa porta UART. In questa progettazione, il driver ACPI di Windows, Acpi.sys, non viene caricato negli stack di driver per Bluetooth e la radio FM, rendendo impossibile utilizzare l'esecuzione del metodo di controllo ACPI come modo per rispondere a una transizione di stato Dx del dispositivo.

Quando la radio Bluetooth è connessa alla porta UART sul SoC, l'integratore di sistema deve usare un pin sul controller GPIO sul SoC per controllare l'alimentazione alla radio. Nel firmware ACPI questo pin deve essere assegnato come risorsa I/O GPIO all'oggetto dispositivo che rappresenta il dispositivo radice del driver del bus di trasporto. Il pin GPIO può essere collegato direttamente alla radio Bluetooth se la radio supporta la disattivazione del dispositivo con controllo di alimentazione interna.

Se la radio Bluetooth supporta il controllo dell'alimentazione, la fonte di alimentazione per la radio Bluetooth può essere connessa a qualsiasi guida di alimentazione del sistema.

Se la radio non supporta l'alimentazione interna controllata da un pin GPIO, l'integratore di sistemi deve posizionare la radio Bluetooth su una guida di alimentazione che è commutabile. Il pin GPIO dal SoC viene quindi connesso all'hardware del commutatore di alimentazione. In questa progettazione, i metodi di controllo ACPI non possono essere utilizzati per tenere traccia dei conteggi dei riferimenti o per aggregare lo stato di alimentazione di più dispositivi che condividono la stessa guida di alimentazione, quindi la radio Bluetooth deve essere isolata sulla propria guida di alimentazione commutabile.

L'integratore di sistemi deve usare un pin aggiuntivo sul controller GPIO sul SoC per ricevere interruzioni di riattivazione dalla radio Bluetooth. Gli interrupt su questo pin devono essere in grado di svegliare il SoC dallo stato di alimentazione più basso. In alcune progettazioni SoC, tale pin viene definito pin GPIO sempre attivo perché il controller GPIO può rilevare interruzioni su questo pin, indipendentemente dallo stato di alimentazione del SoC. La funzionalità always-on può essere limitata nell'hardware a un set specifico di pin GPIO nel SoC o può essere configurabile nel firmware. È fondamentale che l'integratore di sistemi riveda questa progettazione con il fornitore SoC per garantire che l'interrupt di riattivazione della radio Bluetooth provocherà l'uscita dal soC più profondo stato di alimentazione inattiva. (In qualsiasi momento durante lo standby moderno, il sistema si trova in S0. I sistemi di standby moderni non supportano S3.

Quando tutte le funzioni enumerate dal conducente del bus di trasporto sono state spente e il dispositivo bus di trasporto enumerato ACPI entra in D3, il pin GPIO always-on può essere spento. Ciò si verifica quando le radio per tutte le funzioni del dispositivo enumerate dal conducente del bus di trasporto sono state disattivate dall'utente.

Radio Bluetooth su USB

Se la radio Bluetooth è collegata al soC o al processore core sul bus USB, la radio deve essere alimentato da un'origine diversa dal bus USB. Nella specifica USB, tale radio viene descritta come self-powered e questa funzionalità deve essere segnalata nei descrittori USB del dispositivo Bluetooth.

Analogamente, l'hardware del dispositivo USB deve annunciare il supporto per la riattivazione remota, ovvero la possibilità per la radio Bluetooth di generare la segnalazione USB in banda per riattivare il controller host USB. La funzionalità di riattivazione remota deve essere pubblicizzata anche nei descrittori USB della radio Bluetooth.

La radio Bluetooth deve supportare le funzionalità di riattivazione automatica e remota in modo che possa entrare nello stato Sospensione (D2) e abilitare la sospensione selettiva.

Se la radio Bluetooth è in stato Sospensione (D2) e i dati di un dispositivo associato sono disponibili per l'host, la radio Bluetooth deve generare la riattivazione remota segnalazione per riattivare l'host. Non è supportato un segnale di ripresa fuori banda usando una linea GPIO al processore core. La radio Bluetooth, incluso il circuito di connessione USB, dovrebbe consumare meno di un milliwatt di alimentazione nello stato sospensione (D2).

Problemi di riattivazione

La radio Bluetooth dovrebbe essere in grado di generare un interrupt di riattivazione quando è in stato di sospensione (D2). L'interruzione della riattivazione deve causare l'accensione del SoC, anche se il SoC è nello stato di alimentazione più basso. La tabella seguente riepiloga i due meccanismi di riattivazione Bluetooth.

Bus di connessione	Percorso di segnalazione hardware	Commenti e note
UART (con driver del bus di trasporto fornito dal fornitore)	GPIO dalla radio Bluetooth al SoC.	La radio deve essere connessa a un pin GPIO in grado di riattivare il SoC dallo stato di alimentazione più basso.
USB	Usb in banda riprende la segnalazione dalla sospensione selettiva.	La riattivazione GPIO fuori banda non è supportata.

Test e convalida

I fornitori di dispositivi Bluetooth sono invitati a testare e convalidare l'operazione di risparmio energia del dispositivo radio Bluetooth.

È possibile osservare facilmente le transizioni tra gli stati Active (D0), Sleep (D2) e Off (D3) usando lo strumento Xperf, come descritto in altre sezioni.

Le attività dei driver Bluetooth possono essere monitorate usando la strumentazione ETW integrata in Windows. Lo sviluppatore di driver è incoraggiato a usare la strumentazione ETW (Event Tracing for Windows) per esporre modifiche significative dello stato di risparmio energia nel driver e osservarle usando lo strumento Xperf o windows Visualizzatore eventi predefinito.

Se la radio Bluetooth è collegata tramite USB, l'utilità Powercfg.exe predefinita può essere usata insieme all'opzione della riga di comando /energy per verificare che la radio stia entrando nello stato Sospensione (D2) e sia sospesa. Per usare l'utilità Powercfg.exe:

• Aprire una finestra del prompt dei comandi come amministratore.
• Passare alla directory radice dell'unità (cd \).
• Immettere il comando powercfg.exe /energy.
• Attendere i 60 secondi predefiniti.
• L'utilità Powercfg.exe restituirà il numero di errori e condizioni di avviso nel sistema, come illustrato nello screenshot seguente.
• Dopo che lo strumento scrive le informazioni di riepilogo nella finestra del prompt dei comandi, genera un file HTML denominato Energy-report.html. Aprire il file e cercare le condizioni di errore o avviso dal dispositivo Bluetooth USB. L'esempio di riepilogo seguente segnala che uno stato di sospensione (D2) di un dispositivo Bluetooth USB non è stato attivato quando è inattivo.

I fornitori di dispositivi Bluetooth che forniscono driver e applicazioni di profilo Bluetooth di terze parti aggiuntivi devono verificare che il software supporti la rimozione a sorpresa e consenta all'infrastruttura di gestione radio di disattivare correttamente la radio Bluetooth in modo tempestivo. Questi scenari devono essere convalidati mentre il profilo o l'applicazione è in uso. Ad esempio, per i driver audio, dovrebbe essere presente lo streaming audio Bluetooth mentre la radio è disattivata. La radio dovrebbe quindi essere riattivata e il flusso audio è stato riavviato per verificare che funzioni ancora.

Elenco di controllo per il risparmio energia Bluetooth

Gli integratori di sistemi, i fornitori di radio Bluetooth e i fornitori soC devono usare l'elenco di controllo seguente per garantire che la progettazione del risparmio energia del sistema sia compatibile con Windows 8 e Windows 8.1:

• Determinare il bus di comunicazione per la radio Bluetooth nella progettazione del sistema. La radio Bluetooth è connessa tramite UART o collegata tramite USB.

• Assicurarsi che la radio Bluetooth supporti una modalità sospensione a basso consumo che consuma meno di un milliwatt quando non sono associati dispositivi.

  Il consumo di energia della radio Bluetooth in modalità sospensione può variare in base al numero di dispositivi associati attualmente presenti, ma in genere non deve superare cinque milliwatt in qualsiasi momento.

• Assicurarsi che la radio Bluetooth supporti le seguenti funzionalità di risparmio energia necessarie di base:

  • Supporto per lo stato Off (D3) come modo per consentire all'utente di disattivare la radio.
  • Un meccanismo per entrare in uno stato di sospensione a basso consumo (D2) in cui le connessioni vengono mantenute ai dispositivi associati, ma non sono presenti trasferimenti attivi.
  • Un meccanismo per riattivare il SoC quando un dispositivo associato genera dati e il SoC è in uno stato a basso consumo.

• Se la radio Bluetooth è connessa tramite un bus non USB (UART o integrato nel SoC), il fornitore di radio Bluetooth deve sviluppare un driver del bus di trasporto. L'autista del bus di trasporto deve eseguire le operazioni seguenti:

  • Supportare le funzionalità e i requisiti descritti in Linee guida per la gestione del controllo alimentazione Bluetooth.
  • Convertire le richieste Bluetooth dal driver Bluetooth di Windows (Bthmini.sys) ai comandi alla radio Bluetooth tramite il bus UART o un bus SoC interno proprietario.
  • Eseguire la transizione del dispositivo radio Bluetooth in varie modalità di risparmio energia che eseguono il mapping agli stati Attivo (D0), Sospensione (D2) e Off (D3). Il driver deve anche implementare routine che gestiscono i runtime di integrazione dx (Device Power Management).
  • Configurare la radio Bluetooth per riattivare il SoC quando un dispositivo genera l'input e modificare lo stato di tutte le righe GPIO facoltative che connettono il SoC alla radio Bluetooth a scopo di risparmio energia.
  • Enumerare altri dispositivi (ad esempio, un trasmettitore FM) che potrebbero essere condivisi sulla radio Bluetooth.
  • Usare Windows Driver Framework (WDF) per lo sviluppo di driver.
  • Essere implementata in base al driver del bus HCI seriale Bluetooth.

• Se la radio Bluetooth è connessa tramite USB, il fornitore di radio Bluetooth deve:

  • Abilitare il supporto per la sospensione selettiva nella radio.
  • Assicurarsi che la radio abbia le funzionalità remote-wake e self-powered impostate nel descrittore del dispositivo USB.
  • Assicurarsi che la radio (inclusi i componenti USB) consumi meno di un milliwatt.

• Indipendentemente dal bus di connessione, la radio Bluetooth deve eseguire le operazioni seguenti per una radio connessa internamente:

  • Assicurarsi che tutti i componenti RF siano disattivati in risposta a un comando HCI_Reset inviato alla radio in preparazione all'accensione della radio. La radio non deve essere in grado di trasmettere né ricevere segnali radio.
  • Immettere la modalità di alimentazione più bassa quando è impostata sullo stato Disattivato (D3).

• Se la radio Bluetooth è connessa tramite UART, l'integratore di sistemi deve connettere il segnale di riattivazione dalla radio Bluetooth a un pin GPIO sul SoC che può riattivare il SoC dallo stato di alimentazione più basso.

  • Il SoC può richiedere l'instradamento dei segnali di riattivazione a un set limitato di pin GPIO preconfigurati per essere sempre attiva.
  • In alternativa, il SoC può supportare la configurazione di un pin GPIO a un pin sempre attivo nel firmware di sistema durante l'avvio.

• L'integratore di sistemi deve testare e verificare che la radio Bluetooth entri nello stato Sospensione (D2) quando non sono presenti dispositivi associati.

• L'integratore di sistemi deve testare e verificare che la radio Bluetooth entri nello stato Sospensione (D2) quando tutti i dispositivi associati non dispongono di trasferimenti attivi.

• L'integratore di sistemi deve testare e verificare che la radio Bluetooth possa riattivare il SoC dallo stato di alimentazione più basso quando la radio è nello stato Sospensione (D2).

• L'integratore di sistemi deve testare e verificare che la radio Bluetooth non generi segnali di riattivazione spuri durante lo stato Sospensione (D2).

• L'integratore di sistemi deve testare e verificare che il software aggiuntivo di terze parti, ad esempio driver di profilo e applicazioni, funzioni correttamente con la gestione delle radio Bluetooth. La radio deve essere disattivata e attivata mentre il software di terze parti è attivamente in uso (ad esempio, la riproduzione di audio o il trasferimento di un file).