AVR Freaks

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

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.

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.

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.

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.

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

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.