Interfacing SJA1000 CAN controller to embedded PC

I have a project coming up which will involve 5 - 10 CAN nodes, implemented in ARM9 microcontrollers. The CAN bus will run a 1Mbit, using 11 bit identifiers. About half the nodes will be in the same physical box, the others will be in various sensor / user interface boxes connected via short lengths of cable. There is also an embedded Windows PC in the main box, which we want to use to snoop on the CAN transactions to drive a mimic display, etc. There's also the possibility of doing all the MCU firmware upgrades via CAN.

So, what's the least-effort way of interfacing a 1Mbit CAN bus to a Windows PC? This has to be a chip-level solution; plug-in cards are no good for space reasons. PC host interfaces available are:

- USB 2.0

- PCI Express

- LPC

Now the difficult bit : I'm a hardware engineer, I don't write code (unless you count VHDL). We have people who write bare-metal C for MCUs, and other people who write Visual Studio .NET for PCs, but nothing in between. Our last attempt to write a driver using the Windows DDK, for a fairly simple peripheral implemented in an FPGA, took months and months to get working properly. Hence an off-the-shelf driver is pretty much a must.

Two options I've looked at so far using the ubiquitous SJA1000 controller:

- USB interface via FT2232H in MCU Host Bus Emulation Mode This looks attractive to begin with, all the PC-side code is at the application level. All the comments I've read say that this won't keep up with a 1Mbit CAN bus, mainly due to the limited interrupt support in the FT2232.

- LPC interface using address decoding, SERIRQ and other glue logic in a CPLD I already have LPC interface code in VHDL which works well in an existing product (but polled I/O only, using DLPORTIO), the difficult bit is the Windows device driver. Are there any off-the-shelf drivers available which might fit the bill? Commercial or open-source, I don't mind.

Or if anyone has any better suggestions for how to do this, I'm all ears.

TIA

Reply to
<news
Loading thread data ...

Exactly how much space do you have available? Could you fit a 50mmx35mm board in there somewhere?

Andy

Reply to
Andy Sinclair

Possibly. I just found this:

formatting link

which would do the job. Probably not much bigger than the SJA1000 + transceiver + CPLD I was considering.

Reply to
<news

Not an SJA1000 but I used a CANdo USB to CAN module from

formatting link
and it worked a treat.

Reply to
Bill Davy

Also look at the offerings over at Peak

formatting link
(distributor over at
formatting link
that are about that size.

We use a bunch of their USB-CAN adapters to provide PC to CAN connectivity for monitoring the internals of various equipment. The as-built USB-CAN dongle sounds like it would be too large for your app but, perhaps, you could just crack the case and integrate the guts, which may fit and would happily chatter on your USB. May be okay for a onsie-twosie project; not so much for 10K units/week. Could be worth contacting Peak, though, and asking if they have an OEM version.

For true chip-level, I'd look at a smaller micro with both USB and CAN; something like one of STMicro's STM32 Cortex-M3 family. Your bare-metal guys should be able to get one up and running without too much trouble.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

The Peak PCAN-USB is what I had in mind. the board inside the plastic case is 50mmx35mm. It would certainly be easier than a custom interface for small volumes.

Andy

Reply to
Andy Sinclair

These guys were great when I last used their stuff (5 years ago). They would have to have worked hard to not be good now.

formatting link

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Reply to
Tim Wescott

It's pretty easy to get up and running for custom apps. In addition to a basic bus monitor (PCanView) it comes with a dll for MS Windows apps. That, plus my trusty Borland BCB5, is all that's needed for some snazzy monitoring. They also include a Linux driver; haven't played with that.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

OK, thanks, that's the smallest board-level module I've seen so far. I'll add it to the list.

Reply to
<news

OK, thanks, I'll keep them in mind for a USB adapter for debug use but as far as I can see they don't do an embeddable module.

Reply to
<news

Volumes will be in the low hundreds a year, high enough that we don't want to be cracking cases apart. It only takes an innocuous little mechanical design change to completely screw up your production - BTDTGTTS! I'll enquire about the OEM version though, thanks.

Our experiences with embedded USB have not been good so far - we did one based on a PIC18 series runnning as a CDC device, using Microchip's reference design and CDC driver. 99.9% of the time it worked fine, the

0.1% of the time - when the device wasn't detected at startup - was virtually impossible to debug as we couldn't see which layer of the Windows driver stack had got stuck. Debugging at the PIC end was hampered by the fact that we couldn't step through the code without violating the USB timeouts and having the peripheral thrown off the bus. Are other micro vendors' USB peripherals better in this regard? In the end we added some code to the PC application which forced a reset of the offending USB port, this improved reliability by about an order of magnitude, but didn't completely eliminate the fault. It was clearly some sort of race condition at startup (it never failed once it was up and running).

I might be unfairly maligning USB but we are increasingly moving mission-critical functions away from it - there doesn't seem to be any expectation, even from the vendors of the USB-capable devices, that it will *always* work. "Have you tried resetting it?" was the first response to most of our tech support queries.

Reply to
<news

If you are happy making your own board, I'd recommend taking one of the ARM devices you already use (and presumably know and love) to monitor the CAN bus. Connect a UART on this to an FT2232H device, which is then connected to the PC by USB. You should be able to find a fast baud rate that the ARM and the FT2232 can handle (up to 6 MBaud, IIRC, for a direct TTL link). Then you have a simple program in the ARM that reads any incoming CAN telegrams and copies them out on the UART. On the PC side, you've just got a normal (fast) USB UART input.

It's all chips that you know, technology that you know, and no device driver development. Let the microcontroller handle the fast stuff, and let the PC program handle the display, logging, etc.

Reply to
David Brown

Take the case off and stick it to the inside of your box with double- sticky tape, then.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Reply to
Tim Wescott

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.