cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Mentor
Mentor
11,897 Views
Registered: ‎06-10-2008

Feature Request: UARTlite with RS485 Driver Enable output signal

Hi,

 

It would be a really nice feature if the Xilinx UART-lite IP core would have an (optional) output signal that can automatically drive the Driver Enable (DE) of an RS485 transceiver. AFAIK there is currently no Xilinx IP for a UART that can do this.

 

Maarten

0 Kudos
16 Replies
Highlighted
Voyager
Voyager
11,718 Views
Registered: ‎04-21-2014

I agree, but I am guesing this is not going to be a high priority.  In the meantime, you might use a different AXI GPIO module, configured as all outputs, 1 bit.  Or, if the source code is provided, you could always modify it.  (I think the source code is provided in this case).

***Many of us who help you are just FPGA enthusiasts, and not Xilinx employees. If you receive help, and give kudos (star), you're likely to continue receiving help in the future. If you get a solution, please mark it as a solution.***
0 Kudos
Highlighted
Mentor
Mentor
11,699 Views
Registered: ‎06-10-2008

Using GPIO it gets harder to achieve correct timing. The software must know when the last stopbit has been sent before it can disable the driver enable. And if the software waits too long the other side might already be sending a response when this side is still holding the driver enabled.

0 Kudos
Highlighted
Mentor
Mentor
11,656 Views
Registered: ‎06-10-2008

I was surprised by your comment that the source code might be available. Today I checked, but nowhere can I find the VHDL or Verilog sources for the uartlite. I think you are mistaken.

0 Kudos
Highlighted
Voyager
Voyager
11,573 Views
Registered: ‎04-21-2014


@vanmierlo wrote:

I was surprised by your comment that the source code might be available. Today I checked, but nowhere can I find the VHDL or Verilog sources for the uartlite. I think you are mistaken.


Where did you look?

***Many of us who help you are just FPGA enthusiasts, and not Xilinx employees. If you receive help, and give kudos (star), you're likely to continue receiving help in the future. If you get a solution, please mark it as a solution.***
hereitis.gif
Highlighted
Mentor
Mentor
11,561 Views
Registered: ‎06-10-2008

Apparently in the wrong places. Thank you!

0 Kudos
Highlighted
Voyager
Voyager
11,498 Views
Registered: ‎04-21-2014

You're welcome.  Vivado is a powerful tool, but with so much power there are little knooks and crannies that are sometimes not obvious.

***Many of us who help you are just FPGA enthusiasts, and not Xilinx employees. If you receive help, and give kudos (star), you're likely to continue receiving help in the future. If you get a solution, please mark it as a solution.***
0 Kudos
Highlighted
Mentor
Mentor
11,192 Views
Registered: ‎06-10-2008

I have modified uartlite_tx.vhd and the wrapping modules to add a TXEN output. I have not yet tried to get it into a Block Design with GUI configuration. Attached is a patch that can be applied to the axi_uartlite_v2_0 sources.

In the picture below you can see a 2 bit times delay after tx_Enable goes active before the first start bit is transmitted at 115k2. The data is two 'U's (0x55) a rest and again two 'U's.

 

uartlite_rs485.png

 

As far as I'm concerned everyone, including Xilinx, is welcome to integrate this into their design.

 

N.B. the signal tx_Data_Enable should maybe renamed to tx_Bit_Trigger for clarity of its purpose.

Highlighted
Visitor
Visitor
3,583 Views
Registered: ‎07-16-2018

