+ Post New Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 25 of 25
  1. #21
    Junior Member level 1
    Points: 90, Level: 1

    Join Date
    May 2019
    Posts
    17
    Helped
    0 / 0
    Points
    90
    Level
    1

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

    Quote Originally Posted by KlausST View Post
    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.
    Last edited by intiCA; 14th May 2019 at 06:28.



    •   AltAdvertisement

        
       

  2. #22
    Super Moderator
    Points: 76,257, Level: 67
    Achievements:
    7 years registered
    Awards:
    Most Frequent Poster 3rd Helpful Member

    Join Date
    Apr 2014
    Posts
    15,467
    Helped
    3516 / 3516
    Points
    76,257
    Level
    67

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

    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
    Please don´t contact me via PM, because there is no time to respond to them. No friend requests. Thank you.



    •   AltAdvertisement

        
       

  3. #23
    Junior Member level 1
    Points: 90, Level: 1

    Join Date
    May 2019
    Posts
    17
    Helped
    0 / 0
    Points
    90
    Level
    1

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

    Quote Originally Posted by KlausST View Post
    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



    •   AltAdvertisement

        
       

  4. #24
    Super Moderator
    Points: 258,502, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    45,132
    Helped
    13720 / 13720
    Points
    258,502
    Level
    100

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

    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


    1 members found this post helpful.

  5. #25
    Junior Member level 1
    Points: 90, Level: 1

    Join Date
    May 2019
    Posts
    17
    Helped
    0 / 0
    Points
    90
    Level
    1

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

    Quote Originally Posted by FvM View Post
    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.


    Quote Originally Posted by FvM View Post
    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 by intiCA; 14th May 2019 at 12:55.



--[[ ]]--