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.

Calling Notify_sendEvent from within a callback function.

Using a C6678 with IPC 3.30.2.13  

Normally Core 0 receives some data and then sends a notify event to Core 1 to start some processing.  Core 1 does it's thing, sends a notify back to Core 0 when done. Typically Core 0 waits for the next batch of data and the process repeats

If Core 1 takes an abnormally long time to process the data, occasionally Core 0 may have already collected new data for Core 1.  Is it possible to do the Notify_sendEvent from Core 0 back to Core 1 inside the callback function that got triggered when Core 1 said it was done?  Will this screw up the notify system?

Since it is rare and moderately hard to create the conditions for it, I'm not sure I could test it reliably.

Mike

  • Hi Mike,

    Mike says said:
     If Core 1 takes an abnormally long time to process the data, occasionally Core 0 may have already collected new data for Core 1.  Is it possible to do the Notify_sendEvent from Core 0 back to Core 1 inside the callback function that got triggered when Core 1 said it was done?

    If it takes long time to process the data, actually, in the Notify_sendEvent function, the fifth parameter,  "Bool  waitClear " is used whether to wait until the previuos event has been acknowledged or the pending event has been overwritten without waiting....

    Will that not help for your use case?

    More info on Notify_sendEvent(): -

    Send an event on an interrupt line.This function sends an event to a processor via an interrupt line identified by a processor id and line id. A payload may be optionally sent to the the remote processor if supported by the device.On the destination processor, the callback functions registered with Notify with the associated eventId and source processor id are called.For example, when using 'NotifyDriverShm', a waitClear value of 'TRUE' indicates that, if an event was previously sent to the same eventId, sendEvent should spin until the previous event has been acknowledged by the remote processor. If waitClear is FALSE, a pending event with the same eventId will be overwritten by the event currently being sent. When in doubt, a value of TRUE should be used because notifications may be potentially dropped when FALSE is used. When using NotifyDriverShm, a payload should never be sent with 'waitClear = FALSE.'

    On the other hand, other notify drivers that use a FIFO to transmit events will spin if waitClear is TRUE until the FIFO has enough room to accept the event being sent. If waitClear is FALSE, Notify_sendEvent() will return Notify_E_FAIL if the FIFO does not have room for the event.

    Refer to the documentation for the Notify drivers for more information about the effect of the waitClear flag in Notify_sendEvent().

    Notify_sendEvent can be called from a Hwi context unlike other Notify APIs.

    By any chance, you glanced this WIKI which has details on Notify_Module:

    Regards,

    Shankari

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

     

  • Hi Shankari,

    I guess I thought waitClear = TRUE related to sending 2 consecutive events to the same remote processor. My situation is that A sends and event to B causing the callback to run, and I want to send an event from B right back to A within the callback that is running in B.

    I had read the IPC user guide on notify, but wasn't quite sure what it meant when it said the sending processor "waits for an acknowledgement that the previous event was received".  Did that mean the callback function started, or that it completed? Base on the "More info on sendEvent" that you quote above, I'm figuring it means the callback is done.  In addition, it says sendEvent can be called from an Hwi context, and the user guide says "remote callback functions execute in an ISR context" so I think using waitClear = TRUE and I'll be ok.  Thanks for the additional info.

    Mike