Asyncronous serial bus network with UART and CAN transceiver

I read the following page:

formatting link

The author suggests to use a CAN transceiver, instead of a RS485 half-duplex transceiver, to create a serial multi-drop bus with nodes featuring normal UART peripherals. This should avoid the use of a third pin for direction control.

What do you think? Does this solution works without problems?

I think the control of the direction pin isn't simple. You should change the direction from tx to rx as soon as possible, because you need to free the bus. However, most of MCUs (at least the ones I used) lack the "automatic" control of the direction pin. In the best case, you have an IRQ when the last byte is really shifted out. But IRQ is processed with a certain latency, if other IRQs are active.

The solution is to introduce a short delay *before* starting transmitting an answer, just to be sure the other node has really freed the bus. However creating short delays isn't simple: you have to use a hardware timer, if you have one. One possibility is to use the same UART peripherla to transmit a couple of dummy bytes with direction pin in the receive state. After dummy bytes are really shifted out (they will not appear on the bus), the direction pin changes enabling the driver of the transceiver.

After all, the CAN transceiver solution should solve all those problems.

The only difference, from the firmware point of view, is you will have the echo of all the bytes you transmit on the bus... right?

Reply to
Loading thread data ...

On 2016-01-22 pozz wrote in comp.arch.embedded:

I don't see huge problems with it, but it has limitations. Maximum speed of the tranceiver is 1Mbps and the effective usable speed on the line will also depend on bus load/capacitance as the inactive (recessive) state is pulled by the 120 Ohm terminators and not actively driven.

That is not what I call 'the best case'. My current project uses a controller that automatically switches the driver in RS485 mode (alternate function of the UART RTS pin on a lot of NXP (and other) controllers). That may not always be ideal, but better than your 'best case' imo.

Those are hacks when you have no other options, have used them as well.

Well depends, you can also have a 485 receiver active while transmitting, also echoing your own bytes. But with the CAN driver there is indeed no way to switch the echo off (as it is required by actual CAN controllers for bus arbitration).

Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

Living in LA is like not having a date on Saturday night. 
 Click to see the full signature
Reply to

What is so special about this ?

Early CANbus systems used ordinary RS-485 hardware with transmit data connected to the Transmit Enable pin.

Of course, the receiving hardware had to be capable of detecting any collisions compared to your own transmitted data. At 1 Mbit/s that definitely required hardware detection, but at lower speeds, software detection could be used.

Reply to

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.