RS485 and RTS delay

[lpcware]

Content originally posted in LPCWare by bighouse on Wed Jun 20 01:01:43 MST 2012
Hi,
i'm using the RS485 on lpc1343. I configured the RS485CTRL to use the RTS auto direction control and RS485DLY to have a delay time after the stop bit. My question: is there a way to get a delay between the assertion of RTS and the first start bit? The message should be: RTS_ON -> delay -> message -> delay -> RTS_OFF.
There isn't a registry for my question and i think the only way to do so is to disable the auto direction and set/reset manually the RTS. Any Ideas ?
Thanks

Gianluca

[lpcware]

Content originally posted in LPCWare by jagsimila on Sun Feb 21 21:59:42 MST 2016
EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the electrical characteristics of drivers and receivers for use in balanced digital multipoint systems.

This standard is widely used for communications in industrial automation because it can be used effectively over long distances and in electrically noisy environments. See here for more information.

Some CPUs (e.g., Atmel AT91) contain a built-in half-duplex mode capable of automatically controlling line direction by toggling RTS. That can used to control external half-duplex hardware like an RS485 transceiver or any RS232-connected half-duplex device like some modems.

The Linux kernel has a huge amount of drivers. Probably more than any other (even commercial) OS. Incredibly, however, it doesn't have many drivers for RS485 serial communications. This may mean that Linux is not much used in this sector, yet.
Free 300-101 Dumps

[lpcware]

Content originally posted in LPCWare by mathseng on Wed Oct 14 03:32:00 MST 2015
I understand that there is an earlier reply from NXP to use a timer. I used this advice.

Being concerned about the RTS front porch issues (lots of comments in this forum), and not needing RS-485 address detection, the project uses RS-232 with RS-485 transport hardware.
Note:  Some hardware engineers tell me that since the sampling is at the 8/16 point, the NXP RS-485 RTS timing should not be a problem.

This project uses a heavily modified version of "uart.c" from LPCXpresso v6. The code is now fully interrupt driven, feeding to/from circular buffers.
The RTS porch timing is done using a spare timer operated as a one-shot, started with the desired delay-count, and which interrupts on completion - the interrupt latency is not an issue. The code uses 2x bit-times as the front porch and 12x bit-times for the back porch. The timer parameters determine whether the timer IRQ feeds the UART for data transmission or turns off RTS.

On UART send, the code transfers as many bytes to the TX Circular Buffer as possible, turns on RTS, and triggers the 2 bit-times timer, with parameter 'frontPorch = true'. On timer completion, the timer IRQ sets a flag for the UART IRQ (parameter is pendingTHRE = true) and triggers a UART interrupt using NVIC_SetPendingIRQ(USART_IRQn), which actions after the timer IRQ exits. The UART IRQ treats this flag as if the THRE IntID has occurred and fills the Fifo and starts the data transmission.  (ie only the IRQ extracts data from the Tx Circular Buffer for sending, so need to disable ints to prevent mismatched data). This mechanism is always safe and allows concatenated sends without pulsing RTS.

On data exhaustion, the UART IRQ is raised with the THRE IntID. When it recognizes that there is no more data available (note: the last byte may still be in the process of being sent by the hardware), the UART IRQ triggers the 12 bit-times timer, which turns off the RTS signal in the timer IRQ at completion. (8 bit times for the possible character in the bit buffer, 4 bit times to clear the end of the transmitted byte for the RTS back porch).

Both of these delays work well at 115200, with the only side-effect being Breaks at the PC end at every end of transmission from the LPC, and it co-exists fine with FreeRTOS.

I hope that this technique is valid for helping with the AutoDir issue.

[lpcware]

Content originally posted in LPCWare by Dill on Wed Sep 09 04:34:02 MST 2015

I had this exact same problem (driver is not ready when first byte is sent, so autodir can't be used) on a project last year.
Now I have a new RS485 project using 11u67 and it seems that the peripheral is still broken: the first byte is sent at the exact same time RTS is asserted, imo this can't work.

Could someone from NXP please tell us if we do something wrong or confirm that autodir is broken.

[lpcware]

Content originally posted in LPCWare by larsen on Sun Sep 07 03:09:50 MST 2014

---

Quote: DiligentMinds.com
Wow this is interesting-- it looks like someone didn't think of this when they designed the peripheral in the chip!  So, this would mean that the low-level driver has to babysit this signal for the first byte going out?  Wow!  Not good!

---

I am surprised this issue has not been commented by NXP support as it seems to be quite important for proper usage of the devices. Any comments?

[lpcware]

Content originally posted in LPCWare by DiligentMinds.com on Thu Sep 06 10:44:36 MST 2012
Wow this is interesting-- it looks like someone didn't think of this when they designed the peripheral in the chip!  So, this would mean that the low-level driver has to babysit this signal for the first byte going out?  Wow!  Not good!

Maybe the sequence is: assert the RTS line (as GPIO) and send the first byte-- this is done at the application level (not the interrupt routine)-- then quickly switch over the GPIO to the RS485CTRL function (and I'm hoping that the RTS line will not "glitch" here), and then let the interrupt routine finish the rest of the message.  That way, your interrupt routine is not wasting time delaying before the first byte of the message goes out (which could affect interrupt response for any lower level interrupts).

Could you try this out, and post back if it worked?

[lpcware]

Content originally posted in LPCWare by hparracho on Wed Aug 08 05:57:36 MST 2012
Hi,

I'm facing the exact same situation here on LPC1788 and so far I haven't found a solution to this problem. The time between the OE/RTS assertion and the first start bit is too short and worse than that, isn't constant, it varies from transmission to transmission.
I'm afraid that there isn't a solution for what we want except disable the automatic RS485CTRL and do it manually.

If someone has a different opinion please let us know.

Regards,
Helder.