Управление питанием приемника GNSS для современных резервных платформ

Статья
01/10/2024

В этом разделе рассматривается управление питанием глобальной спутниковой системы навигации (GNSS) для современных резервных платформ.

Компьютер с Windows, реализующий современную модель резервной питания, может также содержать устройство глобальной навигационной вспомогательной системы (GNSS). Устройство GNSS позволяет пользователю получать данные о расположении высокой точности из спутниковой навигационной системы, например глобальных систем позиционирования (GPS) или глобальной навигационной системы навигации орбиты (GLONASS). После того как аппаратная платформа входит в современную резервную систему, устройство GNSS должно ввести режим низкой мощности, в котором он потребляет не более 1 мВт мощности. Устройство GNSS должно оставаться в этом режиме, пока платформа не выйдет из современного резервирования.

Устройства GNSS, поддерживающие GPS и глобальную спутниковую навигационную систему орбиты (GLONASS), были доступны в течение некоторого времени, но более новые устройства GNSS поддерживают спутниковые навигационные системы, такие как BeiDou Navigation System (BDS) и Galileo.

Современная резервная платформа обычно строится вокруг интегрированного канала System on a Chip (SoC). Windows поддерживает следующие варианты добавления устройства GNSS на такую платформу:

Включите модуль мобильного широкополосного подключения (МБ B), содержащий встроенное устройство GNSS. Этот метод распространен в сотовых телефонах.
Выберите SoC, содержащий встроенное устройство GNSS.
Используйте низкую мощность шины, например I2C, SPI или UART, для подключения автономного устройства GNSS к SoC.

Если это возможно, системный интегратор должен выбрать устройство GNSS, реализующее режим спящего режима с низким питанием, в котором устройство потребляет не более 1 мВт мощности. Поставщик устройства GNSS должен предоставить драйвер датчика расположения, который преобразует данные расположения с устройства GNSS в форму, необходимую клиентским приложениям. Эти приложения подключаются к устройству GNSS через API расположения Windows. Драйвер датчика расположения для устройства GNSS отслеживает следующие сведения:

Количество клиентов, которые в настоящее время подключены к устройству GNSS через API расположения.
Состояние переключателя включено или выключение для устройства GNSS. Пользователь управляет этим параметром через приложение Windows Параметры. Дополнительные сведения см. в разделе "Интеграция управления радиосвязями".

Драйвер датчика расположения использует эти сведения для определения простоя устройства GNSS, чтобы его можно было разместить в режиме низкой мощности. Устройство GNSS активно используется только в том случае, если один или несколько клиентов подключены к устройству. В противном случае устройство неактивно.

Чтобы продлить срок работы батареи системы, доступ к устройству GNSS ограничен во время современного ожидания. Приложения с экрана блокировки могут получать доступ к геофенсации и расположению информации во время современного резервного копирования. Однако приложения без блокировки могут использовать API расположения для получения данных о расположении с устройства GNSS только во время включения дисплея и взаимодействия платформы с пользователем. Вскоре после отключения дисплея платформа переходит в современный режим ожидания, все приложения, не связанные с блокировкой, имеющие подключения к устройству GNSS, автоматически отключены Windows, и приложения приостановлены.

Режимы управления питанием

Ожидается, что приемник GNSS имеет 4 режима управления питанием, как описано ниже.

Режимы питания приемника GNSS

Режим питания устройства	Description	Состояние питания устройства (Dx)	Состояние радио (как показано для пользователя)	Число Подключение клиентов	Среднее потребление электроэнергии (mW)	Механизм перехода
Активный (приобретение)	Приемник GNSS приобретает вспомогательное исправление.	D0	Вкл	>= 1	~200 mW	Н/П
Активный (отслеживание 1 Гц)	Приемник GNSS приобрел вспомогательное исправление и предоставляет данные одному или нескольким приложениям периодически.	D0	Вкл	>= 1	~100 mW (устройство зависит от устройства)	Н/П
Sleep	Приемник GNSS не имеет подключенных клиентов, оборудование приемника GNSS по-прежнему применяется для сохранения контекста на устройстве и уменьшения времени возобновления задержки в активном режиме.	D3(D3hot)	Выключение или включение	0	<1 mW (для конкретного устройства)	Инициировано программным обеспечением. Это выборочное состояние приостановки для радио GNSS, подключенных непосредственно к шине универсальной последовательной шины (USB) или составному устройству USB.
Удалено питание	Приемник GNSS не имеет подключенных клиентов, переключатель отключен и все питание от приемника GNSS было удалено внешней сущностью.	D3(D3cold)	Выключение или включение	0	0 mW	Инициированные программным обеспечением и требуют аппаратной координации для удаления энергии.

