CAN I CAN with an xmega

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

Hi all,

I have an application where I would like to used different processors for different tasks including controlling and data logging. I would like to connect them for the purposes of inter-uC communication with simple commands, as well as hook the network up to a PC for data-logging and re-programming (each node has a bootloader).

I have been reading through the various threads regarding network protocols and CAN looks like an attractive option, particularly way so much of it is handled in hardware, ... assuming I have a processor with CAN.

Assuming I were to use an xmega, without in-built CAN, is there a nice piece of hardware that I can stick between the xmega and the bus, that will do all the CAN stuff and just send me the data via UART?

I would expect this 'in-between' hardware to have some input and output buffers, and be able to take some higher-level commands from the xmega such as 'send this data to that node'.

Has anyone any experience in implementing CAN in this way?
Am I missing the point?

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

Dare I ask but exactly what kind of inter-uC are you talking about? CAN is a very complex system and for most "uC networks" I would have though TWI/I2C would be more than enough?

But yes there are external "CAN tranceivers" you can attach to non-CAN chips.

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

Look at the MCP2515, you can connect it to any microcontroller with SPI.

I tend to post off-topic replies when I've noticed some interesting detail.
Feel free to stop me.

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

There are many third party vendors taking care of this issue and providing as a module for sale.

You can also use CAN microcontrollers itself in you project but they don't give features like XMEGA.

ATMEL--Heart Beat
Nothing Impossible

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

@Clawson

The main purpose of the data-bus is actually the communication with a PC for data-collection and programming from a remote location. For this, a master-slave system would be sufficient. I would like to span 100m or so and be able to send the flash contents of my xmega fast and securely.

I originally also wanted to have some devices arranged in sub-networks. The communication in such a sub-network would be very simple and indeed TWI would be fine, however if I had CAN implemented anyway, I would just use the same bus for my inter-uC comms.

My main aims are to reduce development time and have something that works. I was looking at CAN as something that may be an overkill, but would have the network more-or -less working "out of the box" so I can concentrate on other things.

I may still use something like SNAP over RS485 for the data collection/programming, but my uC bootloaders will need to have the protocol implemented as well. Any thoughts?

Do you know of any CAN Tanceivers off hand?
The ones I looked at only took care of the level-shifting etc. for a uC that is already implementing the CAN protocol.

Is there a good reason for not putting can on any xmegas?

@ srinivasandelta - do you know the names of some of these vendors?

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

Hope you are trying to make one such this:

http://www.kvaser.com/en/product...

ATMEL--Heart Beat
Nothing Impossible

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

Hope this is what you want http://www.can232.com/

ATMEL--Heart Beat
Nothing Impossible

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

Thanks srinivasandelta. Not quite what I meant. The data logging should be done by a PC, so I do not expect to need to develop a data logger.

The main development is with the nodes- the uC-based systems that are connected to the PC via the data bus. I want to be able to monitor the performance of the nodes and update the uC programs from the PC.

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

Quote:
Hope this is what you want http://www.can232.com/

well that does look cool. Certainly looks like it solves that problem of what to do at the PC end!

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

@buffi

The MCP2515 looks good.

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

With MCP2515 you will need the MCP2551 also....
It is very easy to send and receive small CAN messages but supporting a high level protocall is more tricky....

There is a library for using MCP2515 with AVR here :
http://www.kreatives-chaos.com/a...

Last Edited: Wed. Jun 30, 2010 - 01:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

buffi wrote:
Look at the MCP2515, you can connect it to any microcontroller with SPI.

We have a product in production with this device connected to an ATxmega128A1. It works rather well.

We've written a bootloader over CAN using this chip fits within the 8K bootloader space provided. I doubt it will (easily) fit in 4K bootloader space (such as for the 32A4) without sacrificing too many features (e.g. we CRC the flash and have a basic fallback program in the event of a failed upload).

-- Damien

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

