Forums » Software Development »
bad timing of RS485 TXE when using omap-serial driver
Added by Mihai Cristea over 11 years ago
I've used your nice guidelines describe here: http://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Driving_RS-485_transceivers
to implement the low-latency RS485 handling in the linux kernel (v3.2) - I used the patch2 because I'm using omap-serial driver.
Unfortunately, the transmission doesn't work because it seems that the timing of RS485 TXE is somewhat wrong (it stops sooner than the data start sending - as we can also see it on the scope).
I adjusted your send.c example to send 15bytes one time (to UART4). I put printk in the omap-serial.c to see the moments when it set/reset the GPIO. It seems that GPIO line is a short pulse (4ms) and what's interesting - this pulse has the same width regardless of the amount of bytes I send (you can see when comparing 2 speeds I tried: 19200 or 115200).
root@GateRO-x:~ ./serial-test/send 4
Writing [0]
[ 168.700744] omap_start_tx:SETGPIO (1)
[ 168.704620] omap_enable_ier_thri:SETGPIO (0)
I tried to check the places where it turns off, but unfortunately, I cannot understand why and how to fix this issue.
Could you give me a hint, please?
Thank you in advance,
Mihai
Replies (5)
RE: bad timing of RS485 TXE when using omap-serial driver - Added by Michael Williamson over 11 years ago
Hello Mihai,
Would you be willing to share your modified send.c code?
-Mike
RE: bad timing of RS485 TXE when using omap-serial driver - Added by Mihai Cristea over 11 years ago
sure, here it is.
I also put the patched omap-serial.c to check that your patch has been properly applied and the points I've put "printk"-s.
Cheers,
Mihai
| send.c (2.48 KB) send.c | |||
| omap-serial.c (46.9 KB) omap-serial.c |
RE: bad timing of RS485 TXE when using omap-serial driver - Added by Michael Williamson over 11 years ago
Do you see this problem on all the UARTS? Or just UART4?
-Mike
RE: bad timing of RS485 TXE when using omap-serial driver - Added by Michael Williamson over 11 years ago
I think you are missing part of the patch, which was original written against 3.1 of the kernel.
Take a look at the serial_omap_stop_tx() call in our 3.2 branch omap_serial.c
Around line 159, you are missing the code that waits for the transmit FIFO to empty before disabling TXE. That will hold the TXE line high until the DMA FIFO transmission completes.
-Mike
RE: bad timing of RS485 TXE when using omap-serial driver - Added by Mihai Cristea over 11 years ago
Yes, you were right regarding the falling of RS485-TXE line after data ends: in the version 3.2 we have the RS485-TXE code moved from serial_omap_enable_ier_thri() to serial_omap_stop_tx().
It works perfectly now; in our measurements we found:
RS485-TXE rises by 6us before the data (at 115200bps), or 15us (at 19200bps)
RS485-TXE falls at 2us behind the data bit-stop (regardless of baud-rate).
Many thanks,
Mihai
