Driver Development

Sensor driver development

  • Overview

Sensor is a common input device used to sense the state of the environment and achieve corresponding responses. Compared with the original Linux driver mode, OH implements the sensor driver in the HDF (Hardware Driver Foundation) layer. This implementation method can achieve one-time development and support deployment in different kernel environments, such as lightweight systems, small systems or standard Linux systems. In addition, in the HDF framework, different drivers can be managed uniformly, and each driver can provide services to the outside world. For the application layer, it only needs to call the HDI (Hardware Device Interface) interface to obtain the driver service capabilities.

Sensor Driven Model

The Sensor driver model based on the HDF driver framework in OpenHarmony is as follows:

FIRMWARE

The sensor driver model shields the differences in hardware devices and provides a stable sensor basic capability interface for the upper-level sensor service system, including sensor list query, sensor start and stop, sensor subscription and unsubscription, sensor parameter configuration and other functions.

The development of sensor device drivers is based on the HDF driver framework, combining the operating system abstraction layer (OSAL) and platform driver interface (such as I2C/SPI/UART bus and other platform resources) capabilities to shield the differences in bus resources between different operating systems and platforms, and achieve the goal of "one-time development, multi-system deployment" for sensor drivers.

The sensor driver model in OpenHarmony is divided into the following levels:

Hardware: This layer determines how the sensor device is connected to the CPU, what method the peripheral uses to communicate (such as I2C, SPI, GPIO, etc.), etc. Driver: This layer implements hardware peripheral drivers, including bindInit and realese functions in HdfDriverEntry, and ReadData in data OpsCall. HDI: Interface definition and implementation. The interface mainly includes all stable interfaces such as sensor information query, sensor start and stop, sensor subscription/unsubscription, sensor parameter configuration, etc., to simplify service development. Framework: Upper-level sensor service.

HCS Configuration

For different platforms, you need to modify the corresponding hcs file in the corresponding platform directory. The following example shows the modification method for adding a sensor module under the smt001 platform. Configure device_info.hcs File path: vendor/spacemit/smt001/hdf_config/khdf/device_info/device_info.hcs Configuration instructions: Add the following information in device_info.hcs.

Main field description:

policy: service policy. The value "0" means not to publish the service, the value "1" means to publish the service to the kernel state, and the value "2" means to publish the service to the user state. moduleName: the same as the moduleName in the HdfDriverEntry structure implemented by the driver. deviceMatchAttr: the private configuration information of the driver. serviceName: the service name, and the serviceName node will eventually be generated under the /dev/ node (the prerequisite for generating the node is that the policy is configured to be greater than or equal to 1).

Configure sensor_config.hcs

File path: vendor/spacemit/smt001/hdf_config/khdf/sensor/sensor_config.hcs Configuration instructions: Add the following content to sensor_config.hcs: #include "accel/accel_qm8658_config.hcs"

Configure accel_qm8658_config.hcs File path: vendor/spacemit/smt001/hdf_config/khdf/sensor/accel/accel_qm8658_config.hcs

Configuration instructions: Add a new folder accel and create a new file accel_qm8658_config.hcs. The file content is as follows:

#include"../sensor_common.hcs"
root{
    accel_qm8658_chip_config:sensorConfig{
        match_attr="hdf_sensor_accel_qm8658_driver";
        sensorInfo::sensorDeviceInfo{
            sensorName="accelerometer";
            vendorName="qmi8658";//maxstringlengthis16bytes
            sensorTypeId=1; //enum SensorTypeTag
            sensorId=1;//userdefinesensorid
            power=230;
        }
        sensorBusConfig::sensorBusInfo{
            busType=0; //0:i2c1:spi
            busNum=3;
            busAddr=0x6a;
            regWidth=1;//1btye
        }
        sensorIdAttr::sensorIdInfo{
            chipName="qm8658";
            chipIdRegister=0x00;
            chipIdValue=0x05;
        }
        sensorRegConfig{
            /*regAddr:registeraddress
            value:configregistervalue
            len:sizeofvalue
            mask:maskofvalue
            delay:configregisterdelaytime(ms)
            opsType:enumSensorOpsType0-none1-read2-write3-read_check4-update_bit
            calType:enumSensorBitCalType0-none1-set2-revert3-xor4-leftshift5-rightshift
            shiftNum:shiftbits
            debug:0-nodebug1-debug
            save:0-nosave1-save
            */
            /*regAddr,value,mask,len,delay,opsType,calType,shiftNum,debug,save*/
            initSeqConfig=[
                0x02,0x78, 0xff,1,5, 2,0,0,0,0,
                0x03,0x26, 0xff,1,5, 2,0,0,0,0,
                0x08,0x00,0x03,1,5, 2,0,0,0,0
            ];
            enableSeqConfig=[
                0x08,0x01,0x03,1,5, 2,0,0,0,0
            ];
            disableSeqConfig=[
                0x08,0x00,0x03,1,5, 2,0,0,0,0
            ];
        }
    }
}

