Tool/software:
Hi,
i am developing an EtherCAT slave application using the Full TI Stack on the Sitara AM2434.
I need to use DC-Clocks to synchronize the application with the master and other slaves for cycle times down to 250µs.
In every cycle I need to get the latest incoming packet, do some processing, and prepare the output packet.
In my understanding, i can put this logic into the ApplicationRun-Function, which will be called in every cycle when the Sync0 triggers.
This should be independent of the EtherCAT-Loop-Task, which in DC-Mode only handles the non-time critical acyclic communication (SDO-Access etc.)
Therefore I thought i can setup some other FreeRTOS Tasks for some other low-prio stuff like terminal etc.
However, i now stumbled over this thread:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/511290/configuring-ethercat-distributed-clocks-using-hwi-instead-of-tasks-on-am335x
Do i understand this correctly, in the TI Full Stack, there is some background task which busy-waits on the Sync0-Event? And another which waits on the PDI-Event?
I had expected that the Sync0-Event triggers an interrupt, which either directly handles the processing, or unblocks a task to do so.
Or has this changed since then / for the new AM243X?
If this is actually busy-wait in some background task, which will be swapped in and out regularly by the scheduler, then it is expected to show large non-deterministic jitter on the event reaction time.
I would appreciate some clarification on this topic!
Best Regards
Stefan Schlee
Hi Stefan,
Which SDK version and which EtherCAT example are you using for your development?
Regards,
Aaron
This should be independent of the EtherCAT-Loop-Task, which in DC-Mode only handles the non-time critical acyclic communication (SDO-Access etc.)
Yes, this is the case.
there is some background task which busy-waits on the Sync0-Event?
No, this is not correct. Background processing is only done for EtherCAT stack MainLoop.
the Sync0-Event triggers an interrupt, which either directly handles the processing
Yes, this is the case as in the case Beckhoff SSC stack as we are using this stack.
Thank you for the quick clarification!
I see this PRUSS wait-function uses internally the semphores of the DPL.
My problem was, that my additionally created tasks were higher in priority as the sync0-task, which blocked the the sync0 task from executing deterministically.
Some documentation in the EtherCAT stack would be helpful to understand the scheduling behaviour more quickly.
Also it would be very good if the priorities would be configurable, as it seems there are some other tasks defined in the osal.h, which have higher priority than the sync0/PDI tasks.
To get a more deterministic reaction time in high performance applications.
I guess, for this the EtherCAT library must be rebuild, which may be not possible due the license of the stack sources.
Is it somehow possible to license the full EtherCAT stack sources?
Hi Stefan,
with version 2.00.02 we changed the function EC_API_SLV_prepareTasks() so that the tasks priorities of the PDI, LED, SYNC0 and SYNC1 can be adjusted without recompilation of the stack sources.
In the corresponding example you'll be able to see the call in EtherCAT_Slave_Simple.c in line 266:
EC_API_SLV_prepareTasks(KBECSLV_PRIO_PDI, KBECSLV_PRIO_LED, KBECSLV_PRIO_SYNC0, KBECSLV_PRIO_SYNC1, KBECSLV_STACKSIZE_PDI, KBECSLV_STACKSIZE_LED, KBECSLV_STACKSIZE_SYNC0, KBECSLV_STACKSIZE_SYNC1);
The definitions are in project.h and can be changed to your needs:
#define KBECSLV_PRIO_PDI OSAL_TASK_Prio_ECPDI #define KBECSLV_PRIO_SYNC0 OSAL_TASK_Prio_ECSync #define KBECSLV_PRIO_SYNC1 OSAL_TASK_Prio_ECSync #define KBECSLV_PRIO_LED OSAL_TASK_Prio_ECLED
Best regards
Andreas