Digital Potentiometer
Digital Potentiometer Linux Driver.
Supported Devices
Evaluation Boards
PMOD-DPOT
Reference Circuits
Description
The ad525x_dpot driver exports a simple sysfs interface. This allows you to work with the immediate resistance settings as well as update the saved startup settings. Access to the factory programmed tolerance is also provided, but interpretation of this settings is required by the end application according to the specific part in use.
Source Code
Status
Files
Every supported wiper gets an rdacN file. eepromN exists only on parts flagged for EEPROM commands, toleranceN only on parts with factory tolerance readback, and otpN/otpNen only on OTP-capable parts. Some parts also expose inc_all, dec_all, inc_all_6db and dec_all_6db. Wiper indices follow the part-specific mask and need not start at zero or be contiguous.
The eeprom files program the nonvolatile startup value on devices that provide EEPROM. Use rdac for repeated runtime adjustments: EEPROM write endurance is limited (e.g. AD5259 is qualified to 100,000 cycles). OTP and 50-TP parts use separate one-time/limited-time programming mechanisms with their own endurance limits.
The rdac files program the immediate wiper code as unsigned decimal. Values above the part-specific maximum are clamped to that maximum. On write-only parts, reads return a software cache initialized to midscale, not a hardware readback. The write handlers do not propagate bus-write failures, so a successful shell write alone does not verify programming.
The tolerance files are the read-only factory programmed tolerance settings and may vary greatly on a part-by-part basis. For exact interpretation of this field, please consult the datasheet for your part. This is presented as a hex file for easier parsing.
Function |
File |
|---|---|
driver |
|
i2c bus support |
|
spi bus support |
|
include |
Hardware configuration
Adding Linux driver support
Kernel configuration
Configure kernel with make menuconfig (alternatively use make xconfig or
make qconfig)
Note
The ad525x_dpot driver depends on CONFIG_SPI or CONFIG_I2C.
Device Drivers --->
[*] Misc devices --->
<*> Analog Devices Digital Potentiometers
<*> support I2C bus connection
<*> support SPI bus connection
Platform-data configuration
Example platform device initialization
For compile time configuration, it’s common Linux practice to keep board- and application-specific configuration out of the main driver file, instead putting it into the board support file.
For devices on custom boards, as typical of embedded and SoC-(system-on-chip)
based hardware, Linux uses platform_data to point to board-specific structures
describing devices and how they are connected to the SoC. This can include
available ports, chip variants, preferred modes, default initialization,
additional pin roles, and so on. This shrinks the board-support packages (BSPs)
and minimizes board and application specific #ifdefs in drivers.
Example Platform / Board file (I2C Interface)
Unlike PCI or USB devices, I2C devices are not enumerated at the hardware level. Instead, the software must know which devices are connected on each I2C bus segment, and what address these devices are using. For this reason, the kernel code must instantiate I2C devices explicitly. There are different ways to achieve this, depending on the context and requirements. However the most common method is to declare the I2C devices by bus number.
This method is appropriate when the I2C bus is a system bus, as in many
embedded systems, wherein each I2C bus has a number which is known in advance.
It is thus possible to pre-declare the I2C devices that inhabit this bus. This
is done with an array of struct i2c_board_info, which is registered by
calling i2c_register_board_info().
So, to enable such a driver one need only edit the board support file by adding
an appropriate entry to i2c_board_info.
For more information see: How to instantiate I2C devices
static struct i2c_board_info __initdata bfin_i2c_board_info[] = {
#if defined(CONFIG_AD525X_DPOT) || defined(CONFIG_AD525X_DPOT_MODULE)
{
I2C_BOARD_INFO("ad5245", 0x2c),
},
{
I2C_BOARD_INFO("ad5245", 0x2d),
},
#endif
}
Example Platform / Board file (SPI Interface)
Unlike PCI or USB devices, SPI devices are not enumerated at the hardware level. Instead, the software must know which devices are connected on each SPI bus segment, and what slave selects these devices are using. For this reason, the kernel code must instantiate SPI devices explicitly. The most common method is to declare the SPI devices by bus number.
This method is appropriate when the SPI bus is a system bus, as in many
embedded systems, wherein each SPI bus has a number which is known in advance.
It is thus possible to pre-declare the SPI devices that inhabit this bus. This
is done with an array of struct spi_board_info, which is registered by
calling spi_register_board_info().
For more information see: Overview of Linux kernel SPI support
static struct spi_board_info bfin_spi_board_info[] __initdata = {
#if defined(CONFIG_AD525X_DPOT) || defined(CONFIG_AD525X_DPOT_MODULE)
{
.modalias = "ad5291",
.max_speed_hz = 5000000, /* max spi clock (SCK) speed in HZ */
.bus_num = 0,
.chip_select = 1,
},
#endif
};
Driver testing
Locate the device in your sysfs tree. This is probably easiest by going into the common i2c directory and locating the device by the i2c slave address.
# ls /sys/bus/i2c/devices/
0-0022 0-0027 0-002f
So assuming the device in question is on the first i2c bus and has the slave address of 0x2f, we descend (unrelated sysfs entries have been trimmed).
# ls /sys/bus/i2c/devices/0-002f/
eeprom0 rdac0 tolerance0
You can use simple reads/writes to access these files:
# cd /sys/bus/i2c/devices/0-002f/
# cat eeprom0
0
# echo 10 > eeprom0
# cat eeprom0
10
# cat rdac0
5
# echo 3 > rdac0
# cat rdac0
3