• State
  • Replies 7 replies
  • Subscribers 33 subscribers
  • Views 191 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM2432: How to reduce the execution time of lwip_sendto()?

Weijian Tang
Prodigy 191 points

Part Number: AM2432

Hi experts,

1.Product Information: (1) The product supports dual network interfaces. The R5_0_0 core runs a 1ms CODESYS task, a 1ms EtherCAT Master task, and a 1ms EtherCAT Slave task, with priorities set at 26, 28, and 29 respectively. The simplified network topology is shown below. 

AM2432.png

(2) The 1ms CODESYS task transmits and receives data via UDP sockets, using a driver implemented based on the enet_cpsw_socket example.

2.Issue: When the EtherCAT Master successfully communicates with the slave, the lwip_sendto() function in the CODESYS task takes between 468us and 580us to complete one data transmission. However, when no successful communication occurs between the EtherCAT Master and the slave, lwip_sendto() requires only about 257us. Due to the relatively long execution time of lwip_sendto() within the socket, the 1ms CODESYS task experiences timing overrun issues.

3.Requirement: Is there any method to stabilize the lwip_sendto() execution time around 200us during normal master-slave communication? Or further reduce the execution time of lwip_sendto()? 

lwip_sendto.png


SDK Version: 08_06_00_45

Reference Examples: enet_cpsw_socket, enet_layer2_cpsw

Historical information:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1351767/am2432-sysconfig-conflicts-when-combining-lwip-and-layer2-example/5191476#5191476

 

  • 0
    TI__Expert 7040 points

    Hi Teja,

    can you help priority this thread?

    BR,

    Biao

  • 0
    TI__Genius 10690 points

    Hi,

    lwip_sendto() is a LwIP stack function which handles several usecases, and interfaces between the LwIP modules and Enet driver. Although the ENET driver logic can be improved, we would not see much delta in terms of reducing the peak latency. You can also look at our example which demonstrates the Enet driver packet transmission time, which is still within few micro seconds, and not in 100+ us range.

    From CPTS/IEP, you can time stamp the time when a send packet is called from application context (using lwip_sendto API), the ENET driver API to send the packets () and also when the packet is sent out from the PHY. If you can collect this data, we can have more data points to understand where we are spending the time, and where to focus on.

    Additionally, can you please tell us if the application uses TCP or UDP? TCP takes a relatively longer process load, but have consistent timing.UDP would have lower overhead, but the timing will be inconsistent inherently due to the protocol definition.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 191 points

    Hi Teja,

    Teja Rowthu said:
    Additionally, can you please tell us if the application uses TCP or UDP?

    (1) UDP used by the application.

    Teja Rowthu said:
    From CPTS/IEP, you can time stamp the time when a send packet is called from application context (using lwip_sendto API),

    (2) Where can I find information about the CPTS/IEP interface?

    (3) SDK Version: 08_06_00_45.

    Thanks,

    Weijian.

  • 0 in reply to Weijian Tang
    TI__Genius 10690 points

    Hi,

    Thank you for the details. 

    You can use "ENET_TIMESYNC_IOCTL_GET_CURRENT_TIMESTAMP" IOCTL to get the timestamp if you are in TSN environment, or even enable a GTC timer and get faster current time readouts there as well if you are not using TSN.

    The IOCTL will use the corresponding CPTS or IET module based on which ethernet IP you are using (CPSW or ICSSG respectively)

    Please let us know about your findings so that we can analyse further. Also, if you have any requirements other than the 1ms cycle time, please let us know so that we have better context of realistic targets, and identifying the better route forward.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 191 points

    Hi Teja,

    Sorry for the delayed reply . I was occupied with other tasks recently.

    TSN is not used in our application , so we use the GTC module for timestamp collection..

    Teja Rowthu said:
    even enable a GTC timer and get faster current time readouts there as well if you are not using TSN.

    As you suggested, we are collecting timestamps based on the GTC hardware timebase::

    1. T1: Timestamp when the application calls lwip_sendto() (software GTC sample in application context).

    2. T2: Timestamp when packet enters ENET driver send API boundary (Lwip2Enet_sendTxPackets).

    Unfortunately, I have not been able to accurately identify the exact moment when the packet is actually sent out from the physical layer.

    I collected 10 GTC samples and calculated actual execution time of lwip_sendto(), as shown in the figure below:

    In our application, the CODESYS RTOS task calls lwip_sendto() every 1 ms to send data to external devices. When the EtherCAT Master task is communicating normally, we observe that the CODESYS task frequently takes 1–2 ms to complete its execution.

    Thanks,

    Weijian.

  • 0 in reply to Weijian Tang
    TI__Genius 10690 points

    Hi Weijian,

    I will try to replicate this setup and will capture the results. I expected this time to be smaller. I will let you know my findings, and we can take this discussion from there. Please note that this might need a couple of days time as there are other on-going actions internally.

    Thanks and regards,
    Teja

  • 0 in reply to Teja Rowthu
    TI__Expert 7040 points

    Hi Teja,

    How about your findings? can you help priority this thread? 

    BR,

    Biao