CANBus -- nodes of different speeds?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I am in the process of making a device with a CAN interface. It is a
PIC chip with built-in CAN. There seems to be a desire from marketing
for TWO CAN interfaces, the reason being so there will be one local
CAN bus for sensors that communicate with my PIC-based embedded
controller, and also a more global CAN bus in which my embedded
controller is itself a node.

I feel that I would only need ONE Canbus. If I do have only one
CANBus, does that mean then that the CANBus's speed can only be as
fast as the slowest node? Thus if 10 devices are capable of 1Mbps
speed, but there is only lowly device on the bus that can only
communicate at 400kbps (such throwing out any random lower number),
then as a consequence, must I limit everyone's communication to
400kbps?

Thanks,
Mike

Re: CANBus -- nodes of different speeds?

Quoted text here. Click to load it

Usually, yes.  And they can only be as slow as the fastest node.  All
nodes have to run at the same bit rate.

Quoted text here. Click to load it

Yes.  You can place some CAN controllers into "listen-only"
mode so that they don't react to bad frames, so there's a
chance you could get a dual-speed bus to work, but it sounds
iffy to me.

--
Grant Edwards                   grante             Yow!  I feel like I am
                                  at               sharing a "CORN-DOG" with
We've slightly trimmed the long signature. Click to see the full one.
Re: CANBus -- nodes of different speeds?

Quoted text here. Click to load it
better impossible or useless.
Nodes in the "listen only"  mode do never acknowledge a received message.
- if they run in a different speed than the producer,
  - they don't understand the message - bad news
  - they don't destroy the message on the bus - the good news
  - they never good send a message
What could be the benefit of this behavior ?

A node having two CAN busses (not necessarily with different bus speeds)
could have an other advantage. E.g. in Networks like CANopen or DeviceNet,
one side can be a simple slave node, the other side a network manager for a
sub-network, controlling other nodes.

Regards
 Heinz

with best regards / mit freundlichen Grüßen

   Heinz-Jürgen Oertel
+===================================================================
| Heinz-Jürgen Oertel  port GmbH  http://www.port.de
| mailto: snipped-for-privacy@port.de
| phone +49 345 77755-0     fax   +49 345 77755-20
| Regensburger Str. 7b,     D-06132 Halle/Saale,  Germany
| CAN Wiki    http://www.CAN-Wiki.info
| Newsletter: http://www.port.de/engl/company/content/abo_form.html
+===================================================================



Re: CANBus -- nodes of different speeds?

Quoted text here. Click to load it

If it was strictly a master/slave poll/response system (with a
single master), each slave could be run in listen-only at
whatever baud rate it could support -- the slaves would be set
up to ignore bad frames.  The master could then send polls at
various baud rates (it would need to know what baud rate to use
for each slave).  When a slave heard a poll addressed to it, it
could be put into normal mode and then send a response.  After
the response is sent, it would switch back to listen-only.

In theory, I think it could be made to work, but it would be
messy.

--
Grant Edwards                   grante             Yow!  BARBARA STANWYCK
                                  at               makes me nervous!!
We've slightly trimmed the long signature. Click to see the full one.
Re: CANBus -- nodes of different speeds?

Quoted text here. Click to load it

In normal CAN operation, each node receiving a correct CRC should pull
the line to the dominant state during the ACK field, regardless if the
node is interested in the frame or not. When the transmitter detects a
dominant state in the ACK, it knows, that there is at least one other
node connected to the bus capable of receiving the frame correctly.

However, if all the other nodes are in the listen-only mode, no other
node will pull the line into the dominant state during the ACK field,
so the transmitter has no way of knowing, if the cable is connected or
not.

Thus, if someone is attempting to run the bus on two different speeds
with all nodes in listen-mode unless intending to transmit, then
disable any error ACK field error checking.

Paul
 

Re: CANBus -- nodes of different speeds?

Quoted text here. Click to load it
[...]

Quoted text here. Click to load it

And the transmit node would retry some number of times (I
forget how many), and increment an error counter.  Eventually
it will go into a bus-off error state and refuse to transmit.

Quoted text here. Click to load it

Right.  You'd need to put the transmit section of the CAN
controller in "one-shot" mode (or whatever it's called for the
part in question). Even in one-shot mode, it may still be
incrementing the error counter -- so you may have to reset that
manually to prevent it from going bus-off.

To the OP: this is all an academic exercies and would be, IMO,
a bad thing to try in the real world without a backup plan.

--
Grant Edwards                   grante             Yow!  .. I'll make you
                                  at               an ASHTRAY!!
We've slightly trimmed the long signature. Click to see the full one.
Re: CANBus -- nodes of different speeds?
Quoted text here. Click to load it

A CAN bus needs to run at a single speed.
However, running a CAN bus at high speed does not impact on processor
operation in the same way as, say, RS232 would.
Once the data is loaded into the CAN module the actual process of
transmission is handled in hardware.

Processing every incoming message would obviously have runtime
implications, but careful use of masks mean that you ignore any
messages that are directed at other nodes.

Andy

Re: CANBus -- nodes of different speeds?
Thanks to Grant, HJ, Paul, and Andy, who have given helpful insight on
the situation.

I got a reply from Microchip's app engineer, who basically says that
that I can expect transmission and reception errors if I even think of
trying to run different nodes at different speeds on a single CANbus,
which is exactly what you guys have said. Grant's suggestion of
putting some nodes into listen-only mode sounds theoretically
feasible. That's something i'll play with, but will most likely tend
to just implement the 2nd CAN interface to make life easier. Besides,
as HJ has said, there may as well be an advantage to my implementation
of a 2nd interface. My embedded controller will be the master of all
the sensors and actuators on one CANbus, and on another CANbus, this
same embedded controller will be a slave node connected with other
similiar controllers, each with their own extra CANbus and local
sensors and actuators.

My topology will look like this:
1. A CAN-to-Ethernet Gateway (probably consisting of a Coldfire chip).
The Ethernet port (and a serial modem) is the interface to the outside
world. The CAN interface is the interface to all the embedded
controllers.
CAN traffic will consist of messages to report and query status, data,
and perhaps a CAN bootloader to re-flash the embedded controllers.

2. Sensors and actuators which will be connected to the CANbus either
via CAN I/O expander chips or their own microcontrollers with either
built-in CAN or SPI-to-CAN ICs. Each embedded controller will be the
master of each of its local sensors and actuators. It is critical that
these messages be reacted to immediately, or else bodily injury can
occur. A late answer is a wrong answer in this case.

So it looks like it is much much better to implement two CAN
interfaces after all.



snipped-for-privacy@yahoo.com (Mike V.) wrote in message
Quoted text here. Click to load it

Site Timeline