UART-->RS485 (transmission is finished and it may respond)

KlausST said:

Hi,


This is a protocol.
Without protocol it can't recognize commands..

Klaus

Click to expand...

OK, then it's usual acynchronous serial protocol.

Default: 9600 baud rate, 8 data bits, even parity, 1 start, 1 stop bit.

Hi,

Default: 9600 baud rate, 8 data bits, even parity, 1 start, 1 stop bit.

Click to expand...

This is no protocol, these are interface setup parameters.
..but the interface setup may just be the a tiny part of a protocol.
https://en.m.wikipedia.org/wiki/8-N-1

In the protocol the timing should be specified, as well as the meaning of the bytes (bits).
https://en.m.wikipedia.org/wiki/Communication_protocol

Klaus

KlausST said:

Hi,


This is no protocol, these are interface setup parameters.
..but the interface setup may just be the a tiny part of a protocol.
https://en.m.wikipedia.org/wiki/8-N-1

In the protocol the timing should be specified, as well as the meaning of the bytes (bits).
https://en.m.wikipedia.org/wiki/Communication_protocol

Klaus

Click to expand...

Acynchronous Serial Communication is called (in the same WIKI) as a most common protocol in use.

Lets see here: https://en.wikipedia.org/wiki/RS-485

BR

There is apparently a different understanding of some terms, e.g. does a protocol definition necessarily include the frame specification. Term definitions can't be distinguished as right or wrong, they are more or less useful for a specific application range. Often different definitions coexist in science and engineering.

If you also review the "Applications" above the quoted "Protocols" paragraph in the Wikipedia article, you'll notice that the former involves a narrower definition of the term protocol than the latter.

Term definitions don't tell what's wrong in your system. I see at least this possible problems:

- Unsuitable RXDEN timing. If so. it's a low-level firmware, e.g. UART driver problem
- Missing or inappropriate RS-485 bias resistors, line not reliably in idle state when all drivers are deactivated
- Collisions due to wrong framing or incompatible parameters

FvM said:

There is apparently a different understanding of some terms, e.g. does a protocol definition necessarily include the frame specification. Term definitions can't be distinguished as right or wrong, they are more or less useful for a specific application range. Often different definitions coexist in science and engineering.

If you also review the "Applications" above the quoted "Protocols" paragraph in the Wikipedia article, you'll notice that the former involves a narrower definition of the term protocol than the latter.

Click to expand...

The master really doesn't know any protocols, except mentioned above the most common ASC protocol. That's fully in line what I have in practice, on the bench.

FvM said:

Term definitions don't tell what's wrong in your system. I see at least this possible problems:

- Unsuitable RXDEN timing. If so. it's a low-level firmware, e.g. UART driver problem
- Missing or inappropriate RS-485 bias resistors, line not reliably in idle state when all drivers are deactivated
- Collisions due to wrong framing or incompatible parameters

Click to expand...

May I ask, you figured that out based on #16? I gave some additional info there.

BR