• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 103 subscribers
  • Views 893 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3352: RS-485 transmit issue

user6007703
Prodigy 40 points
Part Number: AM3352
Hi,
Chip: am3352
System: rtLinux 4.14
Sdk version: v05.02

After the rs485 port is enabled, the data will be sent immediately. After the test room test, the feedback does not meet the company standard. The following is the test room problem feedback description, please help us to view

Transmit, enable waveform (end of envelope to end of transmission)

At this point, it is necessary to confirm that the last bit of valid data is within the envelope. If the last data bit is low, the envelope time must include at least 1 data bit + 3us. For example, if the baud rate is 9600, :1/9600+3us=104+3=107us, if the last 1 data bit is high, (1/9600)*2+3us=211us. Note: The last 1 bit of data is low level, high level, all need to be tested, at least 10 frames of data.

At present, the envelope of 9600 baud rate ends up to 2us at the end of transmission, which does not meet the requirements.

Rs485 device tree configuration information:

RS485 part schematic:

How to overcome this issue ? Please provide me the guidance.

  • 0
    TI__Guru*** 140686 points

    Hi,

    If you bypass the RS-485 transceiver and directly measure the RX/TX signals, do you see the same behavior?

  • 0 in reply to Bin Liu
    TI__Mastermind 26801 points

    Update offline progress of this question for tracking:

    TI feedback: 

    The UART/RS-485 requirement of 1~10bit delay in DE control is not possible in Linux.

     The value passed into 'rs485-rts-delay' DT property is in milliseconds, not bits. So setting <1 1> to 'rs485-rts-delay' would add minimum 10bits delay for 9600 baudrate, so it is not possible to add 1bit delay.

     By the way, currently the 8250-omap serial driver doesn't support setting DE delay in DT, so this is the reason why the customer doesn't see any effect when set 'rs485-rts-delay = <1 1>' in DT.

    It is not possible to implement this requirment in linux.

     1bit time in 9600 baudrate is about 104us, and Linux serial core driver only supports minumum 1ms delay.

    If both sides have further question, please update here.

  • 0 in reply to Tony Tang
    Prodigy 40 points

    Hi.

    The kernel functions ndelay, udelay, and mdelay serve well for short delays, delaying execution for the specified number of nanoseconds, microseconds, or milliseconds respectively.The u in udelay represents the Greek letter mu and stands for micro.

    Their prototypes are: 

    #include <linux/delay.h>
void ndelay(unsigned long nsecs);
void udelay(unsigned long usecs);
void mdelay(unsigned long msecs);

    The implementation of udelay (possibly ndelay is also) uses a software loop based on the processor speed calculated at startup, using the integer variable loos_per_jiffy.
    Can the RS485 device driver be changed by the udelay function, and the delay of the RS485 interface enable end can be increased to meet the requirements.
  • 0 in reply to user6007703
    TI__Guru*** 140686 points

    Hi,

    Yes, kernel does provide these delay functions, but your requirement is 1 bit time of 9600 baud rate which is about 104us, Linux is not a real-time OS, so even if you add udelay(104) in the driver, it is not guaranteed the delay will be exact 104usec, it could be off by tens of usec. That is why I said in my previous post that your requirement is impossible to be implemented in Linux.