Reply by January 22, 20162016-01-22
On Fri, 22 Jan 2016 14:01:39 +0100, pozz <pozzugno@gmail.com> wrote:

>I read the following page: >http://xpcc.io/api/group__sab2.html > >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?
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 by Stef January 22, 20162016-01-22
On 2016-01-22 pozz wrote in comp.arch.embedded:
> I read the following page: > http://xpcc.io/api/group__sab2.html > > 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 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.
> 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.
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.
> 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.
Those are hacks when you have no other options, have used them as well.
> 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?
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. -- Candice Bergen
Reply by pozz January 22, 20162016-01-22
I read the following page:
http://xpcc.io/api/group__sab2.html

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?