12-08-2018 11:35 AM
I am using a ZYNQ Ultrascale
My application requires a half duplex RS485 interface to connect with various sensors.
The ZYNQ is the master and there are several slaves.
I must control the RX/TX (data direction) pins of the line driver by software (using MIO GPIO)
I want to configure the UART to trigger an interrupt when the last bit of the last byte has been sent.
Unfortunately, there is no interrupt when XUARTPS_SR_TACTIVE (UART_TX state machine) becomes false.
This is just a status.
The best thing I can do is to configure the UART to issue an interrupt when the TX_FIFO has become empty.
But this means that the interrupt is issued one byte too early, because the last byte is still in the shift register.
So I added code in the interrupt routine to poll the XUARTPS_SR_TACTIVE status to determine when to switch my data direction to RX.
But even this has a problem, because XUARTPS_SR_TACTIVE is de-asserted 1 bit time too early. It is set to zero at the beginning of the STOP_BIT
not after the STOP_BIT. Some slave devices give me framing errors. I had to add a delay of 100usec(at 9600 baud) .
Polling inside an interrupt routine is a very bad thing to do. At 9600 baud I will be stalling the system for 1msec... unacceptable.
I have studied the TRM in detail and did not find a solution to the problem
Essentially I need an interrupt when XUARTPS_SR_TACTIVE becomes FALSE, ideally a hardware generated signal to switch the data direction of the line driver.
The modem control signals do not help since they are also set/reset based on FIFO fill status.
I could do my own UART in the PL, but the PCBs are already made.
Does anybody have a clever idea to get around this problem?
12-12-2018 09:37 AM
Maybe you can have a look at Feature-Request-UARTlite-with-RS485-Driver-Enable-output-signal where I posted a patch for the UARTlite IP to handle the RS485 driver enable. Unfortunatle Xilinx seems unwilling to adopt it.
12-16-2018 08:41 AM
Thank You vanmierlo...
but your suggestion does not solve my problem.
I am using the UARTS in the PS, not the PL.
As I said in my original post, the PCBs are already made... this is an existing design.
My current solution is to interrupt when the TX_FIFO is empty... set a timer and interrupt 10 bit times later again to
change the data direction of the line driver. Awkward, but it works.
Obviously a hardware solution is more elegant.
I have accepted the fact that most UARTS (hardwired or IP) have all sorts of nonsense features implemented,
instead of what could actually be useful.
05-21-2019 08:01 PM
05-22-2019 01:35 AM
The more elegant solution is not to use a UART that is not equipped for this task.
It's like trying to use both hardware flow-control and the in-built fifo of a classic 16550. The reason to use flow-control is to fix the risk of fifo overflow due to software not being in time to handle incoming data. But you need software to toggle the handshakes! Someone clearly stopped thinking a bit too early.
05-23-2019 06:30 AM
---Someone clearly stopped thinking a bit too early.---
What is this suppose to mean?
---The more elegant solution is not to use a UART that is not equipped for this task.---
Obviously, but this is the PS-Uart which comes with the ZYNQ.
The problem is, that the PS UART does not have an interrupt when both TX FIFO as well as shift register is empty. This has nothing to do with the flow control, which cannot be used to solve this problem.
In my application I must switch the data direction immediately after the all the data has been sent. This is because the sensor immediately replies to a data request. You cannot switch the data direction when the TX-FIFO is empty, because the last byte has not yet left the shift register. When using the PS UART, the only way to do this is to interrupt when the TX fifo is empty and setup a "one shot" timer to generate another interrupt some 10 bit times later, then switch the data direction of the line driver. It works, but it is awkward.
This is the only solution I ever found when using the PS Uart.
However since, I made a new PCB and I wrote my own UART in Verilog, which actually has a hardware output which is asserted when the TX-UART is DONE.
05-23-2019 07:12 AM
It means that in my opinion National Semiconductor should have done a better job when they designed the NS16550, which is now a legacy component that everybody uses, but is broken if you ask me. I certainly was not targeting anyone in this conversation.
My reasoning was that flow control is in an equally bad state. But at least both the PS UART and the NS16550 were not designed to support RS485. Or did you find a different statement?
And if you need fast switchover of the direction, then you need hardware support and the PS UART does not provide that. Instead I suggest to use a different UART.
05-23-2019 07:31 AM
I work in the oild industry and the old fashion RS232/422 and 485 is still everywhere. We are talking about >$100K sensors which... yes... have RS232.
Virtually nobody is using flow control and 90% of the instruments do not even bother with nonsense like odd/even parity and 1.5 or 2 stop bits 6,7 or 8 data bits. The baud rate varies, but virtually all instruments do 8 bits, no parity and 1 stop bit.
Still most integrated UARTS have all this flow control nonsense, but lack essential features.
1. Interrupt when Fifo as well as shift register is empty
2. Data direction signal... for half duplex RS485
3. Proper CRC and not just a useless parity bit
4. Interrupt for detecting a gap (idle condition) in a data stream
5. Simple data framing to reduce software load especially when sending binary data
Again, old fashion RS232/422/485 is still used everywhere, while no semi manufacturer ever considers real world application. I could not find any IP anywhere which addresses these requirements, so I had to write my own Verilog UART.
05-23-2019 07:45 AM
There are UARTs out there which do have a proper DE signal. The FTDI and SiLabs USB-UARTS come to mind. And also the Maxim MAX31xx or NXP SC16750 which are SPI/I2C-UARTS. And in VHDL or Verilog you can make whatever you want, like you did. And so did I when I modified the Xilinx IP for the Uartlite (see my first reply).
05-23-2019 08:22 AM
What's the point in using the wrong tool for the job? A UART without support for RS485 should not be used for RS485. This SOC has no RS485 capable UART integrated.