Looking for CAN transceiver that outputs TTL serial signals

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm looking for a CAN transceiver that inputs/outputs completed CAN/CANbus messages as TTL serial. I've seen them for RS2323 level serial, but that's 1) too high a voltage and 2) backwards.

I unfortunately can't use just a simple CAN transceiver and bit-bang the protocol, as for the 1MHz bus speeds it's just too much processing overhead with everything else I need the chip to do.

Likewise, I can't change chips to a CAN capable model since I'm developing for the XMEGA.

I've searched around a lot, but can't seem to find what I'm looking for. Anyone seen something like that?

P.S. In retrospect, SPI, I2C, etc would also be fine, just so long as there's no need for extra circuitry to connect to the CAN bus.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well use another micro that has CAN controller and interface that with your XMEGA?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:
Well use another micro that has CAN controller and interface that with your XMEGA?

Why devote a whole extra microcontroller, with associated cost, footprint, complexity, etc..., when all I need to do is have the CAN messages translated into serial messages?

If it exists in a -+10V package, I don't see why it can't exist in a [0,5V] package.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I asked a similar-ish question a while ago here:
https://www.avrfreaks.net/index.p...

I think you'll find there more it CAN than simply translating messages to serial - there is a great deal of arbitration to deal with.

People have reported success with the MCP2515. I hope they're right... I have boards with this chip on it coming in this week...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

damien_d wrote:
I asked a similar-ish question a while ago here:
https://www.avrfreaks.net/index.p...

I think you'll find there more it CAN than simply translating messages to serial - there is a great deal of arbitration to deal with.

Thanks. I already have CAN devices in the field. so I can definitely relate to the complexity. My problem is that I want to incorporate a CAN device into the XMEGA, and don't see why I can't have a simple device that does what the transceiver does, along with a bit-stuffing and arbitration. After all, if I tell my Cortex-M3 to write "0xFF" to the CAN bus, it does. And I could tell it by the serial port to write a message, and it would do that. So it's easy to imagine the two units in one piece of plastic.

No need for message filtering, that's a nice feature but one that the MCU can do, or do without.

Quote:
People have reported success with the MCP2515. I hope they're right... I have boards with this chip on it coming in this week...

The MC2515 still requires a transceiver, so it wouldn't work for me any better than, say, a classic ATA6660 with a CAN capable AVR behind it. It might be a little cheaper, but it's still more complicated than I hope to find.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I doubt that what you want exists. Best solution would be external CAN controller + external CAN transceiver.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually if you bit bang the CAN protocol you need a license from Bosch. When you purchase an ATMEL chip with CAN or the MCP2515, the license and fees are already taken care of by the manufacturer at no additional costs to you beyond the price of the chip(s). I suspect there are licensed FPGA based CAN controllers available.

The Bosch protocol is here:
http://www.semiconductors.bosch....

Aside from the licensing, expect fairly high development costs and a long schedule to bit bang CAN from scratch. Don't forget sending active and passive error flags even in Rx, overload frames, Tx bit collision errors when outside the arbitration field, CRC checking, no acknowledge errors, etc. If you only want to Rx CAN frames then the error processing and Tx are gone, but any errors in your Rx only CAN node will not send any error flags on the CAN bus for retransmission. You just have to live with any bad CAN frames in a Rx only node. You are of course responsible for any problems if your other CAN bus nodes do something unexpected and your bit bang code fails (you need to exercise/test your bit bang under all possible CAN activity to know if it will always work).

I'd listen to nleahcim.

In any case you will probably need +5 volt supply to support your existing CAN bus, which means you will need a voltage level translator somewhere for the Xmega. If possible do the voltage level translation between the CAN controller and Xmega. Adding extra propagation delays between the transceiver chip and CAN controller may cause limitations in your CAN bus physical length.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike B wrote:
...I'd listen to nleahcim.

Err... I can't help but think that you misread the question. I never mentioned trying to bit-bang, and in fact said it'd be way too hard to do. I'd have to devote an entire chip to bit-banging, and then I'd still be back where I was to start with: two chips, one that does something useful and one that simply translates CAN messages into serial port messages.

It seems no one knows of a single package chip that combines both transceiver and CAN protocol. Well, if I ever find one I'll be sure to post it here.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, sorry a simple mistake about the bit bang intent. It is possible to implement CAN as a 1 wire serial bus, except I don't think there was ever a "standard" for a 1 wire only CAN bus. Bosch never specified any particular CAN bus physical layer, they only specified the dominant/recessive behavior and priority arbitration bit timing limits. Since the physical bus standards are all added on top of the CAN standard, I guess it made sense to separate the controller and transceiver into separate chips. Otherwise you would have the ISO 11898 combined CAN chip, then the ISOwhatever combined CAN chip, then the ISOsellanotherspec combined CAN chip, then the IEEEwesellspecsalso CAN chip, then a fiber CAN chip, etc., with the only difference being the built in interface circuitry. I think this argues its actually against the interest of any microprocessor manufacturers to make any integrated controller and transceiver single CAN chip. I seriously doubt what you are looking for will ever exist.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Mike. You've got a good point, and it's duly noted. I guess I'll resign myself to having to populate both one transceiver and one controller on the board.

One possible solution not to dramatically increase the footprint is to use a System Basis Chip, such as Freescale makes. It combines the CAN transceiver with an LDO, so that by replacing my current voltage regulator with this all I effectively add to the board is one new chip. Not exactly the way I expected things to work out, but it's good just the same. Especially since Infineon makes some CAN/LIN SBCs, which means I can provide LIN as kind of a bonus.