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.

TM4C129XNCZAD: Is it correct to loop, waiting for the transmit buffer to empty, to know when to turn off the RS485 transmitter?

Part Number: TM4C129XNCZAD
Other Parts Discussed in Thread: EK-TM4C1294XL

I am taking over some code, and this part does not seem right to me.  I don't think it's correct to sit and loop, waiting for the transmission to complete.  Can anyone tell me how it should be done?

void XmitBfr_HB( void )
{
    char ch;
    unsigned int i;

    Enable_UartPort_HB_Transmiter();


//In current Loop, everytime we transmit somthing, we need to discard one received message
// because the hardware is set to receive all messages including the ones we send
  if(TTY20mA_Option==1)
  {
      msg_to_discard_HB++;
  }

  for( i = 0; i < 200 ; i++ ); // Allow time for hardware to switch.


    for( i = 0 ; i < 300; i++)
    {
        ch = get_from_output_buffer_HB();
        UARTCharPut(UartPort_HB ,ch);
        while(UARTBusy(UartPort_HB)); // More data rdy?
        if(out_wrptr_HB == out_rdptr_HB)
        {
            Disable_UartPort_HB_Transmiter();
            break;
        }

    }
}

  • Hi,

      I'm currently on travel and look into your code further when I come back tomorrow. Please bear in mind that UART is full duplex. When you transmit, you also receive. It is up to your application on what to do with the received data. Your current code may just try to ignore the messages. You need to find out what exact message you are trying to ignore. 

  • Hi Charles, thanks for your reply.  While the UART is full duplex, it's connected to the client by 2-wire RS485, so the transmitter has to be turned off after each transmission to avoid a collision with the next reply.

    The code is working--you can ignore the part about discarding messages.

    I am concerned about timing of software execution.  I don't think it's correct to sit and loop, waiting for transmission to complete.

  • Hi Mark,

    If you are referring to the below line in your code then I don't really see a problem to wait for the UART to complete the transmission by polling UARTBusy. I think your code is waiting for the UART transmission to complete before turning off UART to avoid collision. 

            while(UARTBusy(UartPort_HB)); // More data rdy?

    If you look at the the UART example in TivaWare SDK it has a similar calling for UARTBusy(). 

    //
    // Send the data, which was prepared above, over the UART configured for
    // internal loopback operation.
    //
    for(ui32index = 0 ; ui32index < NUM_UART_DATA ; ui32index++)
    {
    UARTCharPut(UART7_BASE, ui8DataTx[ui32index]);
    }

    //
    // Wait for the UART module to complete transmitting.
    //
    while(MAP_UARTBusy(UART7_BASE))
    {
    }

  • Thanks very much for your reply.  We use 9600 baud to communicate with our gauges in the field.  At 9600 baud it takes about 1 ms to transmit one character.  You don't see that as a big problem in most applications? Most transmissions would probably be 30 characters or less.  Once in a while (during transmission of profile data) there could be over 100 characters.

    In a previous version of this instrument I had a 1 ms periodic interrupt, and in the interrupt I would check to see if the transmit register was empty, and then turn off the transmitter, so I didn't have to have the main loop sitting and waiting.  I haven't figured out how to do that with this chip yet.

  • Hi Mark,

    In a previous version of this instrument I had a 1 ms periodic interrupt, and in the interrupt I would check to see if the transmit register was empty, and then turn off the transmitter, so I didn't have to have the main loop sitting and waiting.

    You can do the same for TM4C129 to enable interrupt instead of polling. 

    The uart_echo example in C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\uart_echo uses interrupt mode.