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.
Robert
http://www.aeolusdevelopment.com/
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."
Can the CAN Ports on the LPC2200 be used as RS485
Started by ●November 23, 2007
Reply by ●November 25, 20072007-11-25
Reply by ●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.
Robert
http://www.aeolusdevelopment.com/
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."
>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.
Robert
http://www.aeolusdevelopment.com/
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 ●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.
Regards,
Richard.
> 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.
Regards,
Richard.
