Описание фреймворка HDF

• Обзор

• Структура каталога

• Описание

  • Инструкция использования фреймворка устройств
  • Модель сенсорного фреймворка
  • Модель фреймворка отображения
  • Модель фреймворка ввода данных
  • Модель фреймворка WLAN

• Связанные хранилища

Обзор

Это хранилище предназначено для хранения основной информации о подсистеме устройств OpenHarmony (включая фреймворк устройств, управление конфигурацией, анализатор конфигураций, общие модели устройств, интерфейсы доступа к универсальным платформам оборудования и т.д.), чтобы предоставить разработчикам более точную и эффективную среду разработки, стремясь к одной разработке, многократному развертыванию.

Рисунок 1 Архитектурная диаграмма фреймворка устройств

Структура каталога

/drivers/hdf_core/framework
├── core           # Реализация основного кода фреймворка устройств
│   ├── adapter    # Реализация адаптированных интерфейсов взаимодействия с ядром, предоставляющая абстрактные интерфейсы для использования разработчиками
│   ├── common     # Общие базовые коды фреймворка устройств
│   ├── host       # Модуль окружения устройства
│   ├── manager    # Модуль управления фреймворка устройств
│   └── shared     # Код модулей, используемых как host, так и manager
├── include        # Заголовочные файлы, предоставленные фреймворком устройств
│   ├── audio      # Заголовочные файлы, предоставленные для аудио
│   ├── bluetooth  # Заголовочные файлы, предоставленные для Bluetooth
│   ├── core       # Заголовочные файлы, предоставленные фреймворком устройств
│   ├── ethernet   # Заголовочные файлы, связанные с операциями Ethernet
│   ├── net        # Заголовочные файлы, связанные с операциями сетевых данных
│   ├── osal       # Заголовочные файлы, связанные с системой адаптации
│   ├── platform   # Заголовочные файлы, связанные с оборудованием платформы
│   ├── utils      # Заголовочные файлы, предоставленные фреймворком устройств
│   └── wifi       # Заголовочные файлы, предоставленные для WLAN
├── model          # Предоставляет общие модели фреймворка устройств
│   ├── audio      # Модели аудиофреймворка
│   ├── display    # Модели фреймворка отображения
│   ├── input      # Модели фреймворка ввода данных
│   ├── misc       # Модели фреймворков различных устройств, включая dsoftbus, light, vibrator
│   ├── network    # Модели фреймворка WLAN
│   └── sensor     # Модели драйверов сенсоров
│   └── storage    # Модели драйверов хранения
│   └── usb        # Модели драйверов USB
├── sample         # Примеры описания конфигурации HCS и примеры драйверов HDF
├── support        # Базовые возможности системы
│   └── platform   # Фреймворки и интерфейсы доступа к оборудованию платформы, включающие GPIO, I2C, SPI и т.д.
│   └── posix      # Фреймворки и интерфейсы POSIX, включающие Mem, Mutex, Sem, Spinlock, Thread, Time и т.д.
├── test           # Примеры тестовых случаев
├── tools          # Исходные коды инструментов фреймворка HDF
│   └── hc-gen     # Исходные коды инструмента управления конфигурацией
│   └── hcs-view   #
│   └── hdf-dbg    #
│   └── hdf-dev_eco_tool #
│   └── hdf-gen    #
│   └── idl-gen    #
│   └── legacy     #
└── utils          # Предоставляет базовые данные и алгоритмы

Описание

Инструкция использования фреймворка устройств

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

Фреймворк устройств состоит из трех частей:

1. Часть программного обеспечения драйвера — выполняет логику работы драйвера.
2. Конфигурационная информация драйвера — указывает информацию загрузки драйвера.
3. Конфигурация ресурсов драйвера — конфигурирует информацию аппаратной части драйвера.

Программное обеспечение драйвера выполнено для реализации логики работы драйвера:

Первая часть, которую видят разработчики, это входная точка драйвера, которая описывается через структуру DriverEntry.

Основные компоненты включают Bind, Init и Release три интерфейса.

struct HdfDriverEntry g_deviceSample = {
    .moduleVersion = 1,
    .moduleName = "sample_driver",
    .Bind = SampleDriverBind,
    .Init = SampleDriverInit,
    .Release = SampleDriverRelease,
};

Описание интерфейса Bind: этот интерфейс предназначен для выполнения действия привязки устройства к интерфейсу сервиса устройства.

int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject)
{
    return HDF_SUCCESS;
}

Описание интерфейса Init: когда фреймворк завершает действие привязки устройства, он вызывает интерфейс инициализации драйвера. После успешной инициализации, фреймворк устройств решает, создать ли внешний интерфейс сервиса устройства или сделать его видимым только текущему сервису. Если инициализация Init провалилась, фреймворк устройств активно освобождает созданную информацию об интерфейсе устройства.

int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject)
{
    return HDF_SUCCESS;
}

Описание интерфейса Release: при необходимости удаления драйвера, фреймворк устройств сначала уведомляет драйвер о том, что требуется освободить ресурсы, затем освобождает внутренние ресурсы.

void SampleDriverRelease(struct HdfDeviceObject *deviceObject)
{
    // Освобождение всех ресурсов.
    return;
}

Дополнительные инструкции по разработке драйверов с использованием фреймворка HDF см. в руководстве по разработке драйверов.

