AM2434: AM243x-LP

In addition, I wish to replace OSAL_SCHED_yield(); with a OSAL_SCHED_sleep().

Do you think if it is a problem in general? 


for (;;)
{
EC_API_SLV_mainLoopCyclic();
EC_API_SLV_getState(pApplicationInstance->ptEcSlvApi, &state, &alErrorCode);
if (EC_API_SLV_eESM_init < state)
{
OSAL_SCHED_yield();
}
else
{
/* for carve up give some air */
OSAL_SCHED_sleep(10);
}
}

Hello Jinlong Shen,

The API OSAL_SCHED_sleep() takes the argument in milliseconds and this API implementation is in OSAL library.

A call to API OSAL_SCHED_yield() will place the thread in the ready state and next high/same priority thread can run and a call to API OSAL_SCHED_sleep() will block the thread for the time specified.
If you replace the OSAL_SCHED_yield() with OSAL_SCHED_sleep() in the code part you mentioned, it affects the execution cycle time of the EC_API_SLV_mainLoopCyclic() and it has a big impact for cycle times below 1ms. 

Kind Regards,

I have replaced that line for 2 or 3 hours. I have not observed any bad effects. EtherCAT cycle is smaller than 1 millisecond. 

Measurement of cycle time seems to be totally fine (data not shared).

Could you please elaborate what EC_API_SLV_mainLoopCyclic() exactly does?

Updated: it seems like that mainLoopCyclic is calling MainLoop() of beckhoff ssc. Could you confirm?

Yes, Beckhoff is suggesting the same way of executing mainLoopCyclic() as seen on page 14 of this document chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/download.beckhoff.com/.../an_et9300_v1i8.pdf.


However, it is still possible to execute mainLoopCyclic() at a slower frequency such as 1 KHZ. Why? Since we are using dc sync, per documentation in Bechhoff code, MainLoop() does not take care of exchange between ESC and user application. Instead, PDI_Isr() is taking of it.  Since TI is also using Beckhoff code, PDI_Isr() will be the same. 

IS PDI_Isr() enabled in any of the EtherCAT demo projects?

Best,
Jinlong

Hello Jinlong Shen,

Yes, In the Free-Run mode, without any synchronization with the EtherCAT cycle, executing the mainLoopCyclic() at a lower rate would impact the process data and mailbox data exchange. But if you are using the synchronization such as DC synchronous mode then PDI_ISR() will handle the process data. 
Yes. PDI_ISR() is enabled in the EtherCAT demo projects.

Kind Regards,

Hi Harsha,
I wish to push a bit - can I see if PDI_Isr() is active anyhow in CCS or by any method?
Best regards,
Jinlong

Hello Jinlong Shen,

The user application API EC_SLV_app_SS_applicationRun() is synchronized with the DC SYNC0 event. You can add a GPIO toggle code in this application API and check the toggle period against the DC cycle time configured in TwinCAT (see DC ---> Advanced Settings... ----> Distributed Clock ----> SYNC 0 Cycle Time). This way you can confirm that PDI_Isr() is active.

A GPIO pin is toggled (change the pin state) when the application API EC_SLV_app_SS_applicationRun() called and measured the GPIO pin toggle period. Refer the screenshot below - DC cycle time is configured at 50us.

Kind Regards,

Please expect my reply tomorrow - I just found the pin that I can use for this purpose. 

Yes - I confirm that that run function is called at a frequency of ethercat cycle. 

How can I see snyc1 event and if it is possible to register another function that willl be called on every sync1 event?

Hello Jinlong Shen,

As of now, it is not possible to register a function that will be called on SYNC1 event.
The SYNC0 and SYNC1 signals are exposed on AM243x LP board. Probe the J7.3 pin on AM243x-LP for SYNC0 OUT and J7.5 pin on AM243x-LP for SYNC1 OUT.

Kind Regards,

Many thanks - I will update after some measurements.

To my supporise, sync0 shows the same pattern as measured by toggling one gpio pin, which is 1 ethercat cycle time.
However, sync1 on J7.5 shows a frequency of 2 times ethercat cycle (data not shown).
I think sync1 signal frequency is wrong. How do you think?

For your information: I see the following values with another tool in real-time. 
SM output parameter is 0x1C32:01 is 0x02 and 0x1C32:02 is 250000, and
SM Input parameter is 0x1C33:01 is 0x03, and 0x1C33:02 is 250000.