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 | > +---------+----------+-----------+ > >