Модель сенсорного фреймворка Модель драйвера сенсоров на основе фреймворка HDF (Hardware Driver Foundation) позволяет осуществлять миграцию между различными операционными системами, а также конфигурировать различные устройства.

Модель драйвера сенсоров состоит из следующих двух частей:

• Частота базовых возможностей: зависит от фреймворка HDF для регистрации, загрузки, отключения регистрации, обнаружения устройств и других способностей; предоставляет унифицированные интерфейсы для одного типа устройств сенсоров, интерфейсы анализа конфигурации регистров, абстрагированные интерфейсы доступа к шине и интерфейсы абстракции платформы.
• Разработка разработчиком: зависит от управления конфигурацией HCS (HDF Configuration Source); согласно различиям конфигурации одного типа устройств сенсоров, реализует сериализованную конфигурацию параметров устройств и некоторые специальные интерфейсы.

Для разработки драйверов сенсоров на основе модели драйвера сенсоров, см. руководство по разработке драйверов сенсоров.

Модель фреймворка отображения

Модель драйвера отображения на основе фреймворка устройств OpenHarmony позволяет скрывать различия между платформами чипов, что делает переход операционной системы между платформами легче; она также абстрагирует общую бизнес-логику драйверов периферийных устройств, позволяя одной модели драйвера совместимостью с различными устройствами благодаря конфигурации или адаптации к различиям. Это позволяет сторонним производителям эффективно и легко внедряться в экосистему драйверов HarmonyOS.

Модель драйвера отображения состоит из следующих двух частей:

• Частота базовых возможностей: включает определение и реализацию фреймворка HDI (Hardware Driver Interfaces) и адаптацию платформы чипов к этим интерфейсам; драйвер ядра абстрагирует общую бизнес-логику панели, предоставляя такие возможности, как инициализация панели, получение информации конфигурации устройства, включение/выключение питания, установка подсветки и т.д.
• Разработка разработчиком: требует выполнения конфигурации HCS уровня платы и конфигурации частных данных панели, а также реализации зарезервированных интерфейсов, учитывающих различия устройств.

Для разработки драйверов LCD на основе модели драйвера отображения, см. руководство по разработке драйверов LCD.

Модель фреймворка ввода данных

Модель драйвера ввода данных на основе фреймворка устройств OpenHarmony не зависит от платформы чипов, а предоставляет единую точку доступа к драйверам для верхнего уровня службы ввода данных; в конкретной реализации модели драйвера, для разных типов устройств ввода данных, выделены несколько общих драйверов платформы, которые могут быть использованы благодаря конфигурации и специфическим интерфейсам адаптации, таким образом, модель драйвера может быть совместима со всеми типами устройств ввода данных. Благодаря этой модели драйвера можно значительно сократить время разработки драйверов устройств ввода данных.

Модель драйвера ввода данных состоит из следующих двух частей:

• Частота базовых возможностей: включает определение и общую реализацию слоя HDI ввода данных, предоставляющую возможности управления устройствами, контроля бизнес-процессов, отправки данных для верхнего уровня службы ввода данных; модель драйвера ввода данных предоставляет унифицированные драйверы для различных типов устройств ввода данных, включая регистрацию и отмену регистрации устройств, каналы отправки данных event, парсинг информации конфигурации, загрузку общего драйвера и т.д.
• Разработка разработчиком: требует выполнения конфигурации устройства и конфигурации частных данных устройства, а также реализации зарезервированных интерфейсов, учитывающих различия устройств.

Для разработки драйверов touchscreen на основе модели драйвера ввода данных, см. руководство по разработке драйверов touchscreen.

Модель фреймворка WLAN

Модель драйвера WLAN на основе фреймворка устройств OpenHarmony позволяет осуществлять миграцию между различными операционными системами, автоматически адаптироваться к различиям устройств и модульно собирать и компилировать. Разработчики драйверов WLAN могут использовать унифицированные нижележащие интерфейсы, предоставляемые модулем WLAN, для адаптации своих драйверов; разработчики HDI могут использовать унифицированные верхнеуровневые интерфейсы, предоставляемые модулем WLAN, для получения таких возможностей, как создание/закрытие точки доступа WLAN, сканирование, ассоциация с точками доступа WLAN и т.д.

Модель драйвера WLAN состоит из следующих двух частей:

• Частота базовых возможностей: включает определение и общую реализацию слоя HDI WLAN, предоставляющую возможности установки MAC-адреса, получения MAC-адреса устройства, получения типа характеристики, установки мощности передачи и т.д.; модель драйвера WLAN предоставляет такие возможности для разработчиков драйверов, как создание/освобождение WifiModule, ассоциация/отмена ассоциации, запрос/освобождение NetBuf и т.д.
• Разработка разработчиком: требует выполнения конфигурации уровня платы и конфигурации частных данных чипа WLAN, а также реализации зарезервированных интерфейсов, таких как инициализация/отключение сети, открытие/закрытие сети и т.д.Для разработки драйверов WLAN на основе модели драйвера WLAN, см. руководство по разработке драйверов WLAN.

Связанные хранилища

Подсистема устройств

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

Пример:

Исходный текст (английский):

# Introduction

This document provides an overview of the drivers framework and its components.

Перевод (русский):

# Введение

Этот документ представляет собой обзор архитектуры драйверов и её компонентов.

Если вам нужен полный перевод одного из указанных README файлов, пожалуйста, предоставьте конкретный текст или скачайте документы самостоятельно и вставьте содержимое здесь для перевода.