Micro with CAN + drivers.

Lots with built in CAN. I've seen some that purport to have drivers, but haven't looked into it closely.

CAN, in and of itself is a link-layer standard, and I haven't heard of it being implemented anywhere but hardware; the "driver" in that case need only be some register setup and a function to check receive buffers. There are several network protocols that layer on top of that.

Found NXP's LPC11C00. Misread the description berfore ...

Roberto Waltman wrote:

-- Roberto Waltman

Thanks for the reply. Yes, sorry, the word "driver" is ambiguous. I did not mean a software driver, but a physical layer CAN transceiver, such as TI's SN65HVD232 or ATMEL's ATA6660.

After my first post I found NXP's LXPC11C00 family, with (sic) "On-chip C_CAN drivers". (Which I also misread as some kind of SW support at first)

-- Roberto Waltman

LPC11Cxx have software drivers for CAN in ROM; works great !

Hope that helps, Best Regards, Dave

The plot thickens... Yes, as I just found out, the LPC11Cxx have both CAN *transceivers* on chip and CAN (OpenCAN) *drivers* in ROM. More than what I wanted. I just ordered an LPCXpresso board to experiment.

Thanks,

-- Roberto Waltman

CANopen, not OpenCAN. And it's only "open" in the sense that anyone can make CANopen devices or buy the protocol specifications - not in the sense that the specifications or any software are openly available. If you don't /need/ CANopen support, just ignore CANopen and the library in these devices - it would be much slower, and much more effort than writing your own code on top of CAN. On the other hand, if you /do/ need to work with CANopen, then the ROM libraries might help.

When you need a heavy protocol allowing mixing and matching of devices from different vendors, support from third-party network configuration tools, automatic network setup, etc., etc., then CANopen is a good choice - it's reasonably well put together, doesn't have much more overhead than necessary (though quite a bit /is/ necessary), and is well supported by the CAN in Automation group and third-parties.

But if you /don't/ need such features - you just want to communicate between your own cards, or other cards using known CAN telegrams, then avoid CANopen or any other such higher-level protocol. The CAN hardware lets you move telegrams around on the bus - it's easy to build on that. The LPC CANopen ROM libraries will then be useless.

Just ignore the CANopen stuff, the CAN drivers in ROM work great. Hope that helps, Best Regards, Dave

That's the plan. I haven't defined the message set yet, but I believe the 8 byte payload of a single CAN data frame is large enough to cover all I need.

-- Roberto Waltman

Yes it does, thanks. I don't want to be a trail blazer with this project.

-- Roberto Waltman

Another great thing about the LPC11Cxx part: the built-in oscillator is extremely accurate. Depending on your CAN speed requirement, your operating voltage, and your temperature range, you may be able to avoid using an external crystal. Check the oscillator accuracy chart carefully though.

Hope that helps ! Best Regards, Dave

Are there any real open source CAN applications on a WIN PC ??

I would like to learn about the PC side of communicating with CAN.

I like the PEAK CAN dongles, available over here from Grid Connect:

Includes a basic-but-handy PC-based monitoring app as well as PC side drivers so you can roll your own application. Haven't tried the Linux drivers but they're available as well.

We use CAN for inside the box, board to board comms quite often. Probably have half a dozen of the PEAK dongles around here.

Search for automotive/ODB projects:

-- Roberto Waltman

Owww, high cost of entry !!

Thank you, just what I was looking for to get me started.

If all you need is something to ack the frames, look at traffic and maybe send a frame or 2 for debug, then look at the Microchip can bus analyzer. I have one and it does exactly what I need it to do. Allows me to debug single nodes, watch traffic between multiple nodes, etc. Not real cheap at $99 but for me worth it. You can order directly from Microchip

(watch the wrap)

I don't know if it's an issue any more, but when I started developing CAN stuff 15 years ago the literature always took pains to point out that CAN itself is a link layer specification: it puts requirements on the physical layer but does not specify it, and it delivers interesting information to higher layers but doesn't specify those, either.

Since then I think that "CAN" has almost universally come to mean "CAN with two-wire differential signaling" (it's per some SAE spec which I can't recall) -- but that doesn't mean that there aren't still pitfalls for the unwary out there, someplace.

That is correct, and there are some "unorthodox" implementations. For example, Siemens application note AP2921 describes a 1-wire bus for "On-Board Communication via CAN without Transceiver" (With the expected caviats of limited bus span and less noise tolerance.)

Which is what I need - [ The differential bus, not the pitfalls ;) ] My application will connect an AHRS (gyros + accelerometers + magnetometers + pressure sensor) to a flight computer in a small experimental airplane.

The sensor head will be installed a few yards away from the computer, with a radio transmitter, transponder, strobe lights and a running engine nearby, so the differential bus is a given.

-- Roberto Waltman

RS485 is differential too, and it's easier to use than CAN.

Bye Jack