CANbus on board without transceivers

[voltsandjolts]

I'm starting a project which has 3 microcontrollers (probably gonna be PIC18F26K80) on a PCB that need to share a small amount of data (I can't use one beefy micro). There are several ways to share data but I'm interested in using the ECANbus controller builtin to these PICs. I have never used CANbus so this might be a bit of a journey for me.

Since the micro's are in close proximity I think I can get away without using any drivers and simplify the 'bus' to one physical wire, as described here:

https://electronics.stackexchange.com/questions/30564/is-a-can-enabled-microcontroller-sufficient-to-drive-a-can-bus

After a quick glance through some datasheets, it seems like I should be able to setup the controllers so that I simply get an interrupt when (CRC verified) data arrives from another microcontroller. Sounds easy. The setup being the hard part.

Is this a workable solution for sharing 40 bytes of data (or so) between micros?
Any gotchas with the one wire CAN bus?

[rounin]

I've done the diode/resistor single ended local PCB CAN bus thing in the stack overflow link, it /seemed/ to work fine in the brief testing (@500kbps, 29bit mode).

I haven't tested it much though, it was mainly a "oh we didn't use these, lets hook it up in case we want to use it" thing on a multi-core MCU with 5 CAN controllers, the other CAN controllers used real line drivers and went offboard. We were actually toying with the idea of using the external CAN as a core-to-core communication thing, in case there were cache-coherency issues that were hard to solve with RAM based core-to-core messaging. We probably won't end up using it, after all.

It's probably fine. I really like CAN for control networks.

[voltsandjolts]

OK, thanks for that. I'll probably be using a much lower bit rate, around 100kbps.

CAN transceivers have a timeout function to prevent a malfunctioning node from clamping the bus. I guess that will be one downside of not using a transceiver, the one wire bus implementation can be clamped by a bad node.

[clee781]

OK, thanks for that. I'll probably be using a much lower bit rate, around 100kbps.

CAN transceivers have a timeout function to prevent a malfunctioning node from clamping the bus. I guess that will be one downside of not using a transceiver, the one wire bus implementation can be clamped by a bad node.

The CAN hardware in your MCU should still have the capability to detect frame errors. There should be error counter registers in there somewhere named TEC and REC. When either of these increment to 127, your MCU will probably either generate an interrupt, or take a pre-configured action such as disabling the CAN peripheral. Someone should correct me if i'm wrong, since I have wondered this for a while myself, but I don't think the CAN transceiver is anything more than a simple differential transceiver. You could just as easily use CAN over RS485 transceivers as long as you have them on every node.

[rounin]

Someone should correct me if i'm wrong, since I have wondered this for a while myself, but I don't think the CAN transceiver is anything more than a simple differential transceiver. You could just as easily use CAN over RS485 transceivers as long as you have them on every node.

I think most transceivers these days have something like the "TXD dominant time-out function" in the TJA1043 https://www.nxp.com/docs/en/data-sheet/TJA1043.pdf, that will start ignoring the controller (MCU) if it appears to be stuck low. They also usually have some provisions for low power sleep and wake-on-bus-activity with an external 12V power supply (eg, car battery) that can turn on a local regulator when some master node starts talking. You might not care for non-automotive applications.

[rounin]

This one is one of my favorites - TJA1055 https://www.nxp.com/docs/en/data-sheet/TJA1055.pdf. It can fall back to single ended mode automatically if it detects a bus fault, including mutual CANH/CANL short, either to ground, either to battery, ...

It also allows for distributed termination, so you can do star networks in weird topologies. It can disconnect/reconnect the termination automatically in certain fault conditions as needed. So some of them do more advanced things.

[Phoenix]

We've done exactly this idea with a product at my last job. 3 micros (2 ti for power electronics, one pic32 supervisory/display), the pic32 was even over an isolation barrier (2 opto couplers). Single wire CAN with diodes, I forget the arrangement of the opto couplers though. This ran perfectly at 400kbps.

Sent from my G8441 using Tapatalk

[C]

OK, thanks for that. I'll probably be using a much lower bit rate, around 100kbps.

CAN transceivers have a timeout function to prevent a malfunctioning node from clamping the bus. I guess that will be one downside of not using a transceiver, the one wire bus implementation can be clamped by a bad node.

The CAN hardware in your MCU should still have the capability to detect frame errors. There should be error counter registers in there somewhere named TEC and REC. When either of these increment to 127, your MCU will probably either generate an interrupt, or take a pre-configured action such as disabling the CAN peripheral. Someone should correct me if i'm wrong, since I have wondered this for a while myself, but I don't think the CAN transceiver is anything more than a simple differential transceiver. You could just as easily use CAN over RS485 transceivers as long as you have them on every node.

The CAN bus is a wired-OR.
Un-like RS485 and others you can have many transmitters active at same time.

To get to one active transmitter, Each transmitter monitors the bus. When what is being transmitted does not match what is received the transmitter stops sending.
This back-off leaves just one transmitter still transmitting well before the Data length code (DLC) field is being transmitted.
In addition the  bus wired-OR gives

CAN data transmission uses a lossless bitwise arbitration method of contention resolution.

A  Transmitted logic 0 wins the arbitration.
So a lower value Identifier wins over a higher value Identifier.
The transmitter with lower value Identifier, keeps transmitting.
The transmitter with higher value Identifier,  stops transmitting.

https://en.wikipedia.org/wiki/CAN_bus

So only transceivers with wired-OR bus will work properly.

C

[voltsandjolts]

Thanks to Phoenix and rounin - your comments have given me enough confidence to put some time and effort into this.

[SparkyFX]

The transceivers ensure that all nodes have the proper impedance depending on the bus state, as C pointed out. Sparing them would require extra steps in the controller to check for certain error modes which the built in controller probably doesn´t, therefore you would need to bit-bang the whole protocol to make it work (lots of extra instruction cycles required, might not work out at all) even if one node misbehaves, like being stuck indefinitely.

By using single wire CAN you also give up on the differential signal and therefore common mode rejection. In that case you might be better off using other serial busses like I²C or SPI.

[tumbleweed]

Microchip CAN controllers have a feature that allows you to create a single-wire OR configuration without requiring the diodes.

If you're using the 18F26K80, the selection is done via bit CIOCON.ENDRHI (bit 5):
1 = CANTX pin will drive VDD when recessive
0 = CANTX pin will be tri-state when recessive

Just set ENDRHI=0 and CANTX won't by driven actively high (which is the default setting, btw).

Connect all the CANTX and CANRX signals together to form a single-wire bus, and add a pullup to VDD.
1K-2K should probably get you a reasonable looking signal up to a few 100khz as long as you're running them all on the same PCB.

Doesn't work any worse than other OD busses...