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 ]

On Wed, 01 Aug 2012 17:22:21 -0400, Roberto Waltman wrote:

> 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,

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.
Why am I not happy that they have found common ground?

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

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


Roberto Waltman  wrote:
>Is there a microcontroller with a CAN interface and built-in CAN
>drivers? 
--
Roberto Waltman

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

Tim Wescott wrote:

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

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 ]

On Wednesday, August 1, 2012 6:12:00 PM UTC-4, Roberto Waltman wrote:
> 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)

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

Hope that helps,
Best Regards, Dave

Dave Nadler  wrote:
>LPC11Cxx have software drivers for CAN in ROM;
>works great !

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 ]

On 02/08/2012 00:59, Roberto Waltman wrote:
> Dave Nadler  wrote:
>> LPC11Cxx have software drivers for CAN in ROM;
>> works great !
>
> 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.
>

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.

<http://www.can-cia.org/>

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.

On Thursday, August 2, 2012 2:20:07 AM UTC-4, David Brown wrote:
>   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

David Brown wrote:
>But if ... 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. 

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 ]

Dave Nadler wrote:
> ... the CAN drivers in ROM work great.
>Hope that helps,

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 ]