You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Peter Van Der Perk <pe...@nxp.com> on 2020/02/11 12:47:11 UTC
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 |
+-------------------------------+ +-------------------------------+
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
Re: NuttX SocketCAN implementation
Posted by Xiang Xiao <xi...@gmail.com>.
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.
Thanks
Xiang
On Tue, Feb 11, 2020 at 11:21 PM Gregory Nutt <sp...@gmail.com> wrote:
>
>
> > 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)
> >
> 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.
>
>
Re: NuttX SocketCAN implementation
Posted by Gregory Nutt <sp...@gmail.com>.
> 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)
>
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.
RE: NuttX SocketCAN implementation
Posted by David Sidrane <Da...@nscdg.com>.
+pavel
-----Original Message-----
From: Peter Van Der Perk [mailto:peter.vanderperk@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
NuttX SocketCAN implementation
Posted by Peter Van Der Perk <pe...@nxp.com>.
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