A digit-to-analog converter (DAC) is a device that converts a digital signal into an analog signal in electronics.
The DAC APIs provide a set of methods for DAC data transfer, including:
- Opening or closing a DAC device
- Setting the target digital-to-analog (DA) value
### Basic Concepts
The DAC module provides the output channel for the process control computer system. It connects to the executor to implement automatic control of the production process. It is also an important module in the analog-to-digital converter using feedback technologies.
- Resolution
The number of binary bits that can be converted by a DAC. A greater number of bits indicates a higher resolution.
- Conversion precision
Difference between the actual output value of the DAC and the theoretical value when the maximum value is added to the input end. The conversion precision of a DAC converter varies depending on the structure of the chip integrated on the DAC and the interface circuit configuration. The ideal conversion precision value should be as small as possible. To achieve optimal DAC conversion precision, the DAC must have high resolution. In addition, errors in the devices or power supply of the interface circuits will affect the conversion precision. When the error exceeds a certain degree, a DAC conversion error will be caused.
- Conversion speed
The conversion speed is determined by the setup time. The setup time is the period from the time the input suddenly changes from all 0s to all 1s to the time the output voltage remains within the FSR ± ½LSB (or FSR ± x%FSR). It is the maximum response time of the DAC, and hence used to measure the conversion speed.
The full scale range (FSR) is the maximum range of the output signal amplitude of a DAC. Different DACs have different FSRs, which can be limited by positive and negative currents or voltages.
The least significant byte (LSB) refers to bit 0 (the least significant bit) in a binary number.
### Working Principles
In the Hardware Driver Foundation (HDF), the DAC module uses the unified service mode for API adaptation. In this mode, a device service is used as the DAC manager to handle access requests from the devices of the same type in a unified manner. The unified service mode applies to the scenario where there are many device objects of the same type. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services. The figure below shows the unified service mode.
The DAC module is divided into the following layers:
- The interface layer provides APIs for opening or closing a device and writing data.
- The core layer provides the capabilities of binding, initializing, and releasing devices.
- The adaptation layer implements other functions.
NOTE<br/>The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer.
Currently, the DAC module supports only the kernels (LiteOS) of mini and small systems.
## Development Guidelines
### When to Use
The DAC module converts digital signals into analog signals in the form of current, voltage, or charge. It is mainly used in audio devices. Audio players and headsets use the DAC module as the digital-to-analog conversion channels.
### Available APIs
The table below describes the APIs of the DAC module. For more details, see API Reference.
A digit-to-analog converter (DAC) is a device that converts a digital signal into an analog signal in electronics.
### Basic Concepts<a name="3"></a>
The DAC module supports development of digital-to-analog conversion. The DAC module provides the output channel for the process control computer system. It connects to the executor to implement automatic control of the production process. It is also an important module in the analog-to-digital converter using feedback technologies.
- Resolution
The number of binary bits that can be converted by a DAC. A greater number of bits indicates a higher resolution.
- Conversion precision
Difference between the actual output value of the DAC and the theoretical value when the maximum value is added to the input end. The conversion precision of a DAC converter varies depending on the structure of the chip integrated on the DAC and the interface circuit configuration. The ideal conversion precision value should be as small as possible. To achieve optimal DAC conversion precision, the DAC must have high resolution. In addition, errors in the devices or power supply of the interface circuits will affect the conversion precision. When the error exceeds a certain degree, a DAC conversion error will be caused.
- Conversion speed
The conversion speed is determined by the setup time. The setup time is the period from the time the input suddenly changes from all 0s to all 1s to the time the output voltage remains within the FSR ± ½LSB (or FSR ± x%FSR). It is the maximum response time of the DAC, and hence used to measure the conversion speed.
The full scale range (FSR) is the maximum range of the output signal amplitude of a DAC. Different DACs have different FSRs, which can be limited by positive and negative currents or voltages.
The least significant byte (LSB) refers to bit 0 (the least significant bit) in a binary number.
### Working Principles<a name="4"></a>
In the Hardware Driver Foundation (HDF), the DAC module uses the unified service mode for API adaptation. In this mode, a device service is used as the DAC manager to handle access requests from the devices of the same type in a unified manner. The unified service mode applies to the scenario where there are many device objects of the same type. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services. The figure below shows the unified service mode.
The DAC module is divided into the following layers:
- The interface layer provides APIs for opening or closing a device and writing data.
- The core layer provides the capabilities of binding, initializing, and releasing devices.
- The adaptation layer implements other functions.
NOTE<br/>The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer.
**Figure 1** Unified service mode<aname="fig14423182615525"></a>
![](figures/unified-service-mode.png"DAC unified service mode")
### Constraints<a name="5"></a>
Currently, the DAC module supports only the kernels (LiteOS) of mini and small systems.
## Development Guidelines<a name="6"></a>
### When to Use<a name="7"></a>
The DAC module is used for digital-to-analog conversion, audio output, and motor control. The DAC driver is used when the digital signals input by the DAC module are converted into analog signals to output.
### Available APIs<a name="8"></a>
The **DacMethod** is used to call the DAC driver functions.
| write | **device**: pointer to the DAC controller at the core layer.<br>**channel**: channel ID, which is of the uint32_t type.<br>val: data to write, which is of the uint32_t type.| - | HDF_STATUS| Writes the target digit-to-analog (DA) value.|
| start | **device**: pointer to the DAC controller at the core layer. | - | HDF_STATUS| Starts a DAC device. |
| stop | **device**: pointer to the DAC controller at the core layer. | - | HDF_STATUS| Stops a device. |
### How to Develop<a name="9"></a>
The DAC module adaptation procedure is as follows:
- Instantiate the driver entry.
- Configure attribute files.
- Instantiate the APIs of the core layer.
- Debug the driver.
1. Instantiate the driver entry.
Instantiate the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type (defined in **hdf_device_desc.h**), and the value of **moduleName** must be the same as that in **device_info.hcs**. In the HDF, the start address of each **HdfDriverEntry** object of all loaded drivers are collected to form a segment address space similar to an array for the upper layer to invoke.
Generally, the HDF calls the **Init()** function to load the driver. If **Init()** fails to be called, the HDF calls **Release()** to release driver resources and exit.
```
static struct HdfDriverEntry g_dacDriverEntry = {
.moduleVersion = 1,
.Init = VirtualDacInit,
.Release = VirtualDacRelease,
.moduleName = "virtual_dac_driver",// (Mandatory) The value must be the same as that in the .hcs file.
};
HDF_INIT(g_dacDriverEntry); // Call HDF_INIT to register the driver entry with the HDF.
```
2. Configure attribute files.
- Add the device node description to the **vendor/hisilicon/hispark_taurus/hdf_config/device_info/device_info.hcs** file.
The device attribute values are closely related to the driver implementation and the default values or restriction ranges of the **DacDevice** members at the core layer, for example, the number of device channels and the maximum transmission speed.
In the unified service mode, the first device node in the **device_info.hcs** file must be the DAC manager. The parameters must be set as follows:
| policy | **0**, which indicates that no service is published.|
| priority | Driver startup priority. The value range is 0 to 200. A larger value indicates a lower priority. If the priorities are the same, the device loading sequence is not ensured.|
| permission | Driver permission.|
| moduleName | The value is **HDF_PLATFORM_DAC_MANAGER**.|
| serviceName | The value is **HDF_PLATFORM_DAC_MANAGER**.|
| deviceMatchAttr | Reserved.|
Configure DAC controller information from the second node. This node specifies a type of DAC controllers rather than a specific DAC controller. In this example, there is only one DAC device. If there are multiple DAC devices, you need to add the **deviceNode** information to the **device_info** file and add the corresponding device attributes to the **dac_config** file.
**device_info.hcs** configuration reference
```
root {
device_dac :: device {
// device0 is the DAC manager.
device0 :: deviceNode {
policy = 0;
priority = 52;
permission = 0644;
serviceName = "HDF_PLATFORM_DAC_MANAGER";
moduleName = "HDF_PLATFORM_DAC_MANAGER";
}
}
// dac_virtual is the DAC controller.
dac_virtual :: deviceNode {
policy = 0;
priority = 56;
permission = 0644;
moduleName = "virtual_dac_driver"; // (Mandatory) Driver name, which must be the same as moduleName in the driver entry.
serviceName = "VIRTUAL_DAC_DRIVER"; // (Mandatory) Unique name of the service published by the driver.
deviceMatchAttr = "virtual_dac"; // (Mandatory) Controller private data, which must be same as that of the corresponding controller in dac_config.hcs.
}
}
```
- Configure the **dac_test_config.hcs** file.
Add a file, for example, **vendor/vendor_hisilicon/hispark_taurus/hdf_config/hdf_test/dac_test_config.hcs** and configure driver parameters.
```
root {
platform {
dac_config {
match_attr = "virtual_dac"; // (Mandatory) The value must be the same as that of deviceMatchAttr in device_info.hcs.
template dac_device {
deviceNum = 0; // Device number.
validChannel = 0x1; // Valid channel 1.
rate = 20000; // Transmission speed.
}
device_0 :: dac_device {
deviceNum = 0; // Device number.
validChannel = 0x2; // Valid channel 2.
}
}
}
}
```
3. Instantiate the APIs of the core layer.
- Initialize the **DacDevice** object.
Initialize the **DacDevice** member in the **VirtualDacParseAndInit** function.
```
// Custom structure of the virtual driver
struct VirtualDacDevice {
// DAC device structure
struct DacDevice device;
// DAC device number
uint32_t deviceNum;
// Valid channel
uint32_t validChannel;
// DAC rate
uint32_t rate;
};
// Parse and initialize the **DacDevice** object of the core layer.
HDF_LOGE("%s: add Dac controller failed! ret = %d", __func__, ret);
// Release the virtual space.
OsalMemFree(virtual);
// Set the virtual pointer to null.
virtual = NULL;
return ret;
}
return HDF_SUCCESS;
}
```
- Custom structure reference
The custom structure holds parameters and data for the driver. Define the custom structure based on the function parameters of the device. The HDF reads the values in the **dac_config.hcs** file using the **DacTestReadConfig()** function and initializes the structure members using **DeviceResourceIface()**. Some important values, such as the device number and bus number, are also passed to the **DacDevice** object at the core layer.
```
struct VirtualDacDevice {
struct DacDevice device;// (Mandatory) Control object at the core layer. For details, see the description below.
For details about **DacMethod**, see [Available APIs](#section752964871810).
- **Init** function
Input parameters:
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return value:
HDF_STATUS (The table below lists some status. For details about other status, see HDF_STATUS in the /drivers/framework/include/utils/hdf_base.h file.)
**HdfDeviceObject**, an interface parameter exposed by the driver, contains the .hcs configuration file information.
Return value
This function returns no value.
Function description:
Releases memory and deletes the controller. This function assigns a value to the **Release** API in the driver entry structure. If the HDF fails to call the **Init** function to initialize the driver, the **Release** function can be called to release driver resources. All forced conversion operations for obtaining the corresponding object can be successful only when the **Init** function has the corresponding value assignment operations.
