RS485

Can you explain a bit more? You're asking how to change UART from receive mode to transmit mode?

Yes,

Probably i was not clear.

I am trying to control com_control pin of SN65HVD72D (ie: DE n RE^bar), so that i can switch the Rx and Tx mode of the same.

I am using port B for UART and pin D0 for Com_control on controller board.

So i need to control D0, on correct time (ie: when complete transmission is done) by checking the register UARTFR which indicated wheather the transmission is done or not.

I hope i am clear.

there's more than 1 way of doing that depending or your urgency to switch D0.

you can use interrupts or just do :

while (UARTBusy(UART0_BASE)); // this for UART0

Lu��s Afonso said:

or just do :

while (UARTBusy(UART0_BASE)); // this for UART0

Maybe not!

While that function is logically correct does it fully/properly handle the following?

a) DE pin - that RS485 device - must be ordered "high" prior to transmit.  It's likely this method will - at minimum - somewhat "clip" the initial transmitted bit - or worse - fail to toggle DE into transmit mode.  (i.e. needed is the exact time at which this function asserts - ideally it should beat/precede the first bit output via the Uart - that must be checked/verified)  My (quick) belief is that, "UARTBusy()" is excellent for, "end of xmsn" recognition - but may prove suspect for, "xmsn start."

b) RS485 is a, "multi-drop" bus design - any device may transmit.  And this creates the possibility that two (or more) RS485 devices may try to transmit at the same time - yielding bus contention.  (thus the appeal of I2C which employs open-drain - rather than push-pull outputs - and has built-in, multi-transmit, "collision avoidance."  However I2C is confined to "short range")

So - you may need to design and enforce some transmission protocol which first, "sniffs the bus" to determine if it's "safe" to transmit.  Poster's, "just do" then may meet the TX logic requirement (a) but may not be expansive enough to meet, "real-world" multi-drop, RS485 bus (b) management needs...

Devil always in such, "detail" - beware solutions which arrive too quickly - are too easy...

I know the metod i sugested has some problems. i usualy use it when comunicating with the computer and i need to have good control over it.

He just asked for sometigh that showed how to see if UART was busy and there it is. Tha'ts the simplest and most "ugly" way to do it.

But since we're talking about protocol i would use a interrupt for receiving data that would enable a flag and when sending data i would use UARTCharsAvail() to check the bus with probably the combination of UARTBusy();. You could also us UARTFIFOLevelSet(); to manage priority of receive and transmit FIFO interrupts.

Any other way is beyond me but i'm sure there's better ways to manage the UART 

Lu��s Afonso said:

He just asked for sometigh that showed how to see if UART was busy

That's likely true - yet haven't we an obligation to "alert" client/user if the method proposed may cause harm?

Even the more detailed method now listed - to me - seems to "avoid" (or deal only indirectly) with the serious issue of bus contention. Multiple, connected outputs - on in unison - seems short of, "best practice."   At the very minimum - I believe the client/user should be warned - follow on analysis/action then is his/her choice...

agreed, warning should be made about each method

BTW - believe it's "great" that you're here helping/guiding others! 

That's the true spirit of the forum - and makes us all stronger.  Good luck to you in your studies/projects and thanks...

Is it possible to implement RS-485 with DMA or does the requirement for GPIO to control the DE/RE* control
line prevent this?

Charles McCallum said:

Is it possible to implement RS-485 with DMA

Danger Will Robinson! 

That's a great (I think) question.  And - our firm past did just that - but w/another's (180MHz) Cortex M4.

There's one missing point (I believe) in this RS485 based thread: certain (few) UART Ports offer a (near) full-complement of "normal - modem-like" signals.  And these "extra" signals (usually) serve to facilitate the "automatic switch-over" between RS485 TX & RX.

How or if that impacts, "direct DMA tie-in/marriage" is beyond my (this vendor) pay-grade...  (although I suspect that the occurrence of the critical UART modem signal could, "enable and launch" a proper, DMA transfer...)  Truth in advertising - we've not yet tried/achieved that w/parts here...  (clients demand that we provide M0, M3, and M4)

cb1- said:

How or if that impacts, "direct DMA tie-in/marriage" is beyond my (this vendor) pay-grade...  (although I suspect that the occurrence of the critical UART modem signal could, "enable and launch" a proper, DMA transfer...)  Truth in advertising - we've not yet tried/achieved that w/parts here...  (clients demand that we provide M0, M3, and M4)

 Hi CB1, on MSP430 side I wrote all I need to handle half duplex RS485 communication DMA and or Interrupt driven, but all device driver and management of circular buffer and interrupt too are from my code so I managed a TX free flag as semaphore to low level routines.

 I am porting protocols and code to TIVA 123, I need a lot of floating point math I suspect cannot be  handled from MSP. No trouble for all thing I was using on MSP but  I wish manage RS485 from TIVA too so:

 UARTBusy() check what? How can I sense last bit is transmitted from? My application just poll slave from one master  so just one bus master exist and all other respond to command removing the need of arbitration or magic statistic deskew timing, receiving a message is simple so I can start transmit after end of frame character but how can I detect last bit was transmitted and transmitter is in idle state?

 I still don't know enough this processor and my dream to find a good book or a guide like for MSP vanish with time...

Roberto Romano said:

my dream to find a good book or a guide like for MSP vanish with time...

Fear not - that book has been, "Duly noted" and release should be just after those pesky (and apparently unexpected) - 129 QFP devices - emerge from their cocoon...

cb1_mobile said:

Fear not - that book has been, "Duly noted" and release should be just after those pesky (and apparently unexpected) - 129 QFP devices - emerge from their cocoon...

 Hi CB1, if I follow your humor can answer where are TIVA?

http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/applications.page

 But my goal was to prepare a guide to drive RS485...

 I cannot use one MSP in front of each serial line, I need to drive multple serial lines from TIVA 123 series to slave processor. Slave processor are MSP430 with RS485 Half Duplex. I prefer to TIVA due to lowest cost small footprint and reliability.

 Again serial lines are still used to communicate with peripheral and more often half duplex RS485 than full duplex RS422 mono or multi master, why not release an Half Duplex example?

 How serial lines timing can be controlled from high level library? Are some reference text available?

 TI plan to build a clean and simple as possible new documentation tree? Actual is sparse and sometimes leaf are unconnected, why not do a fully connected tree simple to traverse when user need seek information?

Something useful is to set the Tx Uart interrupt at the very end of the Transmission:

ROM_UARTTxIntModeSet (UART5_BASE, UART_TXINT_MODE_EOT);

At TX time:

Enable_Tx_485(true);

Then in the Tx portion of the UART interrupt:

#ifdef RS485

Enable_Tx_485(false);
if ((HWREG(UART5_BASE + UART_O_RIS) & UART_RIS_TXRIS) == UART_RIS_TXRIS)
{
flag_end_tx5_dma = true;
}

#endif