用属性文件吧，缺点是不加自动搜索文件名代码的话，上层代码访问属性文件的路径要随着平台变化（因为不同平台的i2c设备目录名称是不一样的） cascle 发表于 2013-08-11 19:03 static/image/common/back.gif
用属性文件吧，缺点是不加自动搜索文件名代码的话，上层代码访问属性文件的路径要随着平台变化（因为不同平 ...
能否给个示例代码？ 回复 12# 虫虫2003 static ssize_t xxx_store_caliberate(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
const ptrdiff_t offset = attr - s_attr;
int set_value = simple_strtoul(buf, NULL, 10);
switch(offset)
{
case 0:
case 1:
}
}
static ssize_t xxx_show_caliberate(struct device *dev,
struct device_attribute *attr, char *buf)
{
const ptrdiff_t offset = attr - s_attr;
switch(offset)
{
case 0:
case 1:
}
}
#define XXX_ATTR(_name) \
{ \
.attr = { .name = #_name, .mode = S_IRUGO | S_IWUSR | S_IWGRP, },\
.show = xxx_show_caliberate, \
.store = xxx_store_caliberate, \
}
static struct device_attribute s_attr[] = {
XXX_ATTR(a),
XXX_ATTR(b),
}; 大体的架子就是这样，至于具体的细节，自己google下属性文件怎么写吧，都很好找的 create和remove我就不加了 本帖最后由 jmyu2006 于 2013-09-26 13:28 编辑
回复 7# 虫虫2003
我也有此疑问。不过目前的理解就是：没有什么好的办法。要么适配Linux I2C子系统，要么自行另起炉灶。你举的海思的例子，说明它这个BSP包做的好，有层次，做到了OS无关。其实我个人觉得驱动就应该像海思平台那样写：Linux Kernel <-- Linux Driver subystem <-- Linux Driver Adapter <-- OS independent Driver。 这样，利用最低一层的OS independent Driver，各种驱动就可以方便地进行不同OS下的移植。试想一下，一颗芯片做出来，自然要写芯片驱动来进行测试，这个时候是没必要用到Linux这个庞然大物的，直接写些功能函数来驱动硬件就可以了，只要函数接口设计成低耦合性，那到时候做Linux驱动时，完全可以做到复用这个函数，只是要进一步包装一层，来适配Linux而已。如果直接就照Linux的结构来写，那就会出现楼主目前的疑问了。
页:
1
[2]