• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 221 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.

F29H859TU-Q1: Do we have the UART-simulation LIN solution?

Shuqing Zhou
Expert 3215 points

Part Number: F29H859TU-Q1

Hi team,

I ask this for my customer.

My customer is evaluating F29H859TU8ZEXQ1, but they need 3 LIN module, F29 just has 2 LIN.

Can we use UART to simulate LIN? Any limitation if we use UART simulation? Any other methods to realize the LIN?

BRs

Shuqing

  • 0
    TI__Mastermind 26660 points

    Hi Shuqing,

    There is a possibility the customer may be able to emulate LIN via UART. Please allow me to spend some time this week looking into it if I can run some example showcasing.

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    TI__Expert 3215 points

    Hi Allison,

    Has some specific requirement from customer:

    1, Need to compliant with LIN2.2 or ISO17987

    2. Need to realize the standard data frame transmit

    BRs

    Shuqing

  • 0 in reply to Shuqing Zhou
    TI__Mastermind 26660 points

    Hi Shuqing,

    Thank you for the information. I am taking this into consideration as I evaluate the feasibility of this.

    Best Regards,

    Allison

  • 0 in reply to Shuqing Zhou
    TI__Mastermind 26660 points

    Hi Shuqing,

    Using the UART peripheral to communicate via LIN protocol is functionally achievable. However, please note that the customer would need to implement this in software layers. If the customer requires compliance to these LIN standards, there will be limitations to the extent of their compliance (and need creative workaround for some elements) since the UART hardware is fundamentally different from the LIN hardware.

    Do you know if the customer would require LIN commander mode or Lin responder mode specifically for their application? This information would help narrow the evaluation as well. I'm still working on developing an example to help showcase basic LIN communication using the UART module and will provide another update early next week on that progress.

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    TI__Expert 3215 points

    Hi Allison,

    Thanks for your hard work

    In this project customer needs LIN Slave node, you can evaluate this mode firstly

    BRs

    Shuqing

  • 0 in reply to Shuqing Zhou
    TI__Mastermind 26660 points

    Thank you, Shuqing. This is helpful information to narrow the focus- I will provide an update on the example in the next 1-2 days as soon as I can.

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    TI__Expert 3215 points

    Hi Allison,

    Could you give me the update today? What's can we update to customer? What's the conclusion for this?

    Can this method meet customer's requirement?? can or can't?

    BRs

    Shuqing

  • 0 in reply to Shuqing Zhou
    TI__Mastermind 26660 points

    Hi Shuqing,

    I wanted to highlight the below elements of the LIN standard 2.2/17987 that are not natively covered in UART- other elements can likely be supported by the UART hardware or in software workaround/other modules, but the below are of most concern.

    • No wakeup/sleep signal support
    • No physical bus-level error/collision detection
    • Partial support of break field detection (UART threshold is ~10 bits long; no 13-bit length minimum)
    • No autobaud adaptation (baud rate is fixed) (though may be able to workaround utilizing ECAP)
    • No hardware-enforced response timing (between PID and publisher response)
    Best Regards,
    Allison
  • 0 in reply to Allison Nguyen
    TI__Expert 3215 points

    Hi Allison,

    Customer needs this LIN feature, so it can't be realized by UART simulation right?

    BRs

    Shuqing

  • 0 in reply to Shuqing Zhou
    TI__Mastermind 26660 points

    Hi Shuqing,

    These are not 100% ruled out; however, the UART hardware/drivers do not natively support these. And I unfortunately cannot say with full confidence that we can robustly enable these since there is no precedent. This would take more time to evaluate as it would involve using other peripherals as creative workaround as well as precise software timing.

    Does the customer need 100% compliance to these standards? Are they open to software workarounds and other IP usage (e.g. ECAP, CLB, CPUTIMER come to mind)?

    Best Regards,

    Allison