AVR-Chat

I'd think that the low speed confg would be fine.

--- In AVR-Chat@yahoogroups.com, dlc <dlc@...> wrote:
>
> 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
> -------------------------------------------------
>