• State Answer Suggested
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 2085 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

a use case of idle line mode

bj Wang
Prodigy 235 points

Hello Guys

I have two devices which communicate with each other using UART. One is master, the other is slave.

Master will send a frame( flexible length) to slave and slave will reply a frame.

I am wondering if it is possible that slave can use idle line mode to detect the end of a frame.

I notice that spec says an idle receive line is detected when ten or

more continuous ones (marks) are received after the one or two stop bits of a character.

Thanks in advance.

  • 0
    Guru 58965 points

    I have never used idle-line mode, but I do not think it will work for you. It is able to detect the first byte after an idle gap and ignore all other bytes. It is not able to receive bytes and detect idle gap.

    For variable frame length, you can either include the length as part of your frame, or reserve a special character to indicate the end. People usually use EOT, ENQ, CR, LF, or NUL.

  • 0 in reply to old_cow_yellow
    Prodigy 235 points

    Thank you for your reply. I want to use it to coorperate with DMA to receive a variable frame, meanwhile i hope there is

    less enough( only one for a frame)  interrupt generated when receiving the data.

  • 0
    Guru 227245 points

    OCY is right. Idle line mode is an alternative to address byte mode in a multi-peer setup. It means, when an incoming byte is preceded by at least 11 ‘1’-bits, then it is considered to be the destination address (a bit like SPI, but instead of a start condition, a gap is used).

    If you need to know when a package is done without knowing its size, you can start a timer each time you receive a byte. When the timer expires before the next byte has arrived, you can assume that no more bytes follow and continue. Of course this requires that you have a defined minimum gap between two packages. And ensure that all bytes of a package are sent without a too-large gap.

    When using DMA, things are more complicated. You can't start a timeout timer when you don't get an interrupt on each (or at least on the first) byte of a transfer.
    What you could do is waiting for the first byte with an RX ISR. In this ISR, you start the timer and the DMA. When the timer triggers, you can pocess all received data. THis means, your timeout must be shorter than the frequency of which the frames come in, but long enough for the longest frame to arrive. It also means that you won't process shorter frames faster.

  • 0 in reply to Jens-Michael Gross
    Guru 46710 points

    Jens-Michael Gross said:
    It also means that you won't process shorter frames faster.

    Which also means that you can do fixed frame length without timer as well.

  • 0 in reply to Ilmars
    Guru 227245 points

    Ilmars said:
    Which also means that you can do fixed frame length without timer as well.

    Sure you can. Simply wait for n bytes to arrive.

    Bbut that wasn’t the task. The task is detecting the end of a fram with unknown length. So a timeout is required to determine the end of the frame. And when you receive using DMA, you don’t know the time of the last received byte and therefore need to set the timeout for the maximum time any frame may take.

  • 0 in reply to Jens-Michael Gross
    Guru 46710 points

    Jens-Michael Gross said:
    Bbut that wasn’t the task. The task is detecting the end of a fram with unknown length.

    Task is data transmission, not frame end detection ;)

    Often engineers try to solve problems of improperly defined tasks rather than to look at the whole thing from different angle to possibly find much more elegant and simple way of implementation.

  • 0 in reply to Jens-Michael Gross
    Prodigy 235 points

    Thank  you for you solution. I think it is my last choice, :). I am trying to find a simply and more efficient  way to implement a receiving way using DMA. I seems that i can not implement my case on MSP430.

  • 0 in reply to Ilmars
    Guru 227245 points

    Ilmars said:
    Task is data transmission, not frame end detection ;)

    No. From OP:

    bj Wang said:
    Master will send a frame( flexible length) ....  detect the end of a frame.

  • 0 in reply to Jens-Michael Gross
    Guru 46710 points

    Jens-Michael Gross said:

    Task is data transmission, not frame end detection ;)

    No. From OP:

    bj Wang said:
    Master will send a frame( flexible length) ....  detect the end of a frame.

    [/quote]

    LOL you prove what I was talking about :D

    JMG, I am not talking about your task "solve EOF detection problem" but task of engineering in original project which supposedly is data transmission. I highly doubt that thread author is building end of frame detector which ignores any data sent.

  • 0 in reply to Ilmars
    Guru 227245 points

    When the use case is a variable length frame whose end has to be detected without knowing the size beforehand, it is pointless to talk about solutions for a known fixed frame size. Yes, it is about data transfer, but about a specific and clearly specified kind of data transfer.

    Re-reading all your comments, I can imagine you wanted to say that when I suggest waiting for the longest possible time of a frame, then one could do a fixed frame size as well. Well, that’s right, but this would require changing the master to use a fixed maximum-size frame. And changing the master was not part of the discussion (and often enough is impossible as the master is given as-is).

  • 0 in reply to Jens-Michael Gross
    Guru 46710 points

    Jens-Michael Gross said:
    I can imagine you wanted to say that when I suggest waiting for the longest possible time of a frame, then one could do a fixed frame size as well.

    You are so right.

    Jens-Michael Gross said:
    And changing the master was not part of the discussion

    However it was not specified that it's impossible. This is my point - that if you don't look at whole picture of possibilities you probably are not working on most effective solution.

    To conclude: variable frame size receive most probably is very tough and bumpy road to go if you want to use DMA. Especially  when header does not have frame length info

**Attention** This is a public forum