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-AM62X: remoteproc alternative?

Part Number: PROCESSOR-SDK-AM62X

Tool/software:

Hi!

I've learned a bit more about what's going on with my enviroment - basically there's a mix of kernel/remoteproc & pru-icss versions that's unfavourable & making the use of remoteproc problematic.

Figured it was timely to ask this question now & forgive me for my bad memory, I thought I read somewhere that remoteproc can be less than ideal any way so what are the remoteproc alternatives? Is it based on a shared block of memory?

many thanks

  • Hello there,

    Apologies for the delayed response, I am back from vacation.

    Initializing & controlling PRU cores

    When you say "the use of remoteproc", I assume you mean using the Linux remoteproc driver to initialize the PRU cores. Is that correct?

    The Linux remoteproc driver is the TI supported way to load firmware into the PRU cores and initialize the PRU subsystem from Linux.

    Inter-processor communication

    If you are asking about inter-processor communication (IPC) between Linux and PRU cores, we provide an example of RPMsg communication here:
    https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am62x/PRU_RPMsg_Echo_Interrupt0

    The RPMsg communication protocol does have its limitations. It is just fine for many usecases, but there are also usecases where another IPC mechanism would be preferred.

    If you meant to ask about IPC, please tell me more about your usecase. How much data is getting sent, going in which direction? Are there any throughput requirements? What about latency requirements? If you have latency requirements, is that average latency, or worst-case latency?

    Regards,

    Nick