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.

How does Notify_sendEvent know that a previous event has been acknowledged by the remote processor?

Hi Champs,

According to Notify_sendEvent() Detailed Description in IPC v1.25 doxygen, 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.

So, how does the Notify_sendEvent() know that  the previous event has been acknowledged by the remote processor?

Thanks in advance for your cooperation.

Best regards,
j-breeze

  • Hi,

    The Notify_sendEvent() function sends an event to the specified processor. You can dynamically register callback functions with the Notify module to handle such events.

    Once an event has been registered, a remote processor may "send" an event by calling Notify_sendEvent(). If the specified event and interrupt line are both enabled, all callback functions registered to the event will be called sequentially.

    Please see the IPC user guide to get more detailed information.

  • j-breeze,

    The notify shared memory driver (NotifyDriverShm) uses flags in shared memory to keep track of events. When the local processor sends an event, it sets a flag for that event (the event flag). When the remote processor receives the event, it clears the event flag.

    When using waitClear=TRUE in Notify_sendEvent(), the local processor will first make sure the event flag is cleared before sending the new event and setting the event flag again. If the event flag has not been cleared, the local processor will busy wait. The default is to busy wait forever, but you can control this with the Notify.sendEventPollCount configuration parameter.

    ti/sdo/ipc/Notify.xdc: sendEventPollCount

    ~Ramsey

  • Hi Ramsey,

    Thank you for your information, and let me ask you one more thing.

    How about NotifyDriverCirc?
    Dose the NotifyDriverCirc Driver use the same flags that NotifyDriverShm uses?

    Best regards,
    j-breeze

  • Hi Ramsey,

    I checked out the driver c codes below.

      o NotifyDriverShm C code
        (C:\ti\ipc_1_25_03_15\packages\ti\sdo\ipc\notifyDrivers\NotifyDriverShm.c)

        - Line 269

          SET_BIT(obj->selfProcCtrl->eventRegMask, eventId);

      o NotifyDriverCirc C code
        (C:\ti\ipc_1_25_03_15\packages\ti\sdo\ipc\notifyDrivers\NotifyDriverCirc.c)

        - Line 256

          SET_BIT(obj->evtRegMask, eventId);


    So, I think the both of drivers use the same way that uses flags in shared memory.  Is that right?

    Best regards,
    j-breeze

     

  • j-breeze,

    The NotifyDriverCirc is a bit different from NotifyDriverShm in this regard.

    Note: the code from your previous post relates to event registration.

    With NotifyDriverShm, each eventId has its own event flag. If you call Notify_sendEvent() back-to-back with the same eventId, and the previous event has not yet been processed, then waitClear=TRUE will cause the second invocation to busy wait. However, if you call Notify_sendEvent() with two different eventIds, and the first eventId has not yet been processes, the second call will not busy wait (assuming that it's event flag is clear). In other words, you will only busy wait if the current eventId you are sending has a previous outstanding event which has not yet been processed.

    You can see this in NotifyDriverShm.c: NotifyDriverShm_sendEvent(). Look for the following while statement:

    /* Wait for completion of previous event from other side. */
    while ((eventEntry->flag != NotifyDriverShm_DOWN)) {

    With NotifyDriverCirc, the implementation uses a queue object to transfer the eventId and payload from the local processor to the remote processor. There is no event flag at all. Each time you call Notify_sendEvent(), the eventId and payload are added to the queue. Some time later, the remote processor will remove the eventId and payload from the queue and process the event. This means that you could call Notify_sendEvent() back-to-back with the same eventId, and even if the first event is still in the queue (i.e. it has not yet been processed), the second call will not busy wait. It will simply add the second event to the queue. However, the outcome should be the same. The remote processor will process the first event before processing the second event.

    But, if you application is using waitClear as a means to synchronize, then it will be different. If you application expects to busy wait until the first event has been processed, then using NotifyDriverCirc will not be correct. Your application might think that after sending the second event, the previous event has already been processed, but this might not be the case.

    With NotifyDriverCirc, the waitClear flag is used to busy wait when the queue is full. But there is not way to identify which events are in the queue. We use one queue for all events. If we had used a separate queue for each event, then it would have been different.

    You can see this in NotifyDriverCirc.c: NotifyDriverCirc_sendEvent(). Look for the following if-statement:

    /* check to make sure code has looped */
    if (loop && !waitClear) {
        /* if no slot available and waitClear is 'FALSE' */
        return (Notify_E_FAIL);
    }

    The primary use for waitClear is not for synchronization, but to ensure that the payload is not lost.

    ~Ramsey

  • Hi Ramsey,

    Thank you for your courteous reply.

    Best regards,
    j-breeze