question about SysLink API

MyFather said:

this means the function "fnNotifyCbck" will be called only for the "eventId", right?

Your callback function will be called for whichever eventIds it has been registered with.  If you register a callback for only one eventId then that callback will be called only for that eventId.

MyFather said:

could we use two different eventId for the same lineId? any side effct?

You can consider "lineId" as a distinct group of "eventId"s, and it is typical to register for multiple eventIds (either with the same lineId or different one).  I suppose your question really is "can I use the same callback function for different eventIds?", in which case the answer is "yes".  The callback will be passed the eventId to allow it to distinguish which event caused the callback to be invoked.

You can even register multiple callbacks with the same lineId/eventId combo, and each callback will be called when the event is posted.

MyFather said:

does two different lineId can use the same eventId? any side effect?

Yes, you can register, for example, a callback for lineId 0/eventId 1 and lineId 1/eventId 1, they are separate events.  Keep in mind that most systems support only one lineId, since lineId relates to a particular HW interrupt line.

I can't think of any bad side effects from using the same callback for multiple eventIds.

Regards,

- Rob

Dear Robert,
thanks for your reply.

I have more question

Before using Notify_registerEvent() many times, we need to use followings to enable callback function
and just one time. Right?

status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_LOADCALLBACK, NULL);
status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_STARTCALLBACK, NULL);

MyFather said:

Before using Notify_registerEvent() many times, we need to use followings to enable callback function
and just one time. Right?

status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_LOADCALLBACK, NULL);
status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_STARTCALLBACK, NULL);

That's correct, Ipc_control() functions must be called one and only one time (once for LOADCALLBACK and once for STARTCALLBACK).  None of the SysLink functionality will work until those functions have been called (and corresponding Ipc_start()/Ipc_attach() on the slave side).

Regards,

- Rob

Dear Robert,
thanks for your reply.

I have more question

Q1. According to your speaking, Ipc_start() should be called once and Ipc_attach() should be called once for each remote processor,
so that means the notify could be applied for the communication between Host-M3/DSP or M3-M3 or M3-DSP. Right?

Q2. I check the DVRRDK_03.50.00.05\ti_tools\syslink\syslink_2_20_02_20\examples\archive\TI816X_linux_elf\ex04_sharedregion\dsp\Main_dsp.c

    /* create main thread (interrupts not enabled in main on BIOS) */
    Task_Params_init(&taskParams);
    taskParams.instance->name = "smain";
    taskParams.stackSize = 0x1000;

    May I know how to decide the stackSize?   

MyFather said:

Q1. According to your speaking, Ipc_start() should be called once and Ipc_attach() should be called once for each remote processor,
so that means the notify could be applied for the communication between Host-M3/DSP or M3-M3 or M3-DSP. Right?

Correct, and that applies for processors running SYS/BIOS (not Linux).  Ipc_start() should be called once (well, more correctly stated, called from just one place, although called in a loop while Ipc_start() returns Ipc_E_NOTREADY), and Ipc_attach(procId) should be called once for each processor with which you want to do Ipc (again, only once but probably in a loop).  This is exemplified in the smain() function in main_dsp.c.

MyFather said:

Q2. I check the DVRRDK_03.50.00.05\ti_tools\syslink\syslink_2_20_02_20\examples\archive\TI816X_linux_elf\ex04_sharedregion\dsp\Main_dsp.c

    /* create main thread (interrupts not enabled in main on BIOS) */
    Task_Params_init(&taskParams);
    taskParams.instance->name = "smain";
    taskParams.stackSize = 0x1000;

    May I know how to decide the stackSize?  

Selecting a stack size is somewhat of an art.  The general rule is to make it bigger than you know it needs to be, then run your application and check the Task's stack usage in ROV (there should be a max used field or something like that) and adjust accordingly.  You would want to pad the size a little bit above the "max used" value, and make sure that when you run your app you do stuff that would cause Tasks to execute into all their possible function calling trees (to "stress" the Task into its deepest stack usage).

The Task stack is used for both local function usage and context saves during interrupts.

Regards,

- Rob

Dear Rob,
  Thanks for your reply.
By your speaking, I have more question

Q1. Selecting a stack size is somewhat of an art.  The general rule is ... (to "stress" the Task into its deepest stack usage).
- Could you llustrate the above case for an example?

Q2. Why we don't set a max value, then we don't need to consider too many things?

MyFather said:

Q1. Selecting a stack size is somewhat of an art.  The general rule is ... (to "stress" the Task into its deepest stack usage).
- Could you llustrate the above case for an example?

Every function uses some amount of stack, including the overlying Task entry point function.  Each function called by another function uses more stack.  If you have fxn1 calling fxn2 calling fxn3 then the deepest stack usage would be in fxn3:
    fxn1()
    {
        ...
        fxn2();
        ....
    }

    fxn2()
    {
        ...
        fxn3();
        ...
    }

    fxn3()
    {
        ...
    }

A function's stack usage depends mostly on the amount of local variables used in that function.

So, a Task entry point function is just like any function, and it might call functions which call functions which call functions, etc.  Each function will potentially have different code execute for different conditions or function parameters.  I was just suggesting that you make sure your application has excersized all the possible code sequences, after which you check the max stack usage in ROV.

MyFather said:

Q2. Why we don't set a max value, then we don't need to consider too many things?

Hmmm, not sure I understand your question, but if you mean "make the stack really big" then you're right, it would simplify things, but many systems have minimal amounts of memory that must be carefully managed.

Regards,

- Rob

Robert Tivy said:

Before using Notify_registerEvent() many times, we need to use followings to enable callback function
and just one time. Right?

status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_LOADCALLBACK, NULL);
status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_STARTCALLBACK, NULL);