Is it practical to make a Star Topology CAN Bus? - Page 1
Forum section: electronics / projects

author: rx8pilot
author_rank: Super Contributor
timestamp: December 18, 2020, 04:07:16 am
content: My first effort with CAN bus and practical question #1 came pretty quick.With a single controller/transceiver is there a way to arrange the system in a star configuration? I am thinking that a single daisy-chain setup may add complexity to the wiring effort - but a star configuration violates the stub length maximum.Is there a way around this? I am thinking that max cable length to a node would be about 50ft and probably about 8-10 nodes total.

author: fourtytwo42
author_rank: Super Contributor
timestamp: December 18, 2020, 09:22:10 am
content: Try readinghttps://en.wikipedia.org/wiki/CAN_bus#Architecturespecifically the section for ISO 11898-3 that says YES.

author: rx8pilot
author_rank: Super Contributor
timestamp: December 18, 2020, 06:11:47 pm
content: Quote from: fourtytwo42 on December 18, 2020, 09:22:10 amInteresting - it uses a higher voltage which may mean that nodes designed for this bus may not be compatible with a more typical CAN FD bus. Looking into this though.My application will be just fine at the lower bit rate.Wondering if a single CAN controller would be able to drive multiple independent transceivers.

author: rvalente
author_rank: Frequent Contributor
timestamp: December 18, 2020, 06:41:37 pm
content: Have you looked the automotive harness in detail? Id say they may employ star instead of daisy chain

author: rx8pilot
author_rank: Super Contributor
timestamp: December 18, 2020, 06:45:25 pm
content: Quote from: rvalente on December 18, 2020, 06:41:37 pmThat was my initial observation - but the documentation I have found so far seems to have strict limitations on exterminated stubs which would be rather impractical in cars where CAN bus is designed to work.Maybe the automakers do have numerous transceivers for this or perhaps some sort of passive matching network that allows splits?

author: rvalente
author_rank: Frequent Contributor
timestamp: December 18, 2020, 09:41:17 pm
content: Usually my go to source of information are bosch literature (the invetors of can)https://www.bosch-motorsport.com/content/downloads/Raceparts/Resources/pdf/Operation%20Manual_67410699_Engine_Control_Unit_MS_6.3.pdf

author: T3sl4co1l
author_rank: Super Contributor
timestamp: December 18, 2020, 09:42:09 pm
content: Sure can, in strictly functional terms. But will the reduced baud rate still be practical?Stubs can be partially terminated by introducing AC resistance at the junction; for short stubs, these can be ferrite beads, but for long stubs, a lower cutoff frequency may need to be synthesized from an R||L or something.The impedance reduces rise-time, so the bit times must be significantly longer than the worst case stub electrical length.Tim

author: rx8pilot
author_rank: Super Contributor
timestamp: December 18, 2020, 11:27:36 pm
content: The goal here is to have a main control box roughly the size of a consumer router where 8 or so generic nodes can be plugged in. The nodes could be a display, a sensor, a button pad, etc, etc all connected with dedicated point-to-point cables.Perhaps CAN is a terrible stack to consider for this sort of thing. TCPIP is too complex. RS485 was the initial choice, but it is obviously quite basic.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 18, 2020, 11:41:55 pm
content: Quote from: rx8pilot on December 18, 2020, 11:27:36 pmThe main issue is deciding what throughput you need - lower baudrates shouldn't be a problem, but as the propagation time down your stubs becomes a significant proportion of your bit time, bad things will start happenning.If the control box is in charge of everything, and nodes don't need to talk direct to each other then it doesn't need to be a common bus - individual RS485's per port would be simple and robust.

author: ejeffrey
author_rank: Super Contributor
timestamp: December 18, 2020, 11:44:49 pm
content: Is it necessary for direct all-to-all communication? Have you considered just having dedicated links for each node rather than a shared bus topology? It requires a bit larger controller on the router, but if it means you can use RS232 or RS485 instead of CAN you may make up the difference with cheaper controllers on the nodes.

