Interfacing CAN directly to PCIe bus

I'm working on retooling a project that is an embedded Intel Core i3 system running Linux with a PCAN mPCIe card to interface to our two CAN buses. Cu rrently we're using an Intel NUC motherboard, but we want to move to a COM- Express module for reliability and manufacturing reasons.

Since we're designing a custom carrier board, I would like to lower our par t cost by about $400 by just interfacing the CAN directly to the PCIe bus.

It looks like Linux's built-in SocketCAN drivers have support for the SJA10

00 CAN controller through a variety of vendors' PCI(e) cards. Since they al l seem to use the same driver source, I should be able to emulate what they 're doing and just put the SJA1000 right on my PCB with some sort of interf ace chip right?

The only problem is I know next to nothing about PCIe, so I don't really kn ow where to start. It looks like all the vendors' cards use an FPGA or some thing, can I get away without doing that? Is there a standard solution for this sort of thing?

Reply to
Chris Hammond
Loading thread data ...

I dunno about interfacing CAN directly to PCIe, but do you have USB on your new module? If so, a USB CAN interface may work a lot better, even if you have to buy one already packaged and wire-tie it to the side of the enclosure.

Just a thought -- feel free to ignore it if it's a non-starter for some reason.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

e
e
e
y
r

Thanks Tim,

I thought of doing that as well, but space in the enclosure is pretty tight , and it would also be ideal if we didn't have any extra connectors or wiri ng to vibrate loose. The goal is to have the COM board and carrier board wi th external connectors on it, and nothing else in the box.

Reply to
Chris Hammond

If I remember correctly the COM Express standard mandates at least one SPI bus. If you have one of those, you could attach an MCP2515 to it, and this would be the easiest solution. I think that SocketCAN supports it.

Probably it works through one of those clumsy PCIe-to-ISA bridges, but I don't know the details.

--
Fletto i muscoli e sono nel vuoto.
Reply to
dalai lamah

I _very_ much doubt you'll get that pipe dream anywhere near to working. Certainly not with essentially no knowledge whatsoever about PCIe.

PCIe is nothing like CAN. The host CPU interface of an SJA1000 CAN controller is a parallel address & data bus, like in a traditional memory chip. That's about as big a mismatch to PCIe as you can get while still being in the same hemisphere of the computing world.

Precisely. _Through_ a card. Which holds quite a bit of stuff beside the SJA1000.

In theory: yes. In practice, the SJA1000 will be the least of your worries in such a setup. You'll have your hands full finding such an interface chip, and getting it to do your bidding.

Let me answer that in the shape of a question: if there were a standard chip, don't you think these vendors would have used it?

Reply to
Hans-Bernhard Bröker

Maybe I wasn't really clear about what I'm looking for. I don't necessarily need a "PCIe to CAN chip" (although that would be awesome), but just any w ay to get the PC to talk to a CAN controller without an expensive interface card.

I know Linux can talk to a SJA1000 controller, I just need to fill in the b lanks between CPU and SJA1000. If you really think PCIe would be way too co mplicated, we could use USB or SPI instead. I just figured that if it's don e often enough that there's a standard driver, there should be a fairly sta ndard way to do it.

Reply to
Chris Hammond

Interfacing directly CAN or a CAN controller with a traditional address-/data bus with PCIe is obviously not an option. But how hard would it be when a PCIe to Local Bus Bridge (like the PLX PEX8311) or a PCIe-ISA Bridge is used as a gateway between those two worlds? Getting it to actually work would no doubt still require some knowledge about PCIe, but I expect using a PCIe bridge would require a hell of lot less knowledge than implementing it entirely from scratch.

Reply to
Dombo

The thing that CAN controller is on _will_ be, to a rather good approximation, an expensive interface card.

Not really it can't. Linux can talk to SJA1000 controllers that have been interfaced effectively IBM PC-style. Depending on which generation of PC you're looking at, that might be something like

CPU---front side bus---"north bridge"---PCIe---PCIe/PCI bridge... ...---PCI---legacy interface --- ISA bus --- SJA1000

The main part of the management and handling that allows those Linux drivers to find and use the SJA1000 just by writing and reading to its registers is in all those bridge chips, in the horrible mess that is an ACPI BIOS, and in the tons of Linux driver code that talks to all those.

A large part of all has to be on that expensive interface card if it's to have PCIe coming in on one side, and CAN coming out of the other.

Reply to
Hans-Bernhard Bröker

You might be able to use something from PLX. Maybe something like their PEX 8311. PCIe on one side, a local bus on the other side. A few years back we considered using one of their PCI->local bus chips but, if memory serves, the guys dropped in a FPGA to take care of it.

--
Chisolm 
Republic of Texas
Reply to
Joe Chisolm

I second the USB idea. It is usually /much/ easier to make a USB peripheral than a PCIe board, unless you have an all-in-one PCIe chip for the job. It is perfectly possible to make such a USB board that is small and attaches directly to the board (which often have 10-pin headers for USB), rather than using plugs, wires, etc. And it makes prototyping and testing much easier - get a Peak Systems USB CAN device for testing and prototyping. And when you have your own USB module ready, you can easily test it on any other PC. Being able to plug in and out of a running system makes development faster.

Reply to
David Brown

That might be the case on the ISA bus, but PCI and PCIe requires much more than that.

You mentioned SocketCAN. While I do not know any SocketCAN implementation for an Ethernet/CAN converter, there are several Ethernet/CAN converter that have very similar TCP or UDP socket interfaces as SocketCAN. It should not be too hard to adapt to any of the various vendors. These converters work with any operating system supporting at least some kind of socket interface (some even work with primitive UDP stacks).

With external USB converters are tied to an operating system and even operating system version dependent drivers.

Of course when using external converters at an Ethernet or USB bus, there are additional latencies. While the unidirectional transfers are not a problem due to the higher bulk bandwidth, half duplex transactions, such as CanOpen SDOs will suffer.

Reply to
upsidedown

What is the distance between your device and the CAN device(s) ?

If it is large (more than a few tens of meter), the distance will limit the CAN speed.

Using Ethernet/CAN converter, you can get to 200 m without hubs/switches at full speed.

If the CAN device(s) are at a different room, you should also consider galvanic isolation issues.

Reply to
upsidedown

I've used that one a ways back. It's... interesting. it's basically their PCIe-PCIx chip and their PCIx-local bus chip bonded into the same package. It even needs two different configuration EEPROMs.

Having done a few PCIe projects so far, I'd say that when you can avoid it, you should. There are tons of little lurking issues that require tremendously expensive equipment to diagnose when they're not working right. Also, I've had no luck making it hotplug, with many many many hours spent trying. Ethernet/USB are commodity, easy to work with, and don't require power cycling the PC every time you need to change something in the DUT.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.