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 describe CAN frames as well as a separate implementation for HW access to each CAN peripheral / chip. As Peter pointed out the SocketCAN tries to minimize latencies and number of copying by allocation IOB and using it upcasted to a target frame structure while CAN char tries to minimize the memory used by making as packed structure as possible. So not much parallels with the radio family here. So it seems that we need to choose and most likely SocketCAN should be the path to move forward. I'm just having a concerns that network subsystem is much "heavier" compared to a CAN serial driver and systems that are low in memory will not be able to use it. Best regards, Petro вт, 26 квіт. 2022 р. о 01:31 Gregory Nutt <spudan...@gmail.com> пише: > 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 done with the serial driver that cannot be > done with the network raw packet interface. IOCTL commands, for example, > are handled by the same logic. They are totally redundant. The serial > driver is a remnant of an older architectural concept that evolved over > time as documented here: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397 > (focuses on WiFI and Bluetooth as well as 802.15.4 radios). > > I think that same policy on CAN networking should apply here. > Architectural consistency is an important property of a well-designed > operating system. > > Removing the IEEE802.15.4 serial driver at this point would be a difficult > thing since it is entangled with the i8sak application so intimately. > However, I doubt there is such entanglement with the CAN serial driver > other than a few examples and perhaps some utilities. So one option would > be to replace the CAN serial driver with a network raw socket type. > > How does Linux deal with the CAN low level interface? My bet would be > through a raw socket. Commonality with Linux in at least naming would be a > good thing too. > > > > > On Mon, Apr 25, 2022 at 3:49 PM Petro Karashchenko < > petro.karashche...@gmail.com> wrote: > > > 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 that I need to implement for LIN without knowing what is > > "stilling" on top of it. I believe that it should be the right way of > doing > > things. From a user perspective I do not see any reason in deprecation of > > CAN char driver. I'm not sure how it is done for Linux, I mean is > SocketCAN > > the only interface to CAN bus in Linux? > > > > The deprecation of the CAN char driver could probably solve the issue, > but > > I see that there are many good things in CAN char driver that are not > fully > > integrated with SocketCAN in NuttX. Like HW message filtering (that is > > currently managed by the SW SocketCAN layer). > > > > Best regards, > > Petro > > > > вт, 26 квіт. 2022 р. о 00:06 Peter van der Perk < > peter.vanderp...@nxp.com> > > пише: > > > > > 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 invokes a callback to the actual > > > driver. > > > Whereas CAN Char uses the following prototype to call the driver > directly > > > int (*co_send)(FAR struct can_dev_s *dev, FAR struct can_msg_s *msg); > > > If we would manage to unify this we would probably have to rewrite the > > > net/can upper driver to facilitate this. > > > > > > Furthermore modifying the CAN Char can_hdr_s and can_msg_s data > > > structure would break backwards compatibility with all applications > using > > > the existing CAN char driver. > > > > > > I'm not aware on the usage of the current CAN char driver is in > general. > > > Another option instead of breaking the backwards compatibility for the > > > existing systems would be deprecating CAN Char and try to encourage > > > the use of the SocketCAN driver and maybe migrate some platforms over > as > > > well. > > > > > > I've made a quick overview of all NuttX architectures implementing a > CAN > > > driver using both upper layers. > > > > > > +---------+----------+-----------+ > > > | | Char CAN | SocketCAN | > > > +---------+----------+-----------+ > > > | AM335X | Yes | No | > > > +---------+----------+-----------+ > > > | IXMRT | No | Yes | > > > +---------+----------+-----------+ > > > | SAMA5 | Yes | No | > > > +---------+----------+-----------+ > > > | SAMV7 | Yes | No | > > > +---------+----------+-----------+ > > > | STM32L4 | Yes | No | > > > +---------+----------+-----------+ > > > | LPC43 | Yes | No | > > > +---------+----------+-----------+ > > > | STM32 | Yes | Yes | > > > +---------+----------+-----------+ > > > | Kinetis | No | Yes | > > > +---------+----------+-----------+ > > > | S32K1XX | No | Yes | > > > +---------+----------+-----------+ > > > | STM32F7 | Yes | No | > > > +---------+----------+-----------+ > > > | STM32H7 | No | Yes | > > > +---------+----------+-----------+ > > > | STM32L4 | Yes | No | > > > +---------+----------+-----------+ > > > | ESP32C3 | Yes | No | > > > +---------+----------+-----------+ > > > | | 9/13 | 5/13 | > > > +---------+----------+-----------+ > > > > > > > > >