author: rx8pilot
author_rank: Super Contributor
timestamp: December 19, 2020, 12:00:24 am
content: Quote from: ejeffrey on December 18, 2020, 11:44:49 pmQuote from: mikeselectricstuff on December 18, 2020, 11:41:55 pmDirect RS485 may in fact be the simplest option here. Port expansion with cheap uControllers and RS485 line drivers is easy to implement and can fairly easily be controlled from a single master. I do not believe that high-throughput is necessary. Something in the range of 125kbps should be plenty.I was hoping that there was a method of configuring CAN similar to Ethernet by using a single controller with multiple line drivers. So far, I have not seen anything like that.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: December 19, 2020, 01:25:37 am
content: I guess your problem is not so much the signalling, as that "RS-485" is just that, signalling, and you have to write the entire stack yourself... the curse of freedom is that you can put whatever you want on top of it.CAN is both a reasonably reliable signalling method and communication protocol, so is very attractive by that alone, even when it doesn't really fit some applications (for reasons such as topology, isolation (not that isolation is hard to implement, but it is extra), latency/consistency, bandwidth, distance, etc.).If you're just doing a thing, with short to moderate length cables and no expectations of bandwidth, like, 100kbps would be a lot -- sure, even RS-232 will do, but you can use the ready-to-go CANbus protocol without having to write anything.If you want more than that, then perhaps you'd like an array of CANbus networks, bridged together somehow or another? Make your router box a, well, a router proper? I don't know offhand if there's a standard way of doing that.You can make an apparently physical star network, out of a strictly linear signalling standard, if you include return pairs in every circuit. You'll need some sort of loop-back plug at the end of every spoke, so that the bus can return to the base station and go on to the next spoke and so on. Wasted wiring bandwidth, basically, but it's probably a lot easier than writing a router or bridge from scratch?I wouldn't discard Ethernet out of hand. You're talking about designing a box from scratch (I guess), when you can literally go out and buy an Ethernet router, that does all that, and more, at high speed, and literally costs the equivalent of a couple hours of labor. It's an impossibly good deal. Very heavy-weight protocol, sure, but you don't have to program it from scratch: it Just Works(tm).And when you need tighter timing, there are plenty of industrial solutions to that. Ethernet IP, EtherCAT, Profibus, etc. Which are varying degrees of proprietary, so it may depend how much you're willing to spend on interface devices or programming; but they're definitely doable, at least when enough budget is available...Tim

author: AndersJ
author_rank: Frequent Contributor
timestamp: December 19, 2020, 04:05:33 am
content: Quote from: mikeselectricstuff on December 18, 2020, 11:41:55 pmCAN has a 8 byte payload.Sending a larger payload in multiple frames may become quite messy.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 19, 2020, 09:52:05 am
content: Quote from: AndersJ on December 19, 2020, 04:05:33 amI agree 8 bytes tends to be on a low side, having to split payload to multiple messages reduces the attractiveness as you now need to implement packet framing yourself, possibly with separate transfer buffers and logic to see if all packets have been received. Due to such small payload, CAN also has overhead of approx. 60% which is quite a lot. Oh I have wished so many times BOSCH would have used the full numerical range of 4 bits they dedicated to DLC to support up to 15-byte payload. It would have been simple; just a non-implementation of unnecessary limitation.If you can use modern higher-end microcontrollers and don't need compatibility with cheap/old CAN adapters, you can use CAN FD for up to 64 byte payload. Almost everything typically transferred over CAN (except firmware updates) tend to fit on such large packet.

author: max_torque
author_rank: Super Contributor
timestamp: December 19, 2020, 05:10:53 pm
content: Quote from: T3sl4co1l on December 19, 2020, 01:25:37 am^^^ This is basically what most user variable layout arhcitectures use. By "user variable" what i mean is a BUS physical layout that is not fixed, ie where the user can reconfigure the BUS by adding or subtracting nodes. For a BUS that is fixed, you can validate it works in that particularly embodiment, but for a BUS that can and will be changed, to ensure it ALWAYS works, you are better turning a star into a linear bus by as mentioned, putting an "OUT" and a "RETURN" bus into the same harness. Basically 4 wires rather than two. This has the huge advantage of not requiring any slave device to have to have a bus end terminator, because the bus ALWAYS ends where it starts, on your 'master' module.One technique i have used for a CAN BUS, from a master device that also was the system power hub was to have multiple connectors on the master, the first of which is always used first by the user, and where a dummy "terminator" plug is simply plugged into the last free connector. Those connectors had a CAN OUT and a CAN RETURN lines, (and power for the slaves) and effectively formed a simple linear network when plugged in, in order.If you wan tyour slave devices to "pass the bus on" then they too can have two plugs, a CAN IN and a CAN OUT, and slaves that don't pass the bus on, (because they are end of the branch) have a "reflector" plug plugged into their "OUT" connector, that simply turns the bus 180deg and routes it back the way it came (no termination)Like RS-485, you can parallel Bus Transcievers, but it needs a bit of care, so you could have several electrically seperate buses, that all carry the same data. "OR'ing" the RX data means any slave replying on any of the buses will get through to the master CAN controller, and you may want to partition/gate the outgoing TX signals using external logic so that the master can talk on only one, a few, or all the buses when transmitting (depending on what you nodes need to hear etc)

