AVR-Chat

I've used CAN networking at 250Kbps on runs of up to 1000 feet with no 
problems.  Lower frequencies can tolerate longer runs.  However, if you 
can deal with very low baud rates (which are less sensitive to timing 
and impedance issues), of say 9600 and lower, you can simply use any 
USART with "9th bit" addressing mode and CAN transceivers to get very 
long runs.  Pay close attention to ground issues on long runs since you 
can build up large ground potential differences that can damage devices.

Your 100Kbps rate is pretty slow for CAN, no big deal there.  CAN 
networking is a broadcast bus, every node hears every message, each node 
typically sets filters to only listen to its own address.

One project that I worked on had a "star" CAN network with hubs that 
echoed messages between arms of the star, so your idea is fine.  You can 
also do CAN as a true buss where all nodes hang off of the same wires. 
Make sure to terminate your runs whichever way you choose to go.

The hardware CAN module can give you full CAN addressing, with the usual 
futzing about with the control registers for "free".  If you go the 
USART route you'd need to develop your own networking protocol.  With 
the extended CAN networking scheme you will be sending 13 byte packages 
with 8 bytes being the payload and the other 5 bytes being protocol 
related.  With your own USART networking scheme you have to/get to pick 
your own payload and protocol overhead.

CAN is a very flexible networking scheme, but there are details that you 
must follow for it to work properly.

DLC

Chuck Hackett wrote:
> I preface this question with the fact that I have very limited knowledge of
> CAN bus and DeviceNet technologies (I do have a background in data
> communications from both the EE and software engineering perspective).  I
> have only 'skimmed' the description of CAN bus and DeviceNet on Wikipedia.
> I know that there are Atmel devices such as the ATMega16M1 that implement
> much of the CAN network support in hardware (skimmed the ATMega16M1
> datasheet).
> 
> I understand that CAN works well for 'local area' sensor networks such as in
> a automobiles, etc. but can I leverage the Atmel CAN support for a network
> that is physically much larger (i.e.: one with significant propagation
> delays)?
> 
> I am currently implementing a network of (hopefully) low cost network nodes
> using ATMega16s connected via multi-master, half-duplex RS-485.  The network
> is:
> 
> 1) Outdoors
> 2) Length: 1,000s of feet using one pair from a CAT-5 cable (other pairs
> used for other control tasks).  I anticipate breaking the net into subnets
> with intelligent (buffered) 'bridge' devices if the physical layer requires
> it.
> 3) Bus/power surge protection provided by transorbs, etc.
> 4) Data rate: As fast as practical to reduce message latency but I don't
> anticipate needing an excessively high data rate.  For the moment let's say
> on the order of 100 kbs.
> 5) Message Traffic: Most messages are broadcast type messages containing
> status info that any node may consume to support its work, others are
> addressed to specific nodes.  Some messages are more time sensitive than
> others but there are also messages that are sent more or less continuously
> as bus bandwidth allows.
> 
> Would it be possible/practical to use the Atmel CAN support in this
> environment?
> 
> I read somewhere that CAN was used up to 400m due to timing considerations.
> Can this distance be extended by altering (possibly 'non-standard') timing
> parameters within the AVR hardware?
> 
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 

-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------