• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 152 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.

AM2434: EtherCAT slave API

Manuel Philippin
Intellectual 1305 points
Part Number: AM2434

Tool/software:

Hello stack team,

why aren’t the EC_API_SLV_registerPhy and EC_API_SLV_enableMdioManualMode functions declared as EC_API_SLV_stackRegisterPhy and EC_API_SLV_stackEnableMdioManualMode respectively?

The argument EC_API_SLV_SHandle_t *pHandle appears to have no effect. 
I tried calling it with a valid pointer handle and a NULL value and the function call succeeded in both cases.  This is confusing as it makes it seem like a valid slave object is required to configure the stack. 
When I did create the slave object first I would get an invalid sync manager configuration when trying to transition the device to PREOP. 
It appears as though there is an ordering dependency here, I could not find documentation outlining this dependency. 

Once I moved the call to EC_API_SLV_new after the call to EC_API_SLV_stackInit, things started working.

Best regards
Manuel

  • 0
    TI__Intellectual 2850 points

    Hi Manuel,

    I will look into this and provide the feedback.

    Kind Regards, 

  • +1 in reply to Harsha Begihally Shanmukhaswamy
    TI__Intellectual 2850 points

    Hi Manuel,

    Yes. You're right with your assumption that *pHandle is not used in both of these functions. These functions are using a private (PRU) handler internally. The parameter is there to have a similar feel to all API functions. Since the PRU is initialized in EC_API_SLV_load(), the PRU parameters should be taken care of before that, resulting in the behavior that you described. Nevertheless, both functions are still "stack independent" and therefore I see no need in renaming them, but I take the other points for future improvement:

    - Remove not used parameters from these functions or describe in the documentation that the parameter isn't used.
    - Describe the order of function calls in our documentation.

    Thanks for your feedback!

    Kind Regards,