Драйвер программного обеспечения для приемника GNSS также должен обрабатывать управление радио, как описано ниже.

Требования к реализации платформы

Современная резервная платформа имеет несколько вариантов физической интеграции приемника GNSS. Приемник GNSS может быть частью автономного устройства, которое подключено к SoC с помощью шины связи с низкой мощностью. Приемник GNSS также может быть интегрирован в мобильное широкополосное радио (МБ B), так как приемники GNSS распространены в сотовых телефонах. Наконец, приемник GNSS может быть интегрирован в сам SoC.

Эти несколько вариантов представляют проблему для системного интегратора при определении реализации, выбранной для платформы, требующей функциональных возможностей GNSS. Для современных резервных платформ Windows системные интеграторы рекомендуется интегрировать GNSS в следующем порядке приоритета:

Если система оснащена радио МБ B, используйте приемник GNSS, интегрированный в модуль МБ B.
Если система оснащена soC с подключенным приемником GNSS, используйте приемник GNSS, интегрированный в SoC.
Интеграция автономного приемника GNSS, подключенного к SoC, через шину связи с низкой мощностью (например, UART, SPI или I2C).

Системный интегратор не должен предоставлять дополнительных получателей GNSS в Windows. В присутствии нескольких приемников GNSS, предоставляемых операционной системе, Windows не агрегирует сведения о расположении со всех устройств GNSS.

Механизм управления питанием программного обеспечения

Ожидается, что устройства GNSS на платформах Windows управляются драйвером среда выполнения платформы драйвера режима пользователя (UMDF), использующим модель расширения класса датчиков Windows и реализующим интерфейс ISensorDriver. Этот драйвер GNSS называется драйвером датчика расположения и, как ожидается, управляет базовым приемником GNSS и предоставляет данные для запросов приложений для получения сведений о расположении.

Обзор и модель приложения

Драйверы датчиков расположения используют число подключенных клиентов приложений в качестве основного механизма, чтобы определить, когда устройство GNSS может входить в режим спящего или удаленного питания. Драйвер датчика расположения также отвечает за взаимодействие с библиотекой диспетчера радиосвязи GNSS, предоставляемой поставщиком, которая позволяет пользователю контролировать, включена ли или отключена радио GNSS. Драйвер датчика расположения может использовать как количество подключенных клиентов, так и предпочтения пользователя для состояния радио, чтобы гарантировать, что устройство GNSS находится в режиме с низким питанием или питанием, когда это возможно.

Приложения Microsoft Store управляют временем существования переднего плана и фоновых приложений, поэтому имеют значительное влияние на число клиентов приложений, подключенных к драйверу датчика расположения. Приложение переднего плана запрашивает сведения о расположении через API расположения Windows. Когда приложение переднего плана переключится на фон пользователя, модель приложения Microsoft Store гарантирует, что клиентское приложение отключается от приемника GNSS.

Этот механизм модели приложения позволяет драйверу датчика расположения легко отслеживать количество подключенных клиентов приложений. Всякий раз, когда есть ноль подключенных клиентов приложений, драйвер датчика расположения может перенести устройство GNSS в спящий или удаленный режим питания.

Когда система входит в современную резервную систему, Windows автоматически приостанавливает все приложения переднего плана, что приводит к тому, что драйвер датчика расположения наблюдает за числом подключенных клиентов, переходящих к нулю.

Интеграция управления радиосвязями

Драйвер датчика расположения также должен реализовать интерфейс для взаимодействия с библиотекой радиоуправлений, предоставленной поставщиком. Библиотека диспетчера радио позволяет Windows предоставлять переключатель устройства GNSS "вкл/выкл." в приложении Windows Параметры.

Требования к реализации драйвера датчика расположения

Драйвер датчика расположения должен поместить устройство GNSS в состояние D3 с низкой мощностью, если устройство GNSS не используется. Устройство GNSS не используется, если в настоящее время нет подключенных клиентов или GNSS не было отключено через радио manager.