SlammerA wrote:
With MCP2515 you will need the MCP2551 also....

We use a NXP TJA1040 instead. There's several similar CAN Tranceiver chips on the market from TI and others. The MPC2551 is worth a look though.

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

Since the Xmega is not 5 volts, the TLE6250 V33 is a special CAN transceiver chip with 5 volt to 3.3 volt level converts built in for use with a 3.3 volt CAN controller chip. The SN65HVD230, SN65HVD231 and SN65HVD232 are special CAN transceiver chips that are for 3.3 volt only use. Since these three chips have no 5 volt supply at all, you will need to check their data sheet for compatibility with whatever CAN bus physical layer standard you are using.

The SJA1000 CAN controller chip is 5 volts, but the MCP2515 CAN controller chip will operate at 3.3 volts.

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

If this really is a one-to-one connection then why isn't UART (or rather UART via USB) not sufficient to connect an AVR to a PC for data logging.

Things like CAN, I2C, RS485, (ethernet-TCP/IP even) are for multi-point address based networks. But that's an over-complication for one-to-one.

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

Quote:
If this really is a one-to-one connection then why isn't UART (or rather UART via USB) not sufficient to connect an AVR to a PC for data logging.

I think I mentioned multiple uCs in my opening sentence. This is the problem. Up until now I have been quite happy carrying out my development on a single controller-based system connected to a PC via RS232.
Now I want a bigger system with more processors (at least 10 for starters with room for more) so I am looking for a better way to do it than lots of cable, a big USB hub and lots of USB<->RS232 adapters.

Depending on the complexities of implementing CAN with the additional chip(s), I may yet limit the data/programming network to a master-slaveS system that implements a simpler protocol on-chip. I would use a simpler (probably TWI) connection in sub-networks where inter-uC comms are required.

I am looking into the above suggestions from Slammer, Damien and Mike. Cheers.

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

OK I'll shut up in a minute (I promise!) but have you considered RS485 then which is a sort of "addressed UART" scheme? The code will be much closer to what you already use than the complexities of something like CAN.

http://en.wikipedia.org/wiki/EIA...

Quote:
The recommended arrangement of the wires is as a connected series of point-to-point (multidropped) nodes, a line or bus, not a star, ring, or multiply-connected network.

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

Rather than a MCP2515 CAN chip, you could look into the cost/benefits of using an ATmega16M1, ATmega32M1, ATmega64M1 or the automotive ATmega32C1, ATmega64C1. Even the AT90CAN32, AT90CAN64 or AT90CAN128 as your external CAN controller 3.3 volt Vcc chip. You would probably tend towards the smaller versions. The per chip cost would almost certainly be higher, but you would have the flexibility to develop a variety of Xmega interfaces and you could have your own custom high level command type of network interface, completely unburdening the Xmega from any CAN awareness. This would also allow the implementation of other types of command driven external chip supported networks as plug-in replacements for CAN. If your Xmega bootloader implements your high level command network interface, your Xmega bootloader would be the same no matter what type of external network chip you use. Aside from cost, one disadvantage would be yet another chip to bootload.

noddy2 wrote:
The communication in such a sub-network would be very simple and indeed TWI would be fine, however if I had CAN implemented anyway, I would just use the same bus for my inter-uC comms.
Be aware CAN is a broadcast only bus and you cannot route or subdivide CAN traffic on a single CAN bus. You may have separate CAN buses if you want true sub-network traffic isolation. As long as you have enough bandwidth a single CAN bus is not a problem.

Aside from electrical requirements, CAN maximum bus length is limited by the baud rate and transceiver propagation delays. At 100m you would be limited to around 500 kbps maximum. In error active mode the CAN error system automatically ensures all nodes get good CAN data for high "network wide" data integrity.

CAN complexity is mostly in the controller interface. Because of the built-in CAN hardware protocol support, starting from scratch RS-485 would be harder to implement than CAN for a high data integrity model. However, RS-485 has been around for so long no one has to start from scratch.

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

