• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 90 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.

TIDM-1011: Tamagawa T-Format Solution Selection

Danilo A.
Mastermind 31550 points
Part Number: TIDM-1011


Hi Team,

Posting on behalf of our customer.

I am reading the Design Guide: TIDM-1011. The reference design employs SPI to parse Tamagawa T-Format communication data. However, I note that the T-Format frame structure adheres to a standard asynchronous serial format: featuring 1 start bit, 1 stop bit, and 8 data bits. Theoretically, any conventional serial peripheral should be fully capable of processing and accurately identifying this data stream without requiring consideration of transmission delays. Yet TI appears to favor using SPI for parsing this data, actively generating the clock using CLBs. To ensure clock-data synchronization, additional consideration must be given to data transmission delays. Is there an advantage to this approach that I'm overlooking? I believe serial peripheral features like oversampling and 3-out-of-2 voting could handle T-Format perfectly well (perhaps even better than SPI?).

Regards,

Danilo

  • 0
    TI__Guru* 93190 points

     If our UART (or SCI) peripherals had RS485 flow control, then UART could be used on its own. Since that feature is lacking, the CLB in charge of flow control and leverages the SPI. The clocking of the SPI by the CLB is aligned as needed based on the propagation delay.

  • 0 in reply to Lori Heustess
    TI__Mastermind 31550 points

    Hi Lori,

    Thank you for your response. Please see our customer's feedback below.

    What truly puzzles me is why SPI was chosen over SCI, since SCI also lacks flow control and the T-format data itself is perfectly suited for SCI. My initial thought was that this must be an application-layer protocol built on top of the SCI data format. If implementing flow control and efficient CRC functions is necessary, why TI not combine SCI with CLB? This approach would eliminate the need for clock signals, simplifying the design. I fail to see any drawbacks to such "simplification".

    By the way, while capturing data streams from encoders claiming T-format compliance, I noticed gaps between bytes during data responses. In such cases, using SPI for parsing introduces additional design considerations, whereas SCI adapts well. I'm still unsure whether these gaps stem from the encoder not strictly adhering to T-format or some other reason. I'd appreciate hearing your thoughts and suggestions :)

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Guru* 93190 points
    Danilo A. said:
    What truly puzzles me is why SPI was chosen over SCI, since SCI also lacks flow control and the T-format data itself is perfectly suited for SCI.

    For the physical layer, the data for both send (request to encoder) and received (response back from) from the encoder is on the same differential lines (D+/D-).  The RS458 transceiver for data must be switched between send and receive. The code could take an SCI TX complete interrupt to change the flow direction in code - however would not be deterministic for every system.  

    IF our SCI peripheral featured a signal to indicate "sending" vs "receiving" to the transceiver then this could be used to control the RS485 transceiver. Since we don't have that feature, the SPI with control from CLB was leveraged.  The CLB clocks the SPI to send the data, then switches the RS485 transceiver to receive. 

    Danilo A. said:
    By the way, while capturing data streams from encoders claiming T-format compliance, I noticed gaps between bytes during data responses.

    I guess you are referring to the ControlField? Yes, this is part of the protocol as shown in the design guide. The width of the SPI FIFO was selected so these fields were in the same location for each word and easily extracted by the software.