I just checked Linux variants for CAN. I'm not sure that those are all, but
at least here is what I found:
1. can4linux project -- a serial driver for CAN
2. SocketCAN project -- a network driver for CAN
Each is using its own structure to describe CAN frames and each is using
its own structures to
There is another precedent here: nuttx/wireless/ieee802154. For that radio
family, there are 3 applications interfaces: There is a dumb serial
driver and a network driver. The network driver supports both a simple raw
interface and also an IPv6 LoPAN interface.
There is nothing that can be don
The main reason why I'm raising this topic is that I think that the CAN
lower part should be a standard way the upper layer talks to CAN HW and the
upper half should perform the translation to a char or netdev interface.
Now that is not true. Basically I'm looking into the minimal set of
functions
Hi Petro,
I understand having 2 upper separate layers for CAN isn't welcomed.
However I don't see any real particular gains for a generic can_ops_s
for both the SocketCAN and CAN Char driver.
For example SocketCAN net_driver_s interface uses the dev->d_buf
interface to transfer data and then in
Hello,
Recently I've been working on LIN bus support with SAME70 based device. In
general the integration was done smoothly and I would like to contribute my
work to the community. The LIN is pretty similar to CAN and in Linux is
abstracted as a SocketCAN device. During my integration I chose a mo