Compile option modification

Add the following content in drivers/hdf_core/adapter/khdf/linux/model/sensor/Kconfig:

config DRIVERS_HDF_SENSOR_ACCEL_QM8658
    bool "Enable HDF accel qm8658 sensor driver"
    default n
    depends on DRIVERS_HDF_SENSOR_ACCEL
    help
        Answer Y to enable HDF accel qm8658 sensor driver.

Add the following content in drivers/hdf_core/adapter/khdf/linux/model/sensor/Makefile: obj-$(CONFIG_DRIVERS_HDF_SENSOR_ACCEL_QM8658)+=$(SENSOR_ROOT_DIR)/chipset/accel/accel_qm8658.o Modify the corresponding driver implementation file of Makefile as follows:

drivers/peripheral/sensor/chipset/accel/accel_qm8658.c
drivers/peripheral/sensor/chipset/accel/accel_qm8658.h

Kernel defconfig configuration

Add the following content to kernel/linux/spacemit_kernel-6.6/arch/riscv/configs/k1_defconfig file:

CONFIG_DRIVERS_HDF_SENSOR=y
CONFIG_DRIVERS_HDF_SENSOR_ACCEL=y
CONFIG_DRIVERS_HDF_SENSOR_ACCEL_QM8658=y

Application Code Directory Description

The interface implementations of the Sensor driver's external services are all in the drivers/peripheral/sensor path. The corresponding functions of this directory are described as follows:

/drivers/peripheral/sensor
├── hal
    └── include
    └── src
├── interfaces
    └── include
├── test
    └── unit
hal: HAL layer code for the sensor module  
include: Internal header files for the sensor module's HAL layer  
src: Implementation of the sensor module's HAL layer code  
interfaces: Driver capability interfaces provided by the sensor module to upper-layer services  
include: Interface definitions exposed by the sensor module  
test: Test code for the sensor module  
unit: Unit test code for the sensor module

Common Problem Solving

Confirm the accuracy of HCS configuration, including I2C bus, Sensor register initialization, Sensor enable, etc. Confirm whether the compilation options have been modified to compile it normally. If the application cannot be enabled, confirm whether the module needs to be configured with permissions and whether to touch hdf.hcs to change the timestamp.

TouchScreen driver development

Overview

TouchScreen is a common input device that senses the user's touch on the screen and responds accordingly. Compared with the original Linux driver mode, OpenHarmony implements the TouchScreen driver in the HDF layer. This implementation method can achieve one-time development and support deployment in different kernel environments, such as lightweight systems, small systems, or standard Linux systems. In addition, in the HDF framework, different drivers can be managed uniformly, and each driver can provide services to the outside world. For the application layer, it only needs to call the HDI interface to obtain the driver service capabilities.

TouchScreen driver model

The TouchScreen driver model based on the HDF driver framework in OpenHarmony is as follows:

FIRMWARE

The TouchScreen driver model in OpenHarmony is divided into the following layers: Hardware: This layer determines how the TouchScreen device is connected to the CPU, which IO ports the peripherals are configured through, what method (such as I2C, SPI, UART, etc.) is used for communication, etc. Kernel: This layer mainly selects the appropriate kernel (Linux/LiteOS/RTOS) according to the needs of the project; the OSAL APIs in the Kernel layer are mainly used to normalize different kernels, provide a standardized operation interface for the HDF Drivers layer, and shield the differences between different kernels from causing modifications to the upper layer to the greatest extent.

HDF Drivers: This layer implements hardware peripheral drivers and completes the initialization of different peripherals. For example, TouchScreen needs to implement the Init, Detect, Resume, Suspend, DataHandle, and UpdateFirmware functions in struct TouchChipOps ops. Input HDI: This layer implements driver interface capabilities such as TouchScreen device management, business control, and data reporting, and provides hardware driver capabilities for the upper layer. Framework: Upper-layer TouchScreen services.

HCS Configuration

For different platforms, you need to modify the corresponding hcs file in the corresponding platform directory. The following example shows the modification method for adding a GT9271 touch screen under the smt001 platform.

Configure device_info.hcs File path: vendor/spacemit/smt001/hdf_config/khdf/device_info/device_info.hcs Configuration instructions: Add the following content to device_info.hcs.