Драйвер датчика расположения должен сохранять устройство GNSS в состоянии D3 во всех случаях, когда устройство GNSS было отключено через диспетчер радиосвязи. Это требование запрещает драйверу использовать управляемую питанием очередь и просто пересылать запросы от подключенных клиентов. Драйвер датчика расположения должен использовать неуправляемую очередь для ввода-вывода и управлять простоем непосредственно с помощью методов StopIdle и ResumeIdle. Датчик расположения должен оставаться владельцем политики питания для стека драйверов устройства GNSS. Драйвер должен задать для параметра bPowerManaged значение FALSE при вызове IWDFDevice::CreateIoQueue , чтобы создать очередь ввода-вывода.

Как упоминание выше, драйвер использует количество подключенных клиентов и состояние радио от радио manager, чтобы определить, неактивно ли устройство GNSS. Когда устройство GNSS неактивно, драйвер вызывает метод ResumeIdle, который вызывает платформу драйверов для запуска перехода D3. Платформа драйверов выполнит реализацию драйвера метода OnD0Exit .

Когда устройство GNSS должно быть повторно активировано из-за нового подключенного клиента или питания на радио, драйвер вызывает метод StopIdle . Платформа драйверов выполнит реализацию драйвера метода OnD0Entry . Обратите внимание, что драйвер должен выполнить метод StopIdle с параметром WaitForD0, равным FALSE.

Схема состояния, представленная ниже, иллюстрирует эту связь и служит руководством для разработчика драйвера, чтобы при вызове методов StopIdle и ResumeIdle.

Так как драйвер отвечает за отслеживание того, не работает ли устройство, оно должно напрямую управлять очередью ввода-вывода и получать доступ к аппаратному устройству.

Драйвер датчика расположения должен реализовать методы IPnpCallbackSelfManagedIo::OnSelfManagedIoSuspend и IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart . Обратите внимание, что платформа драйверов вызовет IPnpCallbackSelfManagedIo::OnSelfManagedIoInit при запуске устройства, включая загрузку системы. Последующие вызовы относятся к обратному вызову IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart . Эти интерфейсы должны быть зарегистрированы, когда платформа драйверов вызывает метод CreateDevice.

IPnpCallbackSelfManagedIo ::OnSelfManagedIoRestart сообщает драйверу датчика расположения, который запрашивает в драйвере, может напрямую взаимодействовать с оборудованием устройства GNSS, включая запросы от ISensorDriver:: обратные вызовы. Обратите внимание, что платформа драйверов гарантирует доступ к оборудованию устройства в методах OnD0Exit и OnD0Entry .

Аналогичным образом, когда метод IPnpCallbackSelfManagedIo::OnSelfManagedIoSuspend вызывается платформой, драйвер должен завершить все запросы ISensorDriver непосредственно перед возвращением из OnSelfManagedIoSuspend. Драйвер не может получить доступ к оборудованию устройства, если это может предотвратить выполнение любого из этих запросов в течение одной секунды. Если драйвер датчика расположения имеет ожидающий запрос на оборудование устройства GNSS, запрос должен быть отменен, если он не может быть выполнен каким-либо другим способом, не нарушая это ограничение времени.

Если драйвер не взаимодействует напрямую с аппаратным устройством или все невыполненные аппаратные запросы гарантированно выполняются в течение одной секунды, драйвер должен реализовать метод OnSelfManagedIoSuspend с помощью следующей процедуры:

Задайте глобальный флаг, указывающий, что устройство неактивно.
Вызовите метод StopSynchronously в очереди Windows Driver Frameworks (WDF).
Остановите любую другую асинхронную работу, которая обращается к оборудованию устройства GNSS.
Вызовите метод Start в очереди WDF.
Снимите глобальный флаг, заданный на шаге 1.

Пример кода, выполняющий эти операции, см. в реализации OnSelfManagedIoSuspend в примере драйвера геолокации датчиков (UMDF версии 1).

Если драйвер взаимодействует непосредственно с аппаратным устройством, перед очисткой очереди ввода-вывода необходимо отменить все невыполненные запросы к оборудованию. Драйвер должен реализовать метод OnSelfManagedIoSuspend , выполнив следующую процедуру:

Задайте глобальный флаг, указывающий, что устройство неактивно.
Вызовите метод Stop в очереди WDF.
Отмена всех ожидающих запросов оборудования, чтобы разрешить выполнение всех потоков обратного вызова ISensorDriver .
Вызовите метод StopSynchronously в очереди WDF.
Остановите любую другую асинхронную работу, которая обращается к оборудованию устройства GNSS.
Вызовите метод Start в очереди WDF.
Снимите глобальный флаг, заданный на шаге 1.

Все драйверы датчиков расположения должны синхронно очищать очередь ввода-вывода в рамках реализации метода OnSelfManagedIoFlush .

Режимы спящего режима и режима удаления питания

Устройства GNSS могут поддерживать режим спящего режима и режим удаления питания, если устройство имеет локальный контекст сохранен и по-прежнему может реагировать на запросы по шине связи без внешнего сигнала. (Как правило, устройство в режиме удаления питания не может отвечать на запросы шины.) Драйвер датчика расположения должен быть записан, чтобы понять, может ли базовое устройство работать в режиме удаления питания. Драйвер датчика расположения должен включить D3cold только в том случае, если базовое устройство может использовать режим удаления питания, и драйвер может сохранять и восстанавливать контекст и повторно инициализировать устройство. В противном случае датчик расположения должен продолжать использовать D3 в качестве состояния простоя, но не включить D3cold. Это позволяет базовым шинам и драйверам фильтров помещать устройство в спящий режим низкой мощности, а не в режиме удаления питания.

Когда драйвер датчика расположения указывает, что поддерживает D3cold и начинает переход D3, базовые драйверы шины и фильтров отвечают за удаление питания с устройства. Механизм может быть реализован ACPI в случае устройств GNSS, подключенных к UART. Кроме того, механизм может быть включен с помощью сочетания драйвера USB-концентратора и драйвера ACPI в случае устройств GNSS с USB-перечислением.

Если устройство GNSS находится в SoC, собственный драйвер и встроенное ПО от поставщика SoC, реализованные в базовых драйверах, отвечает за удаление питания с устройства GNSS. Если устройство GNSS потребляет более 1 mW в режиме спящего режима, драйвер GNSS, встроенное ПО платформы и оборудование должны быть спроектированы для размещения устройства в режиме удаления питания при отключении всех клиентов.

Обнаружение простоя

Драйвер датчика расположения для устройства GNSS должен переносить устройство в режим питания в спящий режим всякий раз, когда это возможно. Если приложение запрашивает длинный интервал отчета, драйвер датчика расположения должен перенести устройство GNSS в режим питания спящего режима, пока не будет запрошено следующее исправление. Драйвер датчика расположения должен перенести устройство GNSS в активный режим питания с достаточным временем для триангуляции исправления и предоставления приложению данных расположения.

Например, предположим, что короткий запрошенный интервал отчета составляет 30 минут, и устройство требует одной минуты для прогреть и получить исправление расположения. В этом сценарии драйвер датчика расположения должен:

Сразу после предоставления сведений о расположении вызовите ResumeIdle, который переключит устройство GNSS в спящий режим (D3).
Наведите таймер на срок действия 28 минут в будущем. (TimerExpiration = ReportInterval — WarmUpTime).
По истечении срока действия таймера вызовите StopIdle, который переключит устройство GNSS на D0.
Когда устройство приобрело исправление, укажите сведения о расположении приложения. Обратите внимание, что драйвер датчика расположения должен тщательно настроить D3cold.

Если устройству требуется постоянная мощность для достижения задержки возобновления для WarmUpTime, D3cold не должна быть включена. D3cold можно включить динамически во время выполнения, изменив значение ExcludeD3Cold в структуре WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS.

Когда устройство GNSS, подключенное через USB, переходит в спящий режим (D3) с отключенным D3cold, устройство перейдет в состояние приостановки USB, которое экономит значительную мощность микросхем и процессора. Если драйвер датчика расположения включает D3cold и переходит в спящий режим (D3), базовая платформа может удалить питание с устройства даже при подключении через USB-шину.

Поддерживаемые конфигурации оборудования

Windows поддерживает четыре конфигурации физического оборудования для устройства GNSS. Шина подключения отличается от каждой конфигурации оборудования.

GNSS, подключенный к SoC через UART

