+pavel -----Original Message----- From: Peter Van Der Perk [mailto:peter.vanderp...@nxp.com] Sent: Tuesday, February 11, 2020 6:58 AM To: dev@nuttx.apache.org Subject: NuttX SocketCAN implementation
Hi all, This is a follow up to the SocketCAN integration into NuttX discussion. As discussed before we proposed the idea to include SocketCAN support in NuttX to provide a generic well-known interface for CAN transmission. The initial feedback was great and Gregory Nutt looked into the possibility to integrate SocketCAN (socket family and legal issues). The other feedback we also got was about the realtime behavior which might suffer due to SocketCAN. To measure the impact in realtime behavior I created a testbed using Zephyr RTOS, which already implemented SocketCAN in their RTOS. The results of this testbed have been posted here https://forum.uavcan.org/t/socketcan-api-on-a-rtos/750. To summarize: from the Zephyr SocketCAN I noticed a delay increase from interrupt to userspace application of ~ 55us and measured jitter didn't increase and stayed < 0.001us. I would like gather feedback if 65us is acceptable and if the NuttX network stack might perform better or worse than that. Furthermore I've got some questions about some implementation details, below the figure shows my estimated guess of the current NuttX CAN implementation and the NuttX Ethernet implementation. If we're going to implement SocketCAN do we want to support the old NuttX CAN implementation and SocketCAN implementation at the same time through a single hardware driver? Do people use the NuttX CAN implementation? Can we implement SocketCAN through the NuttX Ethernet implementation and completely skip the NuttX CAN implementation? NuttX CAN Implementation NuttX Ethernet Implementation +-------------------------------+ +-------------------------------+ | Application | | Application | +-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+ | POSIX Interface | | POSIX Interface | +-------------------------------+ +-------------------------------+ +-------------+ +-------------+ +-------------+ +-------------+ |System calls | |VFS (fs/vfs) | |System calls | |BSD socket | | | | | | | |net/sockets | +-------------+ +-------------+ +-------------+ +-------------+ +-------------------------------+ +-------------------------------+ | NuttX CAN Driver (can.c) | | NuttX Network driver | | +------------+ +------------+ | | +------------+ +------------+ | | |Syscall glue| |Char driver | | | |Syscall glue| |BSD Socket | | | | | |glue | | | | | |glue | | | +------------+ +------------+ | | +------------+ +------------+ | +-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+ | Hardware CAN driver | | Hardware MAC driver | +-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+ |OS (sched/), memory manager | |OS (sched/), memory manager | |(mm/), common libraries (libs/)| |(mm/), common libraries (libs/)| +-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+ | Hardware | | Hardware | +-------------------------------+ +-------------------------------+ (Note this is ASCII art use a monospace font to view correctly) Everything is still a WIP but I would like gather feedback and come up with an architectural concept for the SocketCAN implementation. Best regards, Peter van der Perk