Main field description:

policy: service policy. The value "0" means not to publish the service, the value "1" means to publish the service to kernel mode, and the value "2" means to publish the service to kernel user mode. moduleName: the same as the moduleName in the HdfDriverEntry structure implemented by the driver. deviceMatchAttr: the private configuration information of the driver. serviceName: the service name, and the serviceName node will eventually be generated under the /dev/ node (the prerequisite for generating the node is that the policy is configured to be greater than or equal to 1).

Configure input_config.hcs

File path: vendor/spacemit/smt001/hdf_config/khdf/input/input_config.hcs Configuration instructions: Modify the following configuration in input_config.hcs.

Modify the configuration and add chip4 in the chipConfig field to indicate a new touch screen driver.

Compile option modification

The following takes the driver of the newly added touch screen GT9271 as an example to introduce the relevant compilation option modifications.

Add the following content in drivers/hdf_core/adapter/khdf/linux/model/input/Kconfig:

config DRIVERS_HDF_TP_10P10_GT9271
    bool "Enable HDF tp10P10 GT9271

UART driver development

Overview

UART refers to Universal Asynchronous Receiver/Transmitter. In the HDF framework, the interface adaptation mode of UART adopts the independent service mode. In this mode, each device object will independently publish a device service to handle external access. After the device manager receives the access request from the API, it extracts the parameters of the request to achieve the purpose of calling the corresponding internal method of the actual device object. The advantage of the independent service mode is that it can directly use the service management capabilities of HDFDeviceManager, but it also has certain shortcomings, that is, it is necessary to configure the device node for each device separately, which will increase the memory usage. The structure diagram of the UART independent service mode is shown in the figure below.

FIRMWARE

DTS Configuration

Configuration Instructions

Configure the corresponding serial port device node, for example, configure serial port 2:

&uart2 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_uart2>;
    status = "okay";
};

HCS Configuration

For different platforms, you need to modify the corresponding hcs file in the corresponding platform directory.

Configuring device_info.hcs

File Path

vendor/spacemit/xxx/hdf_config/khdf/device_info/device_info.hcs

Configuration Instructions

Add the following content to device_info.hcs:

During the configuration process, pay attention to the following points:

Policy: Set the node to hide or show. The value "1" means hiding, that is, HDF nodes are not displayed in the dev directory; the value "2" means showing, that is, HDF nodes are displayed in the dev directory. Permission: file permissions. Priority: startup sequence, the larger the value, the later it starts. The suffix "2" of "HDF_PLATFORM_UART_2" in serviceName: corresponds to the port parameter of the application open function.

deviceMatchAttr: must be consistent with the match_attr value in rk3568_uart_config.hcs.

Configure rk3568_uart_config.hcs

File Path

vendor/spacemit/xxx/hdf_config/khdf/platform/rk3568_uart_config.hcs

Configuration Instructions

Modify rk3568_uart_config.hcs as follows:

During the configuration process, pay attention to the following points:

The suffix "0x0002" in device_uart_0x0002 is the serial port number, starting from 0x0000. Num: It is combined with the driver_name value "ttyS" to form the driver device name, such as ttyS9.

If the driver device name does not start with ttyS, for example, the driver device names of serial ports A to D of the RK3568A board start with ttyXRUSB, you need to modify the driver_name. For example:

device_uart_0x0002 :: uart_device {
    num = 9;
    driver_name = "ttyXRUSB"
    match_attr = "rockchip_rk3568_uart_9";
}

If you do not modify the driver_name, the driver_name value in the template, that is, "ttyS", is used by default.

Application usage process

For details on how to use the UART API interface, see the OHOS API documentation.

Commonly used UART APIs are described as follows: uartOpen(port: number): port is the suffix number of serviceName in the "Configure device_info.hcs" section. uartSetBaud: Set the baud rate of the specified serial port. uartSetAttribute: Set the basic attributes of the specified serial port.

Common Problem Solving

Confirm whether there is a tty device generated under /dev/. If not, please refer to the "DTS Configuration" section to check the configuration. Confirm whether there is HDF_PLATFORM_UART_x generated under /dev/ (x is the configured service_name). If not, please refer to the "HCS Configuration" section to check the configuration.

Data read and write does not work: Short RX and TX, and test through two hdc terminals, one cat tty node and one echo tty node. If the cat terminal does not receive data: Please make sure that the pinctrl - 0 in the "DTS Configuration" section selects the correct serial port pin. Check and ensure that the hardware circuit is normal.

Sending is normal, but reading data is lost: Please check whether there are other applications grabbing data.

Check for hardware interference.