>I believe that both sides would be the same. Both would use BSD sockets, >SocketCAN would be added to the network stacks, and the CAN drivers would be a >network drivers. > >Your picture shows the existing implementation using character drivers. >SocketCAN is intended to be integrated into the network.
Thanks for the quick response, indeed you're right the CAN drivers would become network drivers and in the BSD sockets layer we can add the PF_CAN protocol. However my question is then, would there still be a need for need for CAN using character drivers (and userspace api)? If so, do we have to make 2 separate HW drivers, one for CAN using character devices and one for CAN using SocketCAN? Or does the current infrastructure support both? The reason why I'm asking this is to think about trade-offs between compatibility, realtime performance and maintainability. >I amn't familiar with CAN, but is it possible to implement a general CAN MAC >driver on top of CAN CHAR driver like this? >+-------------------------------+ >| NuttX Network driver | >| +------------+ +------------+ | >| |Syscall glue| |BSD Socket | | >| | | |glue | | >| +------------+ +------------+ | >+-------------------------------+ >+-------------------------------+ file_* +-------------------------------+ >| Hardware MAC driver |---------->| NuttX CAN Driver (can.c) | >+-------------------------------+ | +------------+ >+-------------------------------+ +------------+ | > | |Syscall glue| |Char driver | | > | | | |glue | | > | +------------+ +------------+ | > +-------------------------------+ > +-------------------------------+ > | Hardware CAN driver | > +-------------------------------+ > So we just need write one CAN driver, but the user can select socket or char > as they want. From ease-of-implementation perspective that would be the way to go. However this would mean that a CAN frame would go through the CAN driver -> Char driver -> VFS -> Socket -> user space. This would add unnecessary delay and jitter which would be certainly worse. Ideally I would implement it as shown below. The question is though then how do deal with existing CAN character device implementation? NuttX SocketCAN implementation Proposal +-------------------------------+ | Application | +-------------------------------+ +-------------------------------+ | POSIX Interface | +-------------------------------+ +-------------+ +-------------+ |System calls | |BSD socket | | | |net/sockets | +-------------+ +-------------+ +-------------------------------+ | NuttX Network driver | | +------------+ +------------+ | | |Syscall glue| |BSD Socket | | | | | |glue PF_CAN| | | +------------+ +------------+ | +-------------------------------+ +-------------------------------+ | NEW Hardware CAN driver | +-------------------------------+ +-------------------------------+ |OS (sched/), memory manager | |(mm/), common libraries (libs/)| +-------------------------------+ +-------------------------------+ | Hardware | +-------------------------------+