В этой конфигурации радио GNSS является автономным устройством, подключенным к UART в SoC. Радио GNSS может иметь один или несколько GPIOs между радио и SoC в целях перехода между активными и спяющими режимами питания или для обработки сброса и состояния последовательности питания.

Если радио GNSS потребляет менее 1 mW в режиме спящего режима, радио GNSS может быть подключено к любой системной железной дороге, которая соответствует спецификациям устройства.

Устройство GNSS должно быть объявлено в пространстве имен ACPI и GPIOs для управления питанием должно управляться _PS3 и _PS0 методами управления под устройством в пространстве имен ACPI. Методы _PS3 и _PS0 выполняются драйвером ACPI в ответ на переходы D3 и D0, инициированные драйвером датчика расположения. Системный интегратор должен объявить объекты GPI как часть области операций GPIO в пространстве имен ACPI.

Если приемник GNSS потребляет более 1 mW в режиме питания спящего режима, приемник GNSS должен быть подключен к железнодорожной линии питания, которая может быть включена и отключена с помощью GPIO, управляемого встроенного ПО ACPI в SoC. В этой конфигурации драйвер датчика расположения должен включить D3cold. GPIO для управления переключимым питанием железнодорожной линии должен быть предоставлен в области операции ACPI GPIO. Системный интегратор должен описать ресурс питания для переключаемой линии питания, включая методы _OFF и _ON, а также ссылки на ресурс питания под устройством GNSS в пространстве имен.

Драйвер Windows ACPI будет оценивать метод _OFF при переходе драйвера датчика расположения на D3. Когда драйвер датчика расположения переходит на D0, драйвер Windows ACPI будет оценивать метод _ON в ресурсе питания. Реализация методов _OFF и _ON должна переключать GPIO, которая управляет переключением электропередачи и реализует все необходимые задержки последовательности питания.

GNSS интегрирован в SoC

Если устройство GNSS физически интегрировано в SoC, реализация коммуникаций и управления питанием зависит от самого SoC.

Устройство GNSS по-прежнему должно быть перечислено через ACPI, хотя связь с базовым приемником GNSS может происходить через транспортный драйвер, предоставляемый поставщиком SoC. В этой конфигурации драйвер датчика расположения по-прежнему должен реализовать переход D3 для ввода режима спящего режима или режима удаления питания при отключении всех клиентов. Переход D3 гарантирует, что средства управления питанием ОС Windows и диагностика могут легко наблюдать за состоянием питания устройства GNSS.

Системные интеграторы, которые планируют использовать радио GNSS, интегрированный в систему SoC, должны тесно обращаться к поставщику SoC для поддержки встроенного ПО, драйверов и управления питанием.

GNSS, интегрированный в usb-подключенный МБ B радио в виде составного USB-устройства

Системный конструктор может интегрировать подключаемый usb-модуль МБ B, содержащий внедренный приемник GNSS. В этой конфигурации оборудования драйвер датчика расположения взаимодействует со встроенным приемником GNSS непосредственно через USB-шину как одну функцию в составном USB-устройстве.

Обратите внимание, что системы с устройствами GNSS в модуле МБ B требуют тщательной интеграции. Обратитесь к представителю Корпорации Майкрософт, чтобы просмотреть оборудование, программное обеспечение и встроенное ПО для этих решений.

В этой конфигурации устройство GNSS является интегрированной частью модуля МБ B. Радио GNSS может совместно использовать компоненты обработки, питания и антенны RF с радио МБ B. Радио GNSS предоставляется непосредственно программному обеспечению в виде одного интерфейса на составном USB-устройстве. Драйвер датчика расположения взаимодействует с радио GNSS непосредственно через USB-шину с помощью интерфейсов USB-драйверов, реализованных внутри драйвера датчика расположения.

Управление питанием оборудования GNSS управляется подключением в полосе связи с модулем GNSS. Модуль GNSS и драйвер датчика расположения должны поддерживать механизм включения и отключения радио GNSS. Этот механизм не должен полагаться на использование любых GPIOS из SoC в модуль МБ B+GNSS.

Аналогичным образом модуль GNSS и драйвер датчика расположения должны поддерживать переход устройства в состояние D3, таким образом, что составное USB-устройство может входить в состояние приостановки USB (выборочная приостановка). Все функции на составном USB-устройстве должны быть приостановлены для приостановки составного устройства. Устройство GNSS должно находиться в режиме спящего режима (D3), чтобы функция GNSS и все составное USB-устройство было в состоянии приостановки.

