CANBus -- nodes of different speeds?

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

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
                               visi.com            NIKITA KHRUSCHEV...

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 | 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 | Newsletter:

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!!
                               visi.com

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

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

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.

1. 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.

[...]

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.

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!!
                               visi.com