Micro with CAN + drivers.

I believe this question has been asked here, but I could not find the answer while searching this group or chip manufacturers.

Is there a microcontroller with a CAN interface and built-in CAN drivers?

The application is a simple CAN node, reading data from SPI & I2C connected sensors and delivering it as CAN messages, so memory and CPU requirements are small.

Thanks,

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman
Loading thread data ...

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.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
 Click to see the full signature
Reply to
Tim Wescott

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

Roberto Waltman wrote:

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
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

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

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

Hope that helps, Best Regards, Dave

Reply to
Dave Nadler

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

[ Please reply to the group, return address is invalid ]
Reply to
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.

Reply to
David Brown

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

Reply to
Dave Nadler

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

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

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

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
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

Reply to
Dave Nadler

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.

Reply to
hamilton

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

formatting link

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.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Search for automotive/ODB projects:

formatting link
formatting link

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

Owww, high cost of entry !!

Reply to
hamilton

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

Reply to
hamilton

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

formatting link

(watch the wrap)

--
Chisolm
Republic of Texas
Reply to
Joe Chisolm

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.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
 Click to see the full signature
Reply to
Tim Wescott

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

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

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

Bye Jack

--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?
Reply to
Jack

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.