Обратите внимание , что устройство GNSS и драйвер должны поддерживать выборочную приостановку, в противном случае контроллер USB-узла в SoC не может войти в режим низкой мощности и предотвратит экономию питания во время современного резервного копирования.

В этой конфигурации устройство GNSS перечисляется через USB и составной драйвер USB, но описывается в пространстве имен ACPI. В этой конфигурации нет поддержки обмена данными GPIO между устройством GNSS в модуле МБ B и SoC. Устройство GNSS должно оставаться перечисленным в Windows через ACPI в течение всего времени, когда платформа остается в состоянии питания системы S0, даже если радио отключено пользователем. Устройство GNSS никогда не должно исчезать из USB-шины во время любой части системы.

GNSS, интегрированный в usb-подключенный МБ B радио с помощью служб устройств

Системный конструктор может интегрировать подключаемый usb-модуль МБ B, содержащий внедренный приемник GNSS. В этой конфигурации оборудования драйвер датчика расположения взаимодействует со встроенным приемником GNSS через интерфейс служб мобильных широкополосных устройств, а не устройство GNSS, которое предоставляется как автономная USB-функция в составе составного устройства, представляющего весь модуль МБ B.

Обратите внимание, что эта конфигурация не рекомендуется. Системные интеграторы, выбирая этот метод интеграции устройств GNSS, должны обратиться к своему представителю Майкрософт, чтобы проверить правильную реализацию. Предоставление устройства GNSS в составе составного USB-устройства, представляющего модуль МБ B, предпочтительнее.

В этой конфигурации устройство GNSS является интегрированной частью модуля МБ B. Радио GNSS может совместно использовать компоненты обработки, питания и антенны RF с радио МБ B. Радио GNSS предоставляется косвенно программному обеспечению через интерфейс служб устройств, к которому можно получить доступ с помощью COM-интерфейса WindowsIMbnDeviceServices. Драйвер датчика расположения взаимодействует с радио GNSS через интерфейс IMbnDeviceServices.

Управление питанием оборудования GNSS управляется межполосной связью через интерфейс служб устройств с модулем МБ B. Оборудование GNSS должно поддерживать встроенный механизм через интерфейс служб устройств, чтобы отключить радио и разместить устройство GNSS в режиме низкой мощности. Эти механизмы должны быть доступны драйвером датчика расположения через интерфейс служб устройств.

В этой конфигурации устройство GNSS должно быть перечислено ACPI и описано в пространстве имен ACPI в качестве дочернего элемента модуля мобильной широкополосной связи. Устройство GNSS не будет иметь аппаратных ресурсов, описанных под устройством в пространстве имен ACPI.

Драйвер датчика расположения должен по-прежнему выполнять тот же набор рекомендаций по реализации управления питанием, как описано в предыдущем разделе требований к реализации драйвера.

В этой конфигурации нет поддержки обмена данными GPIO между устройством GNSS в модуле МБ B и SoC. Все средства управления питанием и радиосвязи выполняются физически через USB-шину и предоставляются драйверу датчика расположения через интерфейс служб устройств. Устройство GNSS должно оставаться перечисленным в Windows через ACPI для всей системы вовремя, даже если радио отключено пользователем.

При реализации этой конфигурации оборудования системный интегратор рекомендуется тесно сотрудничать с поставщиком модуля МБ B, чтобы убедиться, что устройство GNSS предоставляется правильно в пространстве имен ACPI.

Проблемы пробуждения

Нет проблем пробуждения для устройств GNSS. Устройства GNSS не должны поддерживать пробуждение SoC из состояния низкой мощности.

Тестирование и проверка

Поставщики устройств GNSS, поставщики модулей МБ B и системные интеграторы должны следовать этим рекомендациям для тестирования и проверки реализации управления питанием устройства GNSS и связанных с ним компонентов программного обеспечения. Дополнительные сведения см. в руководстве по тестированию глобальной спутниковой системы навигации (GNSS).

Управление питанием датчика расположения

Системный интегратор должен проверить, что драйвер датчика расположения для устройства GNSS выполняет переходы управления питанием и вводит состояние D3 при отключении или отключении радио.

Ниже приведены основные тестовые случаи:

