AVR-Chat

> From: Alex Shepherd
> 
> Hi Chuck,
> 
> > - The data bus is pseudo-CAN.  I use a CAN driver but I'll be doing the
> > beginning-of-message bus arbitration by bit-banging (PD2, PD3) and then
> > switch to the USART for actual data transfer.  In the future I hope to
> switch
> > to a AT90CAN128 (built-in CAN support) but I wanted to limit the initial
> > hardware/software learning curve so I could get the next version out
> faster.
> 
> I would strongly suggest you NOT do this. If you have any interest in CAN
> then you should use proper CAN hardware.

I am using a proper CAN physical layer (cable infrastructure, and bus drivers).  I
am also using the same arbitration methodology but I am just simplifying the upper
levels because I need to get the next development version of my controller out in
the field for testing.  

I agree that that I want to get to full CAN eventually but I don't have the time
required to become familiar with the ins and outs of full CAN, develop/purchase CAN
monitoring hardware/software (including the upper most level message formats that
are unique to my application) and there are other features in this version that don
not need CAN/Datacom.  In addition, my test site needs to implement more blocks, and
I don't want to build any more of the current (now obsolete) block controllers.

> I hadn't got into the detail of your project until today and now that I see
> it is a Model Rail Road project I'm now quite interested.

Well, if you call this a "model" locomotive: http://www.whitetrout.net/Chuck/844

> What you are suggesting in terms of bit-banging the data bus is what
> Digitrax LocoNet does - which works but has limitations. 

I'm willing to live with the limitations for the short term ...

> I have done several
> LocoNet projects over the years and they are available here:
> http://embeddedloconet.sourceforge.net However the last few years of MRR
> hobby time have been assisting a team of people to develop a new MRR Layout
> Control Bus proposal called OpenLCB http://openlcb.org which in due course
> may be adopted by the National Model Railroad Association as NMRAnet.
> 
> If you were interested in leveraging the OpenLCB codebase and assist in this
> development we would certainly appreciate the assistance.

My application is similar, except:
- The cable infrastructure is 1,000's of feet and outdoors
- The signals must still be able to function if they become isolated from any
central PC, etc. (or are isolated by design, i.e.: a long ways away).
- There is no control of locomotives (the on-board engineer is in control of that)
- I can't guarantee that a locomotive stops for a red signal (go figure) ...
- ... yada, yada ...

But, there are also many similarities.  I have looked at interfacing (probably via a
protocol bridge) with JMRI at some future date to implement CTC mode control of
signals (in addition to the normal ABS mode with some flow control added), track
displays, etc.

I took a quick look at the web sites you mentioned but it was unclear to me what the
relationship was between them and JMRI (which is mentioned on several pages).

Can you clarify this?  (probably directly to me off-list as we are now away from the
AVR aspects of the project).

(BTW: I also do my own plastic injection molding of the 18th scale signal heads from
ABS plastic.)
 
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