RS-485 Synchronous Mode ( CLK + DATA )

[ag123]

think clk is normally not 'bundled' in RS485 implementations and that clk & 'synchronous' is probably some "propriety" phy and protocols.
as i didn't work much with RS485, hence, I'd leave it at that.
for 'simple' implementations, i'd just use a uart to interface it.

async 'clock recovery' is 'difficult' and hence I'd guess the designers just made it 'synchronous' by putting a clk line, but that clk on its own can also be noisy or be slew limited (long lines practically work like rlc filters) and possibly limit the distance/length possible.

I think differential signalling
https://en.wikipedia.org/wiki/Differential_signalling
works like flipping the battery between the +/- signals forward and reverse literally. Hence, it is possibly 'easier' to use a transceiver e.g. rs485 / rs422 to translate the signals back to the 'normal' 0 and 1 signals.

[Smokey]

Read what the OP wrote: the systems don't share a common ground. In such cases it is better to use AC coupling and not rely on wether the ground is connected somewhere or not. IIRC ISDN2 is an example which uses HDLC over AC coupled links.

Again: it would be wise for the OP to investigate whether the links are AC coupled or not or that there are other measures to deal with ground offsets (which can include using transceivers with increased common mode ranges).

Isolated transceivers solve the lack of ground maybe?
https://www.ti.com/isolation/isolated-interfaces/rs-485-transceivers/overview.html

[pacioc193]

Read what the OP wrote: the systems don't share a common ground. In such cases it is better to use AC coupling and not rely on wether the ground is connected somewhere or not. IIRC ISDN2 is an example which uses HDLC over AC coupled links.

Again: it would be wise for the OP to investigate whether the links are AC coupled or not or that there are other measures to deal with ground offsets (which can include using transceivers with increased common mode ranges).

Isolated transceivers solve the lack of ground maybe?
https://www.ti.com/isolation/isolated-interfaces/rs-485-transceivers/overview.html

Yes, as already suggested by PCB.Wiz the solution could be to use a isolated transceivers.
I will test and let you know.

[harerod]

Keyword: SSI - Synchronous Serial Interface

This is an industry standard for encoder communication. My first implementations have been on FPGA's. About ten years ago I switched to STM32 - e.g. https://www.harerod.de/applications_eng.html#SSI_USB
A STM32F405 will handle 2MHz in slave mode (sensor emulation) without any sweat. In master mode the transceiver chips limit clock to 10MHz on that board.

Another limitation, for which exist partial software remedies, is the reduced lightspeed in cables. For CAT5 that would be about two thirds of the speed of light in vacuum.

[pacioc193]

Keyword: SSI - Synchronous Serial Interface

This is an industry standard for encoder communication. My first implementations have been on FPGA's. About ten years ago I switched to STM32 - e.g. https://www.harerod.de/applications_eng.html#SSI_USB
A STM32F405 will handle 2MHz in slave mode (sensor emulation) without any sweat. In master mode the transceiver chips limit clock to 10MHz on that board.

Another limitation, for which exist partial software remedies, is the reduced lightspeed in cables. For CAT5 that would be about two thirds of the speed of light in vacuum.

I worked with this MCU but the SSI is a fake communication... it use a USART communication adding a clock on the right byte. It is 8bit aligned and for each data that i write on the bus, a lot of time is lost due a empty time spend to generate signal of start bit, parity bit, stop bit ecc ecc

I preferred to bit bang it....

[pacioc193]

Test continue and the project is not yet finished….
I’ve tested with isolated converter and communication seems works but not in the correct ways…
Is there any equipment to check the isolated 485 signal without transceiver it to ttl?
Like oscilloscope or logic analyzer . Is impossible for me to get the ground from the destination cpu… I’ve already tested to use the ground from power supply but the signal is not present into a classic clone logic analyzer.
Any tips?

[pacioc193]

Finally i understood the problem...

Protocol is HDLC that force a bit stuffing when a more than 5 bit are "1" consecutively.

The byte 0x5F ->  0101 1111 will be translate to  0 1001 1111 (0x09F) to avoid the flag 0x7E misinterpreted.

My board then is working well... I need just to correct the reading from my custom mcu in order to implement this behaviour.

[jjcrawford1990]

Fascinating read. I had a similar problem having to find hardware to communicate with an RS485 Synchronous HDLC device in the railway, I searched for an off the shelf piece of equipment for a while before finding one. However the SDK was horribly complex and although I got it working, I’d love something simpler (comparatively)

If you would be willing to share any of the design, it’d be fascinating

[pacioc193]

Fascinating read. I had a similar problem having to find hardware to communicate with an RS485 Synchronous HDLC device in the railway, I searched for an off the shelf piece of equipment for a while before finding one. However the SDK was horribly complex and although I got it working, I’d love something simpler (comparatively)

If you would be willing to share any of the design, it’d be fascinating

Are you still interest?
We are going in production with some prototype...

[David Hess]

It seems that no commercial microcontroller has this kind of synchronized serial capability.

You could bit bang it, but peripherals like SPI or a USART (universal synchronous and asynchronous receiver-transmitter) produce synchronous serial data, with separate clock and data signals.  RS-232 had a synchronous serial pinout and RS-422 (V.35?) did also, relying on a USART.

[Doctorandus_P]

A few weeks ago I read a bit about bitbus It's an old communication protocol made by intel somewhere in the early '80-ies and it has an extremely big overlap with the protocol described here. It uses SDLC (presumably predecessor of HDLC?). It also uses bit stuffing (but I think it always inserts a bit in the middle of each byte) and one of it's modes is to send Clock & Data by using two RS485 transceivers. I have not read the ful specs, and am not very familiar with details of this bus.

There is very little information about this protocol on wikipedia. It just has a short mention in: https://en.wikipedia.org/wiki/Fieldbus#Bitbus

I am unsure how much this bus is used BEUG (Bitbus European Users Group) has some info, but it's mostly very old

https://html.duckduckgo.com/html?q=bitbus+beug
http://www.bitbus.org/

[Smokey]

...
We are going in production with some prototype...
...

Um ..   I think your definition of "production" might be different than what I have in mind....