• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 615 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.

PROCESSOR-SDK-AM64X: RPMessage-IPC-Callback-mechanism (MCU+SDK 07.03.02)

Felix Heil
Expert 1205 points
Part Number: PROCESSOR-SDK-AM64X

Hello, 

we had that topic handled by mail before with Arnon Friedmann and agreed to place them in e2e. The topic was:

As I read the documentation I can only get called by callback and MUST consume all messages or I need to actively poll or wait them. 

This means I am handling all my stuff inside the callback context or I need a separate receiver-task waiting or polling for new messages.

So in which context is this callback executed? Is it an HwI?

Is it also possible to just get informed via callback and then like sending an event to a task and if time is available handling the event and executing the receive-functionality to copy the data out of the buffer and handle it? After that operation we can signalize we finished and the buffer can be freed.

I can place a mailbox in between and copy the data into the mailbox when the callback is executed but in our architecture that means one extra copy-operation and this is not optimal.

Best regards

Felix

  • 0
    TI__Intellectual 2465 points

    Hi Felix, let me check, thx

  • +1
    TI__Genius 9101 points

    hi Felix,

    Right now the API supports a callback mode or blocking mode
    1. In callback mode, the callback is called in ISR context and expectation is message handling also happens in the callback itself. Callback is called in ISR context

    2. In the non-callback or blocking mode, in the ISR we just post a semaphore, so that a task waiting on RPMessage_recv, can be blocked while its waits for a message. Note, when using freertos, this will still allow other tasks to run

    Based on your requirement, what you need is basically, dont handle the message in ISR and simply call a user callback when a message is received. You will use this callback to notify a task or whatever to later call RPMessage_recv,.

    We can do this. Largely, this will mean invoking a user defined callback at the point shown below in RPMessage_recvHandler

    I will leave the current callback as is, this is to handle messages in the ISR itself and instead will a add new parameter to RPMessage_CreateParams called "recvNotifyCallback" with a "recvNotifyCallbackArgs" and this callback will simply be called in the "else" below after a message is added to the local queue (note this is not a copy), you could then post a semaphore or a global variable and then call  RPMessage_recv later. When you call RPMessage_recv later since you know that there will be atleast one message this API will effectively not block now. When RPMessage_recv is called, the message is copied form shared memory to your buffer and the shared memory buffer is released. Thus as user you just need to call RPMessage_recv  as before and all is taken care of.

                        else
                        {
                            /* recv messages handled in non-callback mode */
                            pMsg->remoteCoreId = remoteCoreId;
                            pMsg->vringBufId = vringBufId;
                            RPMessage_putEndPtMsg(obj, pMsg);
                            status = SystemP_SUCCESS;
    /* NEW CODE - user notification callback, read the message using RPMessage_recv as before */
    if(obj->recvNotifyCallback != NULL)
        obj->recvNotifyCallback((RPMessage_Object*)obj, obj->recvNotifyCallbackArgs);
                        }

    Let me know if this solves your problem

    regards
    Kedar

  • 0 in reply to Kedar Chitnis
    Expert 1205 points

    This would be a great benefit for our architecture! In the meanwhile I will just copy the message in a local buffer which shall hold enough messages before the task is ready again. 

    Thank you! What do you think in which update that will be implemented?

  • 0 in reply to Felix Heil
    TI__Genius 9101 points

    I will take this as a requirement. We will definitely have this in 8.0 release planned on 21-Jun. I need to check if this can be intercepted sooner.