• State Answer Suggested
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 278 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SN65C1167: Driving 1.5 metre cable with SPI

Jithin S
Prodigy 20 points
Part Number: SN65C1167
Other Parts Discussed in Thread: DS90LV049, THVD1452, THVD1552, SN65LVDS049

Hello TI team , 

I want to implement the below architecture based on the article http://www.ti.com/lit/an/slyt441/slyt441.pdf

The query is :

1. Currently the below use case is designed to work at SPI data rate of 6Mhz. Is it fine for 20Mhz or 50Mhz ?

2. When decoding the SPI line (MOSI) at the processor side, data which iam trying to send to the I/O board is perfect. But when i decode the SPI line (MOSI) at the DAC input, the data received there is totally different.

For ex: Data iam sending is "FF DC". But data received at the DAC input side is "00 80". Why is it happening like that? Do i need to reduce the SPI data rate below 6Mhz?

Can you please look into the same ....

  • 0
    Guru 316510 points

    The SN65C1167 supports up to 18.5 MHz, depending on the load. Please show an oscilloscope trace of the A/B signals.

    There are faster RS-422 transceivers like the THVD1552/THVD1452, for up to 25 MHz. If that is not enough, use LVDS, e.g., SN65LVDS049/DS90LV049 for up to 200 MHz.

  • 0
    TI__Guru 52052 points

    Hi Jithin,

    1. So we rate this device up to 10Mbps (5MHz) - however based on the data the worst case rise/fall would push us closer to 30Mbps (15MHz)  (I think the 10Mbps that we state on product page is very conservative) - So 20Mbps (10MHz)  may be possible as this is a pretty short bus application.  So yes you could possibly see issues at above the 6MHz you are currently running at - but it should be able to go a bit higher. 

    That being said:

    What cable is being used ? - a part number would be great.

    And

    What are your termination resistor values? 

    2.  Is It possible to get an oscilloscope shot  of the output of the MOSI at start of bus and end of bus (beginning and end of 1.5m cable) as well as the output of the R pin to confirm if there is a transceiver problem (its a bit easier to troubleshoot the transceiver from a scope shot compared to a the bad data values; as I am assuming you may be having too large of a loss due to AC losses higher data-rate - but the scope shots will help diagnose if that is the true issue at play.

    As Clemens mentioned the parts he stated (1552/1452 - would could support MOSI/MISO in one package (full duplex devices)) would increase the maximum speed of the device and might be able to handle higher data-rates.

    However 1.5 meters of cabling is well within the LVDS use case; and LVDS usually is a better choice for SPI (we are actually in the process of removing this app note you linked as its generally not best practice to use RS-485 for SPI - you can and its not incorrect but LVDS usually is much better for SPI with the same benefits of a differential system that RS-485 provides) .

    Please let me know if you can provide scope shots because I do think its most likely a data-rate limitation. 

    Best,

    Parker Dodson

  • 0 in reply to Parker Dodson
    Prodigy 20 points

    Hi,

    Thanks @ Clemens & @Parker for your response...

    1. Termination resistor used is 100R. 

    2. Please check the scope shots below:

    I reduced the data rate from 10MHz to 1MHz. First signal is the clock signal, second one is MOSI from the processor out and the third one is MOSI from the DAC input.

    As you can see, MOSI at the DAC input is an inverted one of that coming from the processor. How it get inverted? I think because of this issue, iam not getting data properly at the DAC input.

    Can you please look into the same ....

  • 0 in reply to Jithin S
    Guru 316510 points

    The inversion is likely caused by exchanging the A/B bus signals.

  • 0 in reply to Jithin S
    TI__Guru 52052 points

    Hi Jithin,

    Could you please provide the connections to DAC - I have a feeling there could be a connection issue as the inversion is not expected in RS-485 unless there is typically an implementation issue.

    Best,

    Parker Dodson

  • 0 in reply to Parker Dodson
    Prodigy 20 points

    Hi Parker,

    Your feeling is right. Inversion happened because of connection issue. Now iam getting the spi communication properly

    Thank you so much @Parker and @Clemens for your support....