Hi Oliver, thank you for your answer On Thu, Jul 11, 2019 at 8:06 AM Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote: > > Hi Laurent, > > On 10/07/2019 14.45, laurent vaudoit wrote: > > Hi all, > > we are using CAN-BCM protocol for communication between two cpu (one > > with Linux, the other one without OS). > > The communication is basically exchanging some data periodically > > between the 2 cpus (to keep data synchronous between the 2 side) > > > > On a futur architecture of the board, we plan to get some ethernet > > link between the 2 CPUs instead of CAN. > > But with still a "Linux CPU" and the other one without OS (which > > exclude too complex implementation). > > > > So my idea was to write a driver inspired from can-bcm, but instead of > > using can frame using some TCP or UDP socket. Userspace would use > > netlink socket to communicate with the driver, as this would not be a > > AF_CAN driver. > > > > But before starting this work, i was wondering: > > -if it is the good choice? > > The CAN_BCM provides a wide range of tx/rx timing modes and even > bit-wise filtering and notifications - inspired by OSEK COM use-cases in > vehicles. What kind of BCM functionalities are you currently using? > Currently we use mainly TX periodical frames with update of frame when needed (when a data change in our application) and also RX stuffs, with rx timeout to be inform if a frame was not received. > Did you already take a look on "reliable datagram sockets" (RDS) for > your requirements? > > https://www.kernel.org/doc/Documentation/networking/rds.txt > > There's also a reference to "RDMA for RDS" which could be interesting > depending on the potential overhead for your intended data sizes. > > Would that fit for you? I had a look to RDS and RDMA-RDS. This can be interesting for us, in replacement of the CAN. But we must keep the "timing management of the BCM). So the idea would be to have a BCM on rds (or maybe on different protocol, like BCM on rds or udp (for message not critciall for example) RDS seems interesting for the "reliable" aspect, and the frame ordering also, to avoid having to implement it on our own. The choice will now depend on the possibility to port it on the lwIP stack we have on the other cpu. Thanks again. Best regards Laurent > > Best regards, > Oliver > > > -if there is some existing implementation which could be the good > > choice, or a better start point? > > > > Thanks in advance for your advice > > > > Regards > > Laurent > >
