Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

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

Status
Not open for further replies.
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.
 

Attachments

  • protocol.png
    protocol.png
    11.2 KB · Views: 68
Last edited:


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
 

Attachments

  • Protokols_rs485.png
    Protokols_rs485.png
    25.3 KB · Views: 73

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
 
  • Like
Reactions: intiCA

    intiCA

    Points: 2
    Helpful Answer Positive Rating
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
 
Last edited:

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top