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 long to wait till data sent SCI-B (SCIB) ?

Other Parts Discussed in Thread: TMS320F2806

Hello together,
Ive got a question. I have a system which is able to receive data and to send response.
I am using SCI-B (RS485) for communication. To send data, GPIO x has to be set to 1 (high), in receive mode GPIOx has to be to set to 0(low).
Initially system is in rx mode and waits for requests. When I got a request, I am switching to tx mode (I am setting GPIOx high), writing all data to

void serial_port_putchar(char a)
{
   
    // this causes the processor to hang if the transmit buffer is full,
    // but it's OK because all time critical activities take place in the ISR
    while (ScibRegs.SCIFFTX.bit.TXFFST != 0) {}
    // Place the byte to send in the transmit buffer:
    ScibRegs.SCITXBUF=a;
}

Now, when I am switching to rx mode immediatelly after I put all my values into RXBUF, some data (last parts) arent transmitted. How can I calculate time necessry to wait till complete data is sent, before switching to rx mode (setting GPIOx low again)

Thanks

Bye 

  • Hi None,

    In this application it would be more appropriate for you to use interrupts to determine when your messages are sent and recieved.  This is all detailed in the SCI Reference manual as well as the System Control and Interrupts Reference manual for the device you are using.

    Trey

  • Hi Trey, thx for your response. I have included this registers to verify if all data has been sent. Unfortunatelly I still have a data loss of around 20%

    If I got an error, it is always the last byte which is missing.

     

    // Lastly, we physically transmit our response out the serial port:      

    for (i = 0; i < j; i++)    serial_port_putchar_b(tx_buf[i]);      

    while((ScibRegs.SCICTL2.bit.TXEMPTY != 1) || (ScibRegs.SCICTL2.bit.TXRDY != 1) || (ScibRegs.SCIFFTX.bit.TXFFST != 0)){};          

    rs485_rx_mode();//set GPIO low

     

     

  • none none74545 said:

    Hi Trey, thx for your response. I have included this registers to verify if all data has been sent. Unfortunatelly I still have a data loss of around 20%

    If I got an error, it is always the last byte which is missing.

     

    // Lastly, we physically transmit our response out the serial port:      

    for (i = 0; i < j; i++)    serial_port_putchar_b(tx_buf[i]);      

    while((ScibRegs.SCICTL2.bit.TXEMPTY != 1) || (ScibRegs.SCICTL2.bit.TXRDY != 1) || (ScibRegs.SCIFFTX.bit.TXFFST != 0)){};          

    rs485_rx_mode();//set GPIO low

     

     

     

    I am using TMS320F2806

     

  • Looks like I have got the same problem as Mr.Anuchin described.

     

    http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/p/103749/364924.aspx#364924

  • None,

    The problem is that the transmit operation is a two step process.  Data is copied from the transmit FIFO into the transmit shift register.  The TXEMPTY bit which you are testing will be set as soon as the last byte is transferred from the transmit FIFO to the transmit shift register.  This gives you no guarentee that the last byte of data has been shifted out when you change the mode.

    The easiest solution to this problem is to put a delay in after the TXEMPTY check succeeds.  This will give the SCI time to transmit out the last byte.

    A better solution would be to move to a transceiver which will allow you to receive while you are transmitting.  This will prevent you from having to toggle the RE line, but will require you to ignore the copies of messages you transmitted that will now also be received by you in software.

    Try the delay first, but please look at moving to a different transceiver as adding a delay in is kind of a hack


    Trey

  • None,

    Tim King's suggestions in the other post are completely correct.

    Trey

  • Hi Trey, thanks for response.

     

    Hardware can not be changed anymore. I will try the delay.