One final point brought up in EE Times recently (by someone trying to sell chips, of course) is noise immunity. If you really have over 100 m of bus, your grounds will be floating all over the place, intermediate noise sources will screw things up, and so on.

I do not know if CAN transceivers have any isolation (this article, although old, seems to imply problems in this area), but I know that RS-485 transceivers can improve this.

For a quick introduction to RS-485 noise isolation, try reading this article (part 1 and part 2 - PDF) as it explained the basics better than I've seen it elsewhere. Of course, they're trying to sell you their chips, but the points made are valid.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

I found more CAN transceiver chips with 5 volt to 3.3 volt level conversion. The TJA1041 and TJA1041A. Here are some application notes about the NXP transceivers. AN10211 indicates 80 meters if the maximum CAN bus length, even at 125 kbps where the CAN propagation delay theoretical limit is closer to 400+ meters. This is a real world implementation limit based on these chips, their ISO standard and physical bus wiring. The lesson is if you want real 100m performance you had better design for it and test to see if you achieved it or not. RS-485 does have the advantage of not being so propagation delay sensitive, however it does not accept bus data collisions with real time, no retry, priority arbitration of live bus traffic. Unlike RS-485 CAN does not suffer from bus short circuits (i.e. driving an active +V into an actively driven grounded node) during data collisions.

http://www.nxp.com/documents/app...
http://www.nxp.com/documents/app...

This application note has CAN ground offset information for their automotive transceiver chip:

http://ww1.microchip.com/downloa...

If NXP was not being so EMI sensitive for unshielded bus wiring, they should be able to get more than 80 meters at that baud rate.

Stu, nice finds on the articles.

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

I almost forgot, if you want the ultimate in noise and ground offset immunity it is possible to implement CAN on a fiber optic bus. Oops, there goes that cost thing again :wink:...

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

Mike B wrote:
I almost forgot, if you want the ultimate in noise and ground offset immunity it is possible to implement CAN on a fiber optic bus. Oops, there goes that cost thing again :wink:...

TI have some isolated can transceivers, but I have never used them: http://focus.ti.com/docs/prod/fo...

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

Do we have enough power to implement CAN in software?

I love Digital
and you who involved in it!

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

Ali_dehbidi wrote:
Do we have enough power to implement CAN in software?
Yes, but not enough AVR processor power to make 1 mbps. It would be some much slower CAN baud rate. CAN is a really complicated real time protocol that would be a huge software effort for such a slow baud CAN implementation. Whatever highest CAN baud rate it could reach would absorb most of the AVR processor power, leaving very little for other tasks. Also Bosch owns CAN. The AVR chips with CAN hardware in them have already paid the license fee to Bosch, so anyone that purchases an already licensed CAN chip does not have to pay any additional license fees. I know that if you implement CAN on a FPGA for commercial use, you have to pay a license fee to Bosch for each FPGA you program for CAN.

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

Mike B wrote:
Stu, nice finds on the articles.
Thanks, Mike. Also, thanks for your articles!

One of the most interesting applications for CAN that I've come across is a standard being developed for model railroad sense and control. This does not apply to the locomotives but instead to all of the presence sensors, track lighting, traffic control lights, and control board systems. Pretty cool!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Thanks everyone. I have read your answers and links and learned lots.

It looks like I can use the benefits of RS485 hardware over CAN and don't need even a fraction of the CAN protocol functionality. I also didn't realise that the automatic addressing function I wanted from CAN is already built into the UART...

clawson wrote:
... have you considered RS485 then which is a sort of "addressed UART" scheme?

if you meant using Multi-Processor Communication Mode, then no. But I have now. Thanks for the tip!

I will try using MPCM first and possibly throw Modbus on top of that if I need additional functionality.

I hope this thread helps others looking to implement CAN on a non-CAN chip.

Thanks again.