1. Home
  2. Embedded Programming
  3. Re: control area network (CAN) bus speeds > 1Mbps possible?

Re: control area network (CAN) bus speeds > 1Mbps possible?

Issues of whether you can actually find a CAN controller that can do the

>higher speeds (it's about 6 or 7 years since I last used CAN), the main >question I would have would be whether you can afford to drop you >maximum network size? At 5 Mbps the maximum distance between two nodes >would reduce to 1/5th of the maximum distance at 1 Mbps.

In fact the drop would be much more drastic than that due to the fixed propagation times in the CAN controller and the CAN transceivers.

At lower speeds the distance drops to one half when the speed is doubled. However the maximum distance for 500 kbit/s is 100 m, for 800 kbit/s 50 m and for 1 Mbit/s only 25 m (without optocouplers, with optocouplers only 9 m).

The problem is that the total propagation time has to be counted twice when processing the ACK bit. Thus, even if the CAN controller is overclocked, the internal propagation delays remain the same. With typical CAN controller delays of 50 to 62 ns, transceiver delays 120 to 250 ns and cable propagation delay 5 ns/m, you could not reach very far even at 2 Mbit/s.

With 50 ns controller and 120 ns transceiver delay it would take at least 340 ms back-to-back propagation delay even if the devices are wired directly to each other and no optocouplers are used. This might be just enough for a 500 ns bit time (2 Mbit/s) but I really don't see how anything more than that could be used.

Paul

Reply to
Paul Keinanen
Loading thread data ...

I'm unaware of any CAN controllers you can 'overclock' to do that kind of thing.

I think you'd be better trying Ethernet or USB now, or waiting for FlexRay, which looks to be the 'real' answer... ;)

pete

--
pete@fenelon.com "there's no room for enigmas in built-up areas" HMHB
Reply to
Pete Fenelon

take a look to

formatting link
This is a CAN protocol working with 12 bytes instead 8 using 10 Mbit speed. Look for Chips at Motorola

Reply to
Janvi

"Pete Fenelon" schrieb

: > Even though we would deviate from the standard a bit, is there any way : > to run a CAN network faster than 1Mbps? like, 5Mbps? : >

: : I'm unaware of any CAN controllers you can 'overclock' to do that kind : of thing.

If the BRP is adjusted it should be easy to overclock fcan, the frequency of the µC is always far higher than at the CAN-controller. The only problem with high baudrates is maximum propagation delay. By adjustig the Sample-Point up of 87% maximum prop-seg is granted. The system should work although it is not specified in the CAN-spec.

: > I really like CAN and its feature set, but our data rate requirements : > are pushing us to other options. : : I think you'd be better trying Ethernet or USB now, or waiting for : FlexRay, which looks to be the 'real' answer... ;)

That's not the answer. If you're looking for an arbitrating protocol there will always the prop-delay-issue limiting it to 1 MBaud. I am in doubt if FlexRay is an answer, TTP/C is the far better protocol with proven mathematical models of it's security and message latency predictibility. The possibility of using a higher baudrate only is not the main selling feature of this protocol. If you're looking for a cheap bus for sensor applications CAN will still be your choice.

Regards, Taso

Reply to
Anastasios Tsitlakidis

"R Adsett" schrieb

: > > > I really like CAN and its feature set, but our data rate requirements : > > > are pushing us to other options. : > >

: > > I think you'd be better trying Ethernet or USB now, or waiting for : > > FlexRay, which looks to be the 'real' answer... ;) : > : > : > : See

formatting link
It does appear to be the next step from CAN, : providing most of the same elements and adding a statically allocated : message portion and using a different signalling layer so that can get to : much higher message rates. Unfortunately it doesn't exist as a useable : product yet.

FlexRay is not a CAN-migration, it is a protocol evolving from Byteflight and TTP/C. The reason why FlexRay is evolved are political feuds between OEM. TTP/C is a project which started 20 years ago. It is the protocol with a big research effort, it's aim is to provide a time-triggered data protocol. FlexRay is a product developed in short time, they still have problems with the protocol specification because they would violate patents given to TTP/C. Both protocols will be introduced for time-triggered automotive by-wire-applications, they are not senseful for cheap data busses as used in various applications. Btw, TTP/C products are available for a long time know! Only the physical layer is missing.

Reply to
Anastasios Tsitlakidis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.