• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 82 subscribers
  • Views 2363 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.

RS485 driver control

john harrington1
Prodigy 60 points

Other Parts Discussed in Thread: MSP430F2618

I am using the UART of an MSP430F2618 to drive an RS485 communication line using half duplex.  The driver must be switched on during transmit and off during receive periods.  I am using a UART interrupt to transfer a string of characters to the TXBUF register.  The interrupt occurs as the previous char is transferred from the buffer register to the shifting register.  This occurs at the middle of a start bit.  As the last character I want to send is loaded into the shift register, I put a dummy character into TXBUF to create another interrupt after this last character is actually sent.  I use this final interrupt to switch the RS485 driver off and to "kill" the dummy character by resetting the UART.  Unfortunately, by this time, half of a start bit has already gone out which can cause problems for the receiving RS485 device.  This technique has worked with other versions of MSP430s but not this one.  I have considered using "idle" line features to stop the "start" bit but this only delays the same problem.  I tried using the UCBUSY flag but it doesn't generate an interrupt and it changes state at the wrong time.  I have also considered using a timer interrupt in parallel to control the driver but my timers are pretty active doing other functions.  Any ideas?

John

  • 0
    Guru 23000 points

    The ‘Enhanced’ USCI’s have a Transmit Complete interrupt flag.

    You could try to enable Loopback (UCLISTEN) and use the Rx complete interrupt.

  • 0
    TI__Expert 6760 points

    Hello,

    Instead of using interrupts, try polling for the interrupt flag before you start a transfer.  This might give you more control.  Also maybe you can try disabling the UART interrupt before transmission of data occurs and then re-enabling it after the work is done.  

    Regards,

    Arthi Bhat

     

  • 0 in reply to Leo Bosch
    Prodigy 60 points

    Thanks for responding.  Unfortunately, I'm stuck with this processor.  I'll look into the loopback approach.

  • 0 in reply to Arthi Bhat1
    Prodigy 60 points

    Unfortunately, I have several other processes running that are time critical and I can't afford to be in a loop watching for a flag.  I could also implement a software UART but that's too time intensive for the data rate I am using.

    Thank you for the suggestions,

    John

  • 0 in reply to john harrington1
    Guru 227245 points

    UCBUSY changes state when the USCI is done (stop bit sent). However, on RS485, it is maybe necessary to keep the transmitter active for at least one more bit time, to avoid problems with signal reflections and other oddities. That’s what I experienced. On 9600Bd, I give another ms (one full byte) before I switch the transmitter off. And the other peers have a 2ms delay before they answer the last incoming byte. This is probably much too much, but for delays below 1ms, I had to do busy-waiting, which I don’t want (has something to do with my overall project and driver structure).

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

    I'm trying to keep the throughput up on the 9600 baud data link so I switch directions asap.  Also, I don't always have control on how quickly the response message begins.  The problem is UCBUSY doesn't generate any interrupts so I made a loop that just waits for this flag to switch and I found it flips even later than when the the TXBUF becomes free which is after the next start bit is half-way out.  I finally solved the problem by setting up a timer interrupt (I didn't want to) when the last byte starts going out.  Its ISR brings me back just as the last stop bit clears the shift register so I can switch the RS485 driver.  I was worried that the ISR might get serviced at slightly different times because of other ISRs and would be late sometimes but I haven't noticed that.  

    I do appreciate your response.

    john

  • 0 in reply to john harrington1
    Guru 25210 points

    john harrington1 said:
    The problem is UCBUSY doesn't generate any interrupts so I made a loop that just waits for this flag to switch and I found it flips even later than when the the TXBUF becomes free which is after the next start bit is half-way out.

    There won't be another start bit half-way out if you don't put that extra dummy byte in. Regardless of when UCBUSY changes state, once the last actual data byte is done shifting out (including the stop bit) the serial line will go idle.

    Can you try polling the UCBUSY without putting a dummy byte in after the transfer? It sounds from your description like you had half of 2 different solutions implemented.

  • 0 in reply to john harrington1
    Guru 23000 points

    Just curious; What did the loopback give or not give?

  • 0 in reply to Brian Boorman
    Prodigy 60 points

    If I don't queue up a dummy char, there will not be a subsequent interrupt to bring me back to the ISR one last time to switch off the driver.  I also have to kill the dummy char which is a little tacky but it works... at least with previous versions of the MSP.  I have other timely things to be doing besides polling UCBUSY plus, it didn't changed states at the correct time either and this was without using a dummy variable.  

    I mentioned earlier that I resorted to using a timer interrupt to bring the uP back at the right moment to switch off the driver.  The timing seems to be stable without much jitter even though there are other active interrupts.

    tnx for the comments,  john

  • 0 in reply to Leo Bosch
    Prodigy 60 points

    Leo,

    As I was considering loopback, it seemed to complicate other aspects of my design.  This comm link is a party line and there is no master or token passing so messages are fairly spontaneous.  I am using ACK/NACK to confirm delivery with CSMA to help mitigate contention.   Now that I have the start bit solved, the link is running reliably.  Sorry I don't have any useful info to share regarding loopback.  Believe me or not, I prefer to keep things simple if possible.

    john

  • 0 in reply to john harrington1
    Guru 23000 points

    Ok thanks for the info.

**Attention** This is a public forum