Обратите внимание, что драйвер датчика расположения переходит на D3 в течение 10 секунд после отключения экрана для современного резервирования.
Обратите внимание, что драйвер датчика расположения переходит на D3 в течение 10 секунд после отключения радио в приложении Windows Параметры.
Обратите внимание на переход драйвера датчика расположения на D0 сразу после выхода из современного резервного копирования и запуска приложения, использующего API расположения.

Самый простой способ наблюдать за переходами состояния Dx драйвера датчика расположения — использовать набор средств производительности Windows для сравнения с другими устройствами датчика Windows. Этот метод использует инструментирование Windows для проверки передачи IRP D3 через стек драйверов устройств, который состоит из устройства GNSS. Диспетчер питания Windows включает встроенную инструментирование трассировки событий для Windows (ETW), включая инструментирование для irPs питания устройств (DX). Чтобы просмотреть эти сведения в ручном режиме, получите и установите набор средств производительности Windows (WPT) в системе в тестируемом режиме.

Запустите трассировку XPerf в пользовательском режиме с помощью следующих команд:

Откройте командную строку Администратор istrator.
Перейдите в папку \%ProgramFiles%\Windows Kits\8.0\Windows Performance набор средств\.
Пуск Xperf: xperf.exe -start power_session -on Microsoft-Windows-Kernel-Power
Перезапустите систему в современный режим ожидания с помощью кнопки питания.
Подождите 120 секунд.
Переход системы из современной резервной системы с помощью кнопки питания.
Подождите 60 секунд.
Выполните следующую команду, чтобы остановить ведение журнала событий: xperf.exe -stop power_session
Преобразуйте двоичный файл трассировки в csv-файл и формат, доступный для чтения человеком: xperf.exe –i \user.etl > power.txt
Откройте файл power.txt в текстовом редакторе и найдите идентификатор оборудования устройства GNSS. Идентификатор оборудования устройства GNSS можно определить на вкладке "Сведения" свойств устройства в диспетчер устройств в разделе "Путь к экземпляру устройства". В приведенном ниже примере путь экземпляра устройства GNSS — ACPI\MST0731\2&daba3ff&0.
IRP D3 для устройства GNSS указывается событием типа Microsoft-Windows-Kernel-Power/IRP/Stop с путем экземпляра устройства GNSS и последним значением события 3 для состояния D3. Выходные данные события, приведенные ниже из файла power.txt, показывают начало IRP D3.

Microsoft-Windows-Kernel-Power/Irp/Start , 7605393, "Unknown" ( 4), 256, 0, , , , , 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\MSFT0731\2&daba3ff&0", 3
Это событие должно быть зарегистрировано в начале выходного файла power.txt. Параметр 0x868e2728 в приведенном выше примере — указатель на структуру D3 IRP. Найдя последующие события с этим же указателем IRP, можно обнаружить представление IRP D3, движущееся через стек драйверов, включающее устройство GNSS. Обратите внимание, что указатель IRP будет системным и загрузочным.
Microsoft-Windows-Kernel-Power/Irp/Start , 7605393, "Unknown" ( 4), 256, 0, , , , , 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\ATML1000\2&daba3ff&0", 3
Microsoft-Windows-Kernel-Power/Driver/Start , 7605416, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0, "\Driver\gpsdrv"
Microsoft-Windows-Kernel-Power/Driver/Stop , 7605515, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0
Microsoft-Windows-Kernel-Power/Driver/Start , 7608351, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x857ffb90, "\Driver\ACPI"
Microsoft-Windows-Kernel-Power/Driver/Stop , 7608416, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x857ffb90
Microsoft-Windows-Kernel-Power/Driver/Start , 7608424, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0, "\Driver\sensdrv"

Проверка того, что устройство GNSS возвращается в D0, когда экран включен аналогично. Событие Microsoft-Windows-Kernel-Power/IRP/Start для устройства GNSS будет зарегистрировано с целевым состоянием 0 (D0). D0 IRP будет передаваться через драйверы, содержащие стек устройств GNSS аналогично D3 IRP.

Список проверка управления питанием GNSS

Системные интеграторы, поставщики радиоконференций GNSS и Поставщики SoC должны использовать следующий список проверка, чтобы обеспечить совместимость своей системы управления питанием с Windows 8 и более поздних версий.

