AVR-Chat

Hi Chuck,

 

CAN bus is a great way to go with your project. Once you get over the hurdle
of figuring out how the controller works then you won't go back to using the
likes of RS485 again. :o)

 

If you want to avoid having a microcontroller at your signal ends you could
consider the Microchip MCP202X devices. These give you digital and analog
inputs and outputs on your bus without a micro. You could then use one of
the Atmel AVR devices with CAN bus built in or go for using the Microchip
MCP2515 CAN controller and use SPI from any of the Atmel micros. This is
easy and there is code out there for this or if you ask me nicely I can give
you some code to get you going. I have used it on the AT90S2313 and the
ATMega32 in the past.

 

The great thing about CAN is you don't need a master to send and request
messages. You simply setup the devices to send data as and when they want
and your devices simply listen for messages they are interested in. You can
filter messages for them too.

 

Good luck with it. I am sure you will find it rewarding when you have it all
working. Great thing is that you can build and test this on the desk and see
it all working before you roll it out. If you are designing your own
controllers and boards you can make it generic so that you only need to
design one unit to do all and then is simply software etc!

 

Have fun.

 

Dave.

 

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Chuck Hackett
Sent: 19 June 2010 13:10
To: AVR-Chat@yahoogroups.com
Subject: RE: [AVR-Chat] Re: ATMega16 I/O port protection diodes

 

  

I was originally going to use RS-485 but I have decided to use a modified
version of a CAN bus instead. 

The solution you mentioned above is what I eluded to when I said:

"I am looking at using a smaller controller at the "remote" head but this
brings up yet more tradeoff/cost issues and I need to keep it simple at the
moment because there are a host of other issues yet to be addressed in the
system."

The "small controller" I mentioned above is exactly that, a small device
that supports a signal head and shares the same power/data bus that will be
used by the controllers to talk to each other. The reason I'm currently
driving an LED signal head 800 feet away is for (at least) two reasons:

First: I have not finished designing and testing the communications link
(CAN bus) that will eventually allow all of the components to talk to each
other but this club needed some traffic control immediately. At the moment
I have two controllers in the field supporting two independent sections of
track. The ability for the sections to coordinate with each other as well
as other capabilities will be added later. So, for the moment, the remote
head is driven directly via wire.

Second: The two signal heads attached to the controller ensure that only one
train is allowed into the track monitored by the controller. To do this, an
approaching train is sensed (before entering the track in question). If the
controller decides that it may enter, the signal at the far end of the track
MUST go from green to red before (or at the same instant as) the signal for
the entering train goes to green. This is obviously easy to satisfy if the
signals are directly connected to the same controller. To satisfy this
requirement over a communications link (with latency, errors, etc.) requires
asynchronous coordination which complicates other things that the controller
is doing, and may even cancel the need for the remote signal to go to red,
hence, I'm avoiding these complications for the moment with wire to the
remote head --- but, I do agree that that is where I need to end up. Gota
crawl before you can run :-) 

I have about 30 years of experience with different communications methods,
protocols, etc, (Async tty, bisync, SDLC, X25, TCP/IP, custom protocols,
etc., etc.) on mini-computers for applications from financial online
transaction processing to data radio and train control for Union Pacific.
So I've been around this tree before and know where a lot of the potholes
are -- not to say that I might miss one and drop down a black hole for a bit
(no pun intended) :-)

Now, my experience with microcontrollers, surge protection, PCB board layout
is more limited but I'm learning thanks to lists like this one,
Electronics101, etc.
 
Cheers,

Chuck Hackett





[Non-text portions of this message have been removed]