AVR-Chat

Hi Chuck,

See comments below.

> From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Chuck Hackett
> Sent: 23 August 2010 05:07
> To: AVR-Chat
> Subject: [AVR-Chat] Preparing for CAN-bus
>
>  
> 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.

You'll be pushed to run 100kbps at that length. Max would be 500m for
125kbps and 
1000m for 62.5kbps.
20kbs should be ideal for what you are looking to do. I doubt you will even
be using
the full bandwidth here either.

> 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.).

It won't be CAN if you deviate from the protocol to send more bytes. You can
send
more by splitting it up and using 1 byte as the message counter.

> 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" :-)

I got 2 CAN nodes talking in about 2 days so you should be OK with this.
Learning the
registers of the device is going to take the longest but there is lots of
code out
there you can pick out and see what's going on. I can give you some bit
banged code
that works on the ATMega and AT90S2313.

> "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).

You're development time is going to be huge if you decide to write your own.

> 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 ...). 

Protocol would be the only issue here.

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

The PCA82C250 is also another device you can use.

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

Use bit banged SPI. I did this and it works perfectly and I was running the
bus at
125kbps with no loss of data. Let the CAN controller do all the filtering
for you.

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

The TQFP is not too difficult to solder if you have a good setup. Small
soldering bit
and some liquid flux and solder braid. I solder down 2 corners of the device
to align
it on the PCB then I add the flux and then run the iron along the pics
adding solder
as I go. There are quite a few tutorials on Youtube for this. Use the solder
braid
to removed any solder bridges. If you shine a torque through from the bottom
you can
see between the pins to check for solder bridges. A bit of practice and you
will be
good at this. I can now do 0.5mm pitch connectors etc.

> Thoughts on external .vs. on-chip?

If you can use the devices with the internal controller, you can use all the
interrupt handlers that it comes with and no need to share an SPI port etc.

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

There are but don't expect to get anything for less that about $150 or more.
Those with
software to capture the packets are more expensive. 

I did however come across this and price wise it looks very good. 99 Euros.

http://www.canusb.com/

No capture software but I see there is a Labview download that might work
for you!

If you roll your own make sure you design it with opto isolation on the CAN
bus.

Good luck.

> Cheers,
>
> Chuck Hackett