Интеграция устройства GNSS в современную платформу с поддержкой резервного копирования в следующем порядке предпочтения конфигурации:
1. Интегрирована вместе с модулем МБ B (для систем, оснащенных МБ B), подключенным через USB.
2. Интегрирована с SoC (для систем с GNSS в SoC).
3. Автономный за пределами SoC, подключенный к UART, I2C или другой низкой мощности шины.
Выберите устройство GNSS, включающее спящий режим (радио вне), среднее потребление электроэнергии менее 1 мВт, включая интерфейсы подключения к шине.
Если устройство GNSS имеет среднее потребление электроэнергии (радио отключено) больше 1 mW, системный интегратор и поставщик устройств GNSS должны поддерживать удаление питания полностью с устройства GNSS, если нет подключенных клиентов приложений или радио отключается пользователем.
Убедитесь, что поставщик устройства GNSS предоставляет драйвер датчика расположения, который реализует управление питанием среды выполнения на основе числа подключенных клиентов и состояния радио GNSS.
Убедитесь, что поставщик устройств GNSS предоставляет радиоуправленную библиотеку, которая предоставляет радио GNSS в приложении windows Параметры.

Драйвер датчика расположения должен реализовать частный интерфейс для обмена данными о состоянии включено или выключение между библиотекой диспетчера радиосвязи поставщика и драйвером датчика расположения, предоставленным поставщиком.
Если GNSS является автономным устройством за пределами SoC, подключенного через UART, I2C или другую низкопроизводительную шину, системный интегратор и поставщик устройств GNSS должны:
1. Задокументируйте любые объекты GPIOS между устройством GNSS и самой soC.
2. Предоставление всех объектов GPI для управления питанием в рамках области операций GPIO в пространстве имен ACPI.
Если GNSS является автономным устройством за пределами SoC, подключенного через UART, I2C или другую низкую мощность шины, а среднее потребление энергии устройства GNSS в режиме спящего режима питания превышает 1 mW, системный интегратор и поставщик устройств GNSS должны:
1. Предоставьте ресурс питания ACPI и методы управления _ON/_OFF для описания домена питания GNSS.
2. Укажите методы _PR0 и _PR3 на устройстве GNSS в пространстве имен ACPI, который ссылается на описанный ресурс питания ACPI.
3. Убедитесь, что драйвер датчика расположения выполняет переход D3 и включает D3cold в драйвере.
Если GNSS является частью модуля МБ B, системный интегратор и поставщик устройств GNSS должны:
1. Предоставление устройства GNSS в составе составного USB-устройства.
2. Укажите драйвер датчика расположения, который взаимодействует с устройством GNSS непосредственно через USB-шину.
3. Убедитесь, что радио включено и выключение и все управление питанием устройства GNSS может выполняться через USB-шину. В этой конфигурации оборудования нельзя использовать GPIOS для изменения радио или состояния питания GNSS.
4. Убедитесь, что USB-устройство, описывающее модуль МБ B или составное USB-устройство, описывающее радио МБ B и GNSS, входит в состояние приостановки USB во время современного ожидания.
5. Драйвер датчика расположения должен ввести режим D3 (спящий режим), если все клиенты отключены или радио отключены, даже если обмен данными с устройством через интерфейс служб устройств.
6. Если устройство GNSS управляется через интерфейс служб мобильных широкополосных устройств (не рекомендуется), устройство GNSS должно быть описано в пространстве имен ACPI системы без аппаратных ресурсов. Устройство GNSS должно быть описано как дочерний модуль мобильной широкополосной связи в пространстве имен ACPI.
Проверьте и убедитесь, что устройство GNSS и драйвер датчика расположения правильно выполняют управление питанием. Проверьте следующие тестовые случаи по крайней мере:
- Обратите внимание, что драйвер датчика расположения переходит на D3 в течение 10 секунд после отключения экрана для современного резервирования.
- Обратите внимание, что драйвер датчика расположения переходит на D3 в течение 10 секунд после отключения радио в приложении Windows Параметры.
- Обратите внимание на переход драйвера датчика расположения на D0 сразу после выхода из современного резервного копирования и запуска приложения, использующего API расположения.
Проверьте потребление энергии устройства GNSS в состоянии спящего режима (D3) и убедитесь, что это меньше 1 мВт в среднем.

Поделиться через