>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 | >+-------------------------------+ I will look into making a SocketCAN proof-of-concept based on the architecture shown in the picture above. If there are any suggestions or questions please don't hesitate to contact me or reply in this thread.
