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

[intiCA]

Hi,


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

Klaus

OK, then it's usual acynchronous serial protocol.

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

 

[KlausST]

Hi,

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

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

 

[intiCA]

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

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

 

[FvM]

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

 

[intiCA]

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.

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.

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

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

BR