• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 32 subscribers
  • Views 254 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.

AM2631: IEEE 1722 AVTP SDK Support Roadmap

Luke
Expert 4415 points

Part Number: AM2631

Hi team,

I had asked a few months back regarding Ethernet IEEE 1722 support in the AM263x SDK and wanted to follow up. From what I’ve seen of the SDK, “evaluation” code is present, containing headers showing potential functions that would be available. Do you know if ACF traffic is supported yet? If not, is there an approximate future release that would include it, and would accessing it require some additional license or agreement to use?

Best,
Luke

  • 0
    TI__Expert 7035 points

    Hi Luke,

    ACF traffic support is available in the SDK. There is an example in AM263x SDK where ACF packet traffic is demonstrated. In this example, CAN packets are encapsulated as ACF packets.

    Please see the below SDK documentation regarding the example:

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/11_01_00_19/exports/docs/api_guide_am263x/EXAMPLES_ENET_CPSW_ETHERRING_CAN.html

    Thanks & Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    TI__Expert 4415 points

    Hi Aswin,

    I had seen this example before, however I noticed that the example implements the ACF packet encapsulation, not some functions within the SDK, then interfaces directly with the Ethernet LLD driver or EtherRing driver. Is there a plan to move this encapsulation to the SDK and add support for time-sensitive variants of the ACF packet protocol in the future?

    Best,

    Luke

  • 0 in reply to Luke
    TI__Expert 7035 points

    Hi Luke, 
    Let me check the Software team regarding this. So, basically the ask is regarding an SDK API that will do the ACF packet encapsulation instead of the application as demonstrated in the example, right?

    Thank & Regards,

    Aswin

  • 0 in reply to Luke
    TI__Expert 7035 points
    Luke said:
    time-sensitive variants of the ACF packet protocol in the future?

    Can you please elaborate of time sensitive variants for ACF packet protocol?

  • 0 in reply to Aswin Sankar
    TI__Expert 4415 points

    Hi Aswin,

    Yes, I would like to know if the ACF support will be rolled into the SDK itself, rather than need to be implemented in the application.

    The ACF protocol encompasses NTSCF (non-time-synchronous control) and TSCF (time-synchronous control) messages. The example seems to use the non-time-synchronous format (based on the frame header), which doesn’t require gPTP to run. Making these messages time-synchronous would require interfacing with the TSN modules that the SDK provides, so I am curious about whether this support would get rolled into the SDK for convenience.

    Best,
    Luke

  • 0 in reply to Luke
    TI__Expert 4415 points

    I investigated further and it seems that the TSN stack is being used by the example to send time-synchronous control messages. This is implemented by the example code, not the SDK.

    Best,
    Luke

  • 0 in reply to Luke
    TI__Expert 4415 points

    The one thing I’m still interested in knowing is if the ACF support is planned to be rolled into the SDK in the future.

    Best,
    Luke

  • 0 in reply to Luke
    TI__Expert 7035 points

    Hi Luke,

    I checked with the dev team. There is plan currently to include this encapsulation inside the SDK. May I know what is the driving factor behind this requirement? The encapsulation will vary depending on the kind of data we are trying to send.

    Thanks & Regards,

    Aswin

  • 0 in reply to Aswin Sankar
    TI__Expert 4415 points

    Hi Aswin,

    We would like to implement an AVTP stack for transporting CAN messages over Ethernet alongside an IP stack. We don’t have any requirements in place for time-sensitive messaging at the moment, however we want the flexibility to swap to that in the future.

    Given the SDK IP stack directly controls the low-level Ethernet driver, I want to roll the AVTP stack in so that our application doesn’t share control of the low-level Ethernet driver with the SDK.

    Best,
    Luke

  • +1 in reply to Luke
    TI__Expert 7035 points

    Hi Luke,

    Regarding encapsulation as I mentioned above, it is different from protocol to protocol. So, it would not be viable for the SDK to have the encapsulation for all these different protocols for ACF in the driver. A kind of middleware implementation would be required to handle this. So, it would be better handle it the way it is done in the example, outside the driver.

    Thank & Regards,

    Aswin