Reply by Richard Duits●November 26, 20072007-11-26
Robert Adsett wrote: > Wiring is till going to be fundamentally limited by
signal propagation
> considerations. The signal must have time to reach the furthest corners of
> the network and back each bit time in order for CAN arbitration and error
> detection to work. the same considerations also mean reflections need to
> be minimized. These place the same limitation on topology for either
> transceiver.
>
> This is more a property of the CAN protocol (handled by the CAN
controller in the LPCxxxx) than the CAN transceiver. You will not
overcome these limitations by using a RS485 transceiver in combination
with a CAN controller.
Reply by Robert Adsett●November 25, 20072007-11-25
At 12:45 AM 11/25/2007 -0800, Joel Winarske wrote: >Richard Duits wrote:
> > I think CAN and RS-485 physical layers are a bit different. The main
> > difference is that CAN arbitration is based on multiple transceivers
> > sending at the same time, with RS-485 you try to avoid multiple
> > transceivers sending at the same time as much as possible. Somebody
> > correct me if i'm wrong here...
> >
> > And why would you want to use RS-485 transceivers with a CAN controller
> > anyway?
> >Primarily flexible wiring topologies. This combined with:
>1. Offload fault tolerance to silicon and minimize interrupts to CPU.
>2. Silicon handles arbitration.
>3. Prioritized messaging.
But why use RS485 transceivers rather than CAN transceivers? They don't
appear to add anything, all of the benefits stated are a function of the
CAN controller not the '485 transceiver.
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
Reply by Robert Adsett●November 25, 20072007-11-25
At 02:16 AM 11/25/2007 -0800, Joel Winarske wrote:
> > You can get all this with CAN transceivers too.
> >Not so much the flexible wiring topology. Wiring is till going to be fundamentally limited by signal propagation
considerations. The signal must have time to reach the furthest corners of
the network and back each bit time in order for CAN arbitration and error
detection to work. the same considerations also mean reflections need to
be minimized. These place the same limitation on topology for either
transceiver.
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
Reply by Richard Duits●November 25, 20072007-11-25
Joel Winarske wrote: >> You can get all this with CAN transceivers too.
>>
>>
>
> Not so much the flexible wiring topology.
>
>
When we wire our CAN nodes together we do not pay much attention to
network topology and it always seems to work. We have had networks with
up to about 100 nodes. Most important is to limit the slew rate for the
CAN driver (the latest NXP CAN transceivers do this automatically). This
will limit the reflections on the network even if your network is not
the ideal bus topology.
Regards,
Richard.
Reply by Joel Winarske●November 25, 20072007-11-25
> You can get all this with CAN transceivers too.
>
Reply by Richard Duits●November 25, 20072007-11-25
Joel Winarske wrote: > Primarily flexible wiring topologies. This combined
with:
> 1. Offload fault tolerance to silicon and minimize interrupts to CPU.
> 2. Silicon handles arbitration.
> 3. Prioritized messaging.
> You can get all this with CAN transceivers too. > Using RS485 transceivers with Lonwork Nueron chips is
pretty common as well.
>
> Don't know Lonwork Nueron.
Regards,
Richard.
Reply by Joel Winarske●November 25, 20072007-11-25
Richard Duits wrote: > I think CAN and RS-485 physical layers are a bit
different. The main
> difference is that CAN arbitration is based on multiple transceivers
> sending at the same time, with RS-485 you try to avoid multiple
> transceivers sending at the same time as much as possible. Somebody
> correct me if i'm wrong here...
>
> And why would you want to use RS-485 transceivers with a CAN controller
> anyway?
>
Primarily flexible wiring topologies. This combined with:
1. Offload fault tolerance to silicon and minimize interrupts to CPU.
2. Silicon handles arbitration.
3. Prioritized messaging.
Using RS485 transceivers with Lonwork Nueron chips is pretty common as well.
Joel Winarske
Reply by Richard Duits●November 24, 20072007-11-24
I think CAN and RS-485 physical layers are a bit different. The main
difference is that CAN arbitration is based on multiple transceivers
sending at the same time, with RS-485 you try to avoid multiple
transceivers sending at the same time as much as possible. Somebody
correct me if i'm wrong here...
And why would you want to use RS-485 transceivers with a CAN controller
anyway?
Regards,
Richard.
jdauchot wrote: > Hi All
>
> Can the CAN ports on the LPC2200 be configured to be used as RS485
> ports?
>
> If so has anyone done or knows how to do it.
>
> I am using an LPC2294 demo board with CAN drivers.
> Regards
>
> Jean-Jacques
>
>
Reply by Joel Winarske●November 24, 20072007-11-24
jdauchot wrote: > Hi All
>
> Can the CAN ports on the LPC2200 be configured to be used as RS485
> ports?
>
As Robert mentioned yes.
Physical Level = RS485 transceiver
Framing/Arbitration = CAN bus.
Reply by "sub...@aeolusdevelopment.com"●November 23, 20072007-11-23
jdauchot Wrote >Can the CAN ports on the LPC2200 be configured to be
used as RS485
>ports?
If you mean make them behave like a standard asynchronous serial port over
RS485 then I don't see how that would be possible. I don't see a way
of
perverting the framing to match 232 type signalling, especially once you
throw in bit-stuffing.
If you mean could you use RS485 drivers for the bus but use CAN framing
then yes. That's how the original CAN networks were built. But with
real
CAN drivers widely available that seems pointless.
