Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12590 Discussions

UART and RS485: how to control transmit enable on RS485

Altera_Forum
Honored Contributor II
2,270 Views

Hi Forum 

 

I am pretty new working with FPGAs. 

I am using the Altera UART IP core which is connected to a RS485 transmitter. 

The RS485 transmitter have a receive-enable pin and a transmit enable pin. 

Currently the receive-enable pin is always enabled. 

The transmit-enable pin is controlled with a pio-pin via software. 

 

I am currently using the driver from Altera in my software. 

Currently i am enabling the transmit-enable just before i write data to the uart and then i have put a software delay before disabling the transmit-enable pin again. 

But this "design" is not very robust as it is just a constant delay and not actually fitted to the current content. 

 

There must be a clever way to control the transmit-enable pin on the RS485 (maybe making som logic based on the sw-buffer for the uart transmit and the transmit ready bit from the uart status register ?). 

I have searched in the forum and via google but i have not been able to find something useful. 

I hope that you can give me some tips or direction. 

 

 

Best regards 

Michael
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
1,182 Views

There is a number of solutions for this. Which is better mostly depends on your application and the level of performance you need to achieve. 

You also must consider the behavior of other RS485 parties: after you have transmitted your data you must release the rs485 lines (by deasserting the transmit enable pin) before any other rs485 device possibily initiates a new transmission. If they are supposed to answer to your tx data, you may need to deassert tx enable just after the last transmitted word: so, if baud rate is high, a hardware solution could be the better choice. 

On the other hand, for medium-low baudrates or higher tx-rx delays, you could rely on a software solution which is generally easier to implement. 

For myself, I always stayed on a software implementation: even with baudrates up to 320000bps, I could achiev almost zero end-tx to txen-deassertion 

delays using the rx-complete interrupt. 

Please note that in some uart implementations the tx-complete interrupt signals the START of trasmission of last word, not the transmission end: if you use the irq to deassert txen, you will definitely lose the last data word. In such cases you could adopt a simple trick: add a fake invalid word at the end of the tx stream and use it only to trigger the isr just after the last true data has been transmitted.
0 Kudos
Altera_Forum
Honored Contributor II
1,182 Views

The default Altera UART doesn't make it easy to add hardware transmit enable function, but the fifoed avalon uart (http://www.alterawiki.com/wiki/fifoed_avalon_uart) available on the wiki can implement it for you. Then you just have to connect it to your transceiver.

0 Kudos
Altera_Forum
Honored Contributor II
1,182 Views

Thank you for your replies :) 

 

I will give the FIFOed Avalon UART a try. 

I was looking for the license conditions for this IP core, but i could find any (on the wiki it says "To be filled in... "). 

Do anyone know the license conditions for this ? is it like the ones from Altera ? 

 

Best regards 

Michael
0 Kudos
Altera_Forum
Honored Contributor II
1,182 Views

This UART is based on the one from Altera, so my guess is that it is the same license. 

 

When I don't see any notice or license with some distributed code I just assume it's public domain ;)
0 Kudos
Reply