AVR-Chat

I have been busy field testing my devices in stand-alone mode but I’m now ready to
tackle communications between them.

Communication will be a multi-drop CAN-bus implemented over an outdoor, buried,
twisted-pair cable (yes, I know I'll have to implement lightning/surge and
ground-differential protection but let's ignore that for the moment).  The cable is
2,000 to 3,000 feet which is hopefully doable with my low speed requirement.  If I
have to, I'll install bridges.

At the moment the required link bandwidth is unknown but I'm sure it will be very
low by CAN standards - something like 19,200 bps with the desire to increase that
later to maybe as high as 100,000 bps.

I'm currently using an ATMega16 processor on the devices to be connected and I'd
like to stick with this if possible to limit the introduction of new learning
curves.

At first I was avoiding using an off-the-shelf CAN controller such as the MCP2515 or
an AVR with a built-in CAN controller.  This was for two reasons:

1) I was concerned about the message payload limit of 8 bytes with standard CAN but,
after some study, I don't think that this will be a problem.  If I do need larger
messages later I can always implement a higher-level protocol on top of the CAN
level (DeviceNet, OpenCAN, etc.).

2) I was concerned about introducing a steep learning curve, the probable need to
build a CAN-bus monitor, etc.  I have implemented other protocols in the past so I'm
familiar with a lot of the "potholes" :-)


"On the other hand", some of the advantages of using a pre-built CAN controller are:

1) Full CAN is there "out-of-the-box" with all the collision detection, CRC
generation, error recovery, etc. is done and tested and I don't have to debug it (at
the price of my learning the programmatic interface).

2) I would like to be able to connect some other 'dumb' devices such sensors and
indicators.  If I have a 'full' CAN implementation this can be done very easily with
off-the-shelf parts without me having to use/program and MCU for each of them (after
all, this is what CAN was designed for ...). 


I'm thinking of using MCP2551 transceivers
(http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf).  They provide
slew-limiting and seem to be readily available and inexpensive.  I was looking at
the MAX13052 (http://datasheets.maxim-ic.com/en/ds/MAX13050-MAX13054.pdf) but they
do not seem to be readily available in small quantities.

So, this brings up the question of CAN controller:

1) MCP2515 with SPI interface connected to my current ATMega16.  There is a
possibility that I will be adding other SPI devices to the board also so that logic
could be shared.

2) Switch to an AT90CANxxx, ATMegaxxxM1 MCU - assuming that they also have the other
I/O I need (A/D, etc.).  Are there other AVRs with CAN?  I would like to stick with
ones that have JTAG, and can be handled by the STK500 because that is the equipment
I have available.

I wonder about my ability to solder the TQFP package used by the AT90CANxxx and
ATMegaxxxM1 so the external controller might be better ...

Thoughts on external .vs. on-chip?


Another thing I'll need is an interface from my CAN bus to a central PC that
performs monitoring and control functions.  I know that I could build my own
USB-to-CAN bridge, but does anyone know of one available with drivers/libraries to
make access from Visual C# fairly straight-forward?

It would be handy if the above device also came with PC-based CAN "sniffer"/analyzer
software ...
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844 http://www.whitetrout.net/Chuck