Re: Standard CAN over IP

[Tom Evans <tom_usenet@optusnet.com.au>]

On 05/02/15 07:27, Mike Purvis wrote:
> Hi all,
>
> I'm interested in providing low-cost CAN connectivity to a standard
> Mini-ITX PC— so USB, Ethernet, RS232, PCIe connectivity is available,
> but not I2C or SPI (at least easily).

The obvious approach is to use a PCAN-USB. I guess you want something cheaper 
(these are 195 Euros each). Effectively you're making one of these:

http://www.peak-system.com/PCAN-Ethernet-Gateway-DR.330.0.html?&L=1

So you have the "Mini-ITX" presumably running Linux, and you want to bridge 
CAN over Ethernet to a Microcontroller that has one or more physical CAN ports 
on it. I would guess the latter doesn't have to run Linux.

I've implemented that sort of thing, but the other way around. We have a micro 
not running Linux with two CAN ports on it. It communicates over UDP with a 
small embedded Linux system. The latter provides three CAN ports that are 
bridged over Ethernet to appear to be "physical" ports on the first one. Two 
of those ports are physical ones on the Linux micro, and the third is a 
virtual VCAN port.

So the first micro thinks it has 5 CAN ports. The VCAN bus on the Linux micro 
allows us to run multiple Linux user programs which can each be configured to 
either run on a physical CAN port (for some product configurations) or on the 
VCAN bus when they need to be controlled by the other micro over Ethernet.

So then you have the question - which device is now in charge of setting the 
baud rate and the time quanta for these bridged ports? In our case we let the 
first micro set this up, so there has to be an "Open port and configure it 
this way" message in the UDP packets together with the Receive and Transmit 
framing of CAN messages.

We also signal CAN error states back over UDP, so we have Open, Close, 
Configure, Receive, Transmit and Status messages (and "Transmit Multiple").

You can open one UDP port for all the available CAN buses on a unit, one UDP 
port for each separate CAN port or a separate UDP port for each CAN ID on each 
bus (which requires setting filters). It all depends on how and where (in 
software) you want to demultiplex the CAN IDs to the relevant programs, and 
whether you want to pack multiple CAN frames in one UDP packet.

We found it easiest to let VCAN do the demultiplexing, as that's what the 
SocketCAN interface is very good at.

So we have a user "Bridge" program that receives the UDP frames, interprets 
them and simply receives and sends to the two physical CAN ports and the VCAN 
port. The user application programs on the Linux box open connections to the 
VCAN bus with the appropriate ID filters.

We open one UDP connection with a "port selector" field in each encapsulated 
CAN message in the UDP packet. That allows us to pack multiple CAN messages 
for multiple ports in the one UDP packet. It creates too much overhead for 
both CPUs to put one 8-bytes-of-data CAN message in a 
1500-bytes-available-with-60-bytes-overhead UDP packet.

Another consideration is that at the hardware level, CAN is a reliable 
protocol. The message got through or it didn't (unless a software bug or 
buffer overflow dropped the packet in the receiving device). UDP is the 
UNRELIABLE Datagram Protocol. If this is a problem for your usage you might 
want CAN over TCP or you might want to add some error handling or packet retry 
layer (in other words, try to reinvent TCP all over again).

Another problem is that transmission and reception on physical CAN ports can 
often be timestamped to the microsecond. Some uses of CAN rely on this. When 
you bridge over Ethernet (and with all the Linux non-real-time problems) you 
get some pretty bad latencies, or at least worse ones than the physical ports 
provide.

If you have a very busy 1MBit/sec physical CAN bus and you want to connect 
your PC to it over the Ethernet bridge, and the PC program is only sending or 
receiving messages at a low rate, then you probably don't want everything on 
that busy bus to be dumped onto a VCAN bus inside the PC. In that case you 
would want a connection that allows CAN filters on the physical port. How 
would you configure that if you needed to?

We're finding that a single 43% busy bridged CAN bus can take up 13% of the 
total CPU time on our 800MHz ARM CPU.

 > I noticed an interesting past discussion on this topic:

That suggested a user program receiving all packets on VCAN and sending them 
over UDP and vice versa. That's pretty much what we have.

Tom