author: max_torque
author_rank: Super Contributor
timestamp: December 19, 2020, 05:13:47 pm
content: EXTRA:Note that the potentially significant downside of the linear bus that physically goes out and back to each slave, is that a fault ANYWHERE on this line can prevent ANY module from communicating. Whereas using multiple transcievers that can be disabled/turned off by the master means a degree of fail safe can be built into the rest of the system

author: rx8pilot
author_rank: Super Contributor
timestamp: December 19, 2020, 07:38:28 pm
content: Quote from: max_torque on December 19, 2020, 05:13:47 pmDo you see a way to parallel transceivers on to a single controller?I had earlier considered the node loop concept where each node has a CAN return. While it would work on paper, I was definitely concerned that one fault anywhere kills everything.Using a transceiver per node seems like a good concept - but only if it they can be driven to appear as a single CAN network on the controller side.

author: capt bullshot
author_rank: Super Contributor
timestamp: December 19, 2020, 09:30:15 pm
content: Quote from: rx8pilot on December 19, 2020, 07:38:28 pmYes, that should work.Simple approach:Controller TX drives TX on all transceivers, all transceiver RX are "wired-AND" to controller RX. This way the controller sends packets to all nodes, and receives packets from all nodes. But one node cannot receive from other nodes. As the CAN protocol relies on collision detection, this might break your CAN bus if the nodes send packets the usual way CAN does this. You'd have to implement some special handshaking on top of CAN to query one node at a time to avoid these collisions.The hard way:Each node and the controller must be able to receive from each other node / controller to emulate the normal CAN behaviour. So each TX input of a transceiver must be a "wired-AND" of each other RX (including TX of the controller). For eight nodes you'd need to set up eight "AND" gates with each 8 inputs.The "intelligent" way:These dual CAN transceivers do what you want, you'd need four of them for eight nodes:https://www.onsemi.com/pub/Collateral/AMIS-42770-D.PDF, and see the app note:https://www.onsemi.com/pub/Collateral/AND8351-D.PDFYou could use one CAN "bus" per two nodes, reducing the number of these transceivers to two.Anyway, if your cable lengths are limited (e.g. a few single digit meters per node) and your baud rate is on the low end (e.g. 125000 kbits), CAN will work fine if you just parallel them all at the controller side and put a terminator there and nowhere else.

author: voltsandjolts
author_rank: Unknown
timestamp: December 19, 2020, 11:02:54 pm
content: CAN is great for deterministic shared bus communication but since you have option of point-to-point links, what advantages are you getting from CAN?+ hardware CRC'd data+ differential comms (same like RS485)+ some send/receive assistance from the CAN peripheral...not much advantage over DMA transfers- limited message lengthI haven't read all the details so maybe I'm missing something, but 485 is worth considering again.+ DMA transfers+ COBS  to packetise data efficiently, use hardware CRC module if available+ more UARTs on MCUs than CAN peripherals+ simultaneous comms on multiple links (if multiple UARTS available)+ you choose message lengths- some message enc/dec work to doIMHOhttps://www.eevblog.com/forum/microcontrollers/implementing-uart-data-packets-with-consistent-overhead-byte-stuffing-(cobs)/

author: Smokey
author_rank: Super Contributor
timestamp: May 24, 2025, 06:32:25 am
content: Quote from: capt bullshot on December 19, 2020, 09:30:15 pmI'm working on a wacky bus configuration that could have used this, so you almost won chip of the day, but those guys are obsolete now. Got me all worked up for nothing.

author: Smokey
author_rank: Super Contributor
timestamp: May 25, 2025, 10:01:44 pm
content: This TI app note about making a CANBus isolator is essentially just coupling two CAN networks together with some discrete arbitration logic:https://www.ti.com/lit/ug/tidudb5a/tidudb5a.pdfI wonder if this could be extended to coupling more than 2 networks and have everything work...[Edit just to say how much I Loathe, Despise, and Detest using "TX" and "RX" for stuff like this where it's ambiguous which way the signal is actually going.]