Hi @vanmierlo, I'm a SW engineer working with our FW engineer on a custom Zynq 7035 board on which we have a UARTLITE hooked up to a RS485 transceiver (MAX13432) which is configured to do half duplex (A/B represent the D-/D+, X/Y is tied to A/B, respectively) externally.  Our FW engineer was able to implement the PL to automatically drive the DE pin high on transmits and drive it low otherwise; ~RE is hooked to ground.  So far we have successfully transmitted from the Zynq to a remote host (connected to a RS485 to USB dongle); the Zynq PS is running Linux 4.0.0 and we access the UARTLITE via /dev/ttyUL0; we didn't make any changes to the UARTLITE definition in device tree or the UARTLITE driver.  Unfortunately we're not able to get traffic going the other way from the host to the Zynq; I don't see any receive interrupts coming in (/proc/tty/driver/uartlite); we know the RS485 USB dongle transmit is working for sure because we tested 2 dongles back to back.

 

It there any hints or suggestions what we should look at?  I believe the control pins (DE and ~RE) are hooked up correctly because transmit is working.  Is there anything special that needs to be done on the PS side?  Do we need to change the UARTLITE definition/configuration in the device tree (I found some example adding modem control)?  Is the Linux UARTLITE driver good enough or there needs to be extra processing implement for RS485 mode?  Hoping to hear from you or anyone else.  Thanks.

0 Kudos
Highlighted
Mentor
Mentor
3,576 Views
Registered: ‎06-10-2008

I suggest to measure DE at the MAX13432 and see if it really does what you expect. You can also measure A/B and X/Y. From your description I suspect the driver is always enabled.

 

Another option is that the interrupt is not properly connected or configured.

 

There should be no need for any software modification or configuration, although Linux kernel 4.0.0 seems too old and might have a broken driver.

0 Kudos
Highlighted
Visitor
Visitor
3,086 Views
Registered: ‎07-16-2018

Thanks for the quick response.  We will check out the level.  We have already tried hooking DE up to a register which can be accessed by the PS and manually controlled on the Linux side; driving it high works for transmit; receive still doesn't work when we drove it low on the Linux side.

0 Kudos
Highlighted
Voyager
Voyager
1,492 Views
Registered: ‎11-30-2017

Hi,
What does the xilinx‘s linux driver for standard uartlite ip need to change if I use the patch ?
please.

---/\/\/\/\/\/\/\---
Always Online
0 Kudos
Highlighted
Mentor
Mentor
1,466 Views
Registered: ‎06-10-2008

As already stated the driver requires no patch at all.

0 Kudos
Highlighted
Visitor
Visitor
1,391 Views
Registered: ‎05-21-2018

I don't understand how to apply this patch. In Vivado 2019.1, I do not see the same sources view, nor do I see the files anywhere on my system.

0 Kudos
Highlighted
Mentor
Mentor
1,297 Views
Registered: ‎06-10-2008

You must generate the configured IP first. Or else you can find the IP sources in your Vivado 2019.1 installation directory in .../Vivado/2019.1/data/ip/xilinx/axi_uartlite_v2_0/

I have now also added the C_TXEN_DELAY parameter to the configuration dialog and regenerated the patch for the v2.0 r23 revision in Vivado 2019.1.

I still welcome Xilinx to incorporate this enhancement into their distribution.

Tags (3)
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
901 Views
Registered: ‎07-08-2013

Hi Vanmierlo,

Can you introduce how to apply this patch in vivado?

 

Thanks!

0 Kudos
Highlighted
Mentor
Mentor
144 Views
Registered: ‎06-10-2008

Hello @leiz 

I've updated the patch to remove my local paths so it can be better applied.

To apply it to the original Vivado installation, change into its installation dir and go to .../Vivado/2019.1/data/ip/xilinx/axi_uartlite_v2_0

There you can run patch to modify the sources. If you want you can test with --dry-run first.

 

$ cd /opt/Xilinx/Vivado/2019.1/data/ip/xilinx/axi_uartlite_v2_0
$ patch --dry-run -p1 < axi_uartlite_v2_0_rs485.patch
$ patch -p1 < axi_uartlite_v2_0_rs485.patch

 

 

I've checked and the patch also still applies to axi_uartlite_v2_0 revision 25 that comes with Vivado 2020.1.

Maarten

0 Kudos