18 个回答
在candev里增加can过滤器信息
这个是如何实现？
在candev里增加can过滤器信息
这个是如何实现？
仔细想了一下，第三个方法实现不了，目前想到的就两个方法：
１、增加rt_can_read接口，该接口传入过滤器编号。
代码: 全选
２、
rt_size_t rt_device_read(rt_device_t dev,
rt_off_t pos,
void *buffer,
rt_size_t size)
把pos作为过滤器编号传入。
看起来pos作为过滤器ID的方法可能对使用者友好一些，阅读上也比较好理解一些。
不知道部分控制器的过滤器ID在使用过滤中是否会变化？或是过滤器并不以数字ID(0,1,2...N)的形式表现。
如果有，可能要在驱动中限制一下，并转成对应的过滤器。
不知道部分控制器的过滤器ID在使用过滤中是否会变化？或是过滤器并不以数字ID(0,1,2...N)的形式表现。
如果有，可能要在驱动中限制一下，并转成对应的过滤器。
那就改成以pos传入，然后有可能会对个别芯片的过滤器编号进行转换
这里会有个新问题
就是APP设置的过滤器编号如何得到？
是设置后由驱动分配或给出？还是APP指定使用某个过滤器？
就是APP设置的过滤器编号如何得到？
是设置后由驱动分配或给出？还是APP指定使用某个过滤器？
这里会有个新问题
就是APP设置的过滤器编号如何得到？
是设置后由驱动分配或给出？还是APP指定使用某个过滤器？
编号有可能是动态变化的，由回调通过hdr参数传出来：
static rt_err_t lpccanind(rt_device_t dev, void *args, rt_int32_t hdr, rt_size_t size)
{
.............
return RT_EOK;
}
这个回调在设置过滤器时传入：
struct rt_can_filter_item filter1item[] =
{
LPC_CAN_AF_STD_GRP_INIT(8, 9, lpccanind, RT_NULL),
LPC_CAN_AF_STD_GRP_INIT(10, 11, lpccanind, RT_NULL),
LPC_CAN_AF_STD_GRP_INIT(6, 7, lpccanind, RT_NULL),
..................
LPC_CAN_AF_EXT_INIT(4, lpccanind, RT_NULL),
};
类似linux的socket接口方式，那边是怎么处理的？如果是socket接口，是否有部分借鉴的意义？
不如也实现成socket的方式
然并卵，每个芯片需要自己读参考手册，去设置过滤器。
手册看明白了，设置过滤器轻而易举，没看明白，有规范也白搭。
手册看明白了，设置过滤器轻而易举，没看明白，有规范也白搭。
我尝试一下实现成socket方式试试
然并卵，每个芯片需要自己读参考手册，去设置过滤器。
手册看明白了，设置过滤器轻而易举，没看明白，有规范也白搭。
这个规范就是要对用户隐藏过滤器实现的细节，对于不同的平台，应用调用相同的接口。
我尝试一下实现成socket方式试试
这部分我觉得是可以考虑先从使用的角度着手的，例如说，在Linux下，使用socket的方式来进行CAN编程是怎么样的？有了使用的API（模型），再依据这样的方式来实现API就容易了。
我尝试一下实现成socket方式试试
双手双脚支持 我弄的canfestival就差一个好用的can接口了。
我尝试一下实现成socket方式试试
双手双脚支持 我弄的canfestival就差一个好用的can接口了。
你的双手双脚都过来一起做吧 [s:175]
然并卵，每个芯片需要自己读参考手册，去设置过滤器。
手册看明白了，设置过滤器轻而易举，没看明白，有规范也白搭。
这个规范就是要对用户隐藏过滤器实现的细节，对于不同的平台，应用调用相同的接口。
写规范是让厂商提供驱动
可如果变成自己提供驱动
就有点操蛋了
不过我觉得可以参考那个SPI的方式，提供几个open read write control函数接口倒是可以
这样简单而且实用
我尝试一下实现成socket方式试试
双手双脚支持 我弄的canfestival就差一个好用的can接口了。
你的双手双脚都过来一起做吧 [s:175]
这个首先得规范下网络设备及相关接口，得把这部分从lwip里面分离出来
这个首先得规范下网络设备及相关接口，得把这部分从lwip里面分离出来
看新的dfs_lwip；
撰写答案
请登录后再发布答案，点击登录
