Lpc2000

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 10:41 PM 6/15/05 +0000, Josh Ferguson wrote:
> >I'm relatively sure that the CAN to USB connector and the software
> >are running fine.  I borrowed a test board from a co-worker that's
> >working on something similar but with the 8051 board and his CAN is
> >working.  I hooked it up to my laptop and the software registered
> >getting packets.
> 
> Good to have confirmation of that.

Try hook your board up with the existing network.

> 
> 
> >I'll try and answer your other points now.
> >
> > >
> > >          - termination.  Both ends of your cable need to be
> > > terminated.  BTW what are you using for cable?  It is possible 
even
> >likely
> > > that neither the board or the Peak convertor have on-board
> >termination
> > > since the usual use of CAN is on a bus and only the ends of the 
bus
> >should
> > > be terminated.
> >
> >Like I said above, I think this is a non issue because it worked 
with
> >another chip and board.  The only difference was that I had to use 
a
> >gender changer on mine to plug the PEAK CAN to USB converter into 
my
> >board.
> 
> That shows it might be terminated.  Unfortunately since CAN is 
relatively 
> resilient it doesn't prove it.  If the board and the converter have 
> terminators on them they MUST have a way to disable them, otherwise 
they 
> would never work on an existing bus.   If they don't have a way to 
disable 
> termination they very likely don't have termination and it must be 
provided.

CAN is pretty reslient to improper termination , but on short 
networks with cleanish conditions it isn't very fussy. A "lumped" 
termination of 1 x 60R should be fine.


> 
> You mention using a gender changer.  You are not plugging the Peak 
> converter directly into the LPC2294 board are you?  That could 
cause 
> problems.  As I recall there is a minimum distance between nodes as 
well as 
> a maximum bus length.  It ends up being a function of transmitter 
and 
> receiver delays as well as the signal speed on the bus.  It's not 
usually a 
> problem but...

You aren't twisting CAN-hi to CAN lo are you?

You must connect all the CANHIs together and all the CANLOs together.

> 
> These sort of problems, bus length, missing termination etc...  are 
exactly 
> the sort of problems that will work in some combinations and 
conditions and 
> fail in others in a CAN based network.  In some cases you 
get "lucky" and 
> the built-in retry mechanisms get the message through often enough 
for you 
> not to notice the problem, especially if you are bringing up your 
first 
> network.

One thing to do is to disconnect everything, just putting a 
termination resistor across the sending node. Now watch the signal 
with a scope....

The CAN controllers send out their message and wait for an ACK. If no 
ACK is received they automatically re-transmit.

This is a neat way of checking that your node is really transmitting 
and that gives you a way to check the bitrate is corect etc.