• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 32 subscribers
  • Views 2896 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.

How to know UART transmitter buffer is empty after serialization in Tiva TM4C123GH6PM MCU

dredg dredg
Prodigy 70 points
Other Parts Discussed in Thread: TM4C123GH6PM

Hello Everyone

I am using RS-485 physical interface for serial communication. I would like to disable RS-485 transmit mode after sending data to another device. That's why I need to know when transmitter buffer is empty after serialization. Thus I can disable transmit mode and make RS-485 IC into receive mode to listen master. I am currently doing this with adding time delay after sending data. But I know that this is not true and professional...

Thanks in advance

dredg

  • 0
    Guru 92251 points

    dredg dredg said:
    That's why I need to know when transmitter buffer is empty after serialization.

    The BUSY bit in the UART Flag (UARTFR) register should be able to tell you that. The BUSY bit is documented as:

    UART Busy


    Value Description
    0         The UART is not busy.

    1         The UART is busy transmitting data. This bit remains set until the complete byte, including all stop bits, has been sent from the shift register.

    This bit is set as soon as the transmit FIFO becomes non-empty (regardless of whether UART is enabled).

    The TivaWare function UARTBusy() tests the value of the BUSY bit.

  • 0 in reply to Chester Gillon
    Guru 27665 points
    Unfortunately, there isn't an interrupt associated with that bit so it's only a partial solution. Polling for that bit is, in many cases, a worse solution than a timer.

    A complete solution would need an interrupt from that bit. Even better the added capability of using it to trigger a timer so that the bus has time to settle before disabling the transmitter. The need for the bus to settle pretty much mandates the use of a timer even after detecting that the transmission has finished.

    Unfortunately there is no way to know how many characters are in the transmit FIFO so you cannot calculate the time based on the number of characters to be sent unless you disable the transmit FIFO.

    Robert
  • 0 in reply to Robert Adsett
    Guru 92251 points

    Robert Adsett said:
    Unfortunately, there isn't an interrupt associated with that bit so it's only a partial solution.

    Having another read of the TM4C123GH6PM datasheet, think the End of Transmission (EOT) bit in the UART Control register can be used to generate the UART Transmit Interrupt when "all transmitted data, including stop bits, have cleared the serializer":

    - When the EOT bit is clear, the UART Transmit interrupt is generated when the transmit FIFO condition specified in UARTIFLS is met.

    - When the EOT bit is set, the UART Transmit interrupt is generated only after all transmitted data, including stop bits, have cleared the serializer.

  • 0 in reply to Chester Gillon
    Guru 27665 points

    Yep, that looks like it would work but it does effectively set the transmit FIFO level to 0. Still need to use a timer to ensure line stabilization but that's straightforward.

    The FIFO level set to zero shouldn't be a problem in most cases I would expect.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points
    May I commend the two of you (Chester & Robert) for this valuable & inspired, "back-forth?"

    Tips such as that noted here should be (somehow) properly "promoted" so that others may quickly/easily benefit. (w/in few days this thread will have rotated into (always delightful) forum oblivion.

    Bright Red "Style Bar" - atop the forum - carries essentially "worthless" Blogs, Groups, Videos. Not one mm dedicated to, "Tech Tips, App Notes, Key References!" HIDING such valuable & oft needed data serves (some) purpose - (forum masters must believe...)
  • 0 in reply to Chester Gillon
    Prodigy 70 points
    Hello Chester

    I added UART_Busy() register as a condition to my code. But It didn't work. There are missing bytes at the other side when I send data.

    As a result, There is not any sufficient way except that adding timer right ?

    dredg
  • 0 in reply to dredg dredg
    Guru 92251 points

    dredg dredg said:
    I added UART_Busy() register as a condition to my code. But It didn't work. There are missing bytes at the other side when I send data.

    Can you show the code?

  • 0 in reply to dredg dredg
    Guru 27665 points

    dredg dredg said:
    There are missing bytes at the other side when I send data.

    Several bytes on each packet?

    If it's only a single byte per packet then my comment on line stabilization may apply.  You have to delay turning off the transmitter until all transmission delays have been accounted for. Some protocol standards actually give a required time for this extra drive period.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points
    Minus poster's code - and his imprecise, "missing bytes" this diagnosis may not succeed. (which bytes, how many?)

    I see no clear mention of poster's adopting the "EOT" test. Instead, "UART_Busy() register" appears as his central conditional test.
  • 0 in reply to Chester Gillon
    Prodigy 70 points

    Hello Everyone

    It was my fault that I said UART_Busy() didn't work. Sorry for that !! The problem was related with my modbus RTU timing.

    It worked and now works great with 500ms polling. Master send approximately 10000 polls and there are no errors and missing bytes.

    Thanks for suggestions.

    dredg