AM620-Q1: ipc example without interrupt

Hi Owens, sorry for the delay reply, I have been out of office. Could you please clarify your request? what exactly is the modification required? Do you want to change ipc_notify from "interrupt" to "polling"?

thank you,

Paula

hi，Paula

     Yes. In this project, the processing response requirements for ipc are not high (ms level is allowed and polling processing can be carried out), but the interrupts used at the bottom layer of RPMSg need to be removed (to avoid the jitter impact of these interrupts on the IO timing).

linux runs on A53 and no rtos runs on M4F.

Regards,

Owens

Hi Owens, as you might know, the bottom layer of RP Message, in MCU+ RTOS cores, is IPC Notify. IPC Notify's underlying implementation uses HW mechanisms to interrupt and HW mailbox based HW FIFOs to transport the message and interrupt the receiving core. While Linux has a low-level mailbox driver that can be used by other higher-level Linux drivers (like RPMsg).

In both cases changing from interrupt to polling would be a re-work.

What is the current jitter you are observing? what is the maximum or expected jitter in your application? are you using RT Linux?

thank you,

Paula

Hello Owens,

How is RPMsg IPC being used?

Please also tell us how you are using IPC RPMsg. (what data is getting passed? How much data is getting passed? Are there latency needs or throughput needs?)

If you are not actually passing data back and forth between Linux and the M4F core, then you can simply remove the IPC RPMsg drivers from the M4F firmware.

Regards,

Nick

hi Paula & Nick

   We are using non-real-time linux

  We will transmit some short instructions and short logs of M4F to A53. The length of a single frame is less than 300 bytes. The real-time requirements for ipc data are not high and can reach 1ms to 2ms.

   A53 will need to send some instructions and configurations to M4F

   M4F needs to report some status and faults to A53

Owens, please allow us few days to discuss this and come back to you when Nick is back (early next week).

thank you,

Paula

Hi Owens, help me to confirm, the issue is that M4F gets interrupt too often (IPC Notify) and this is creating jitter in some IO tasks. If so, do you know how much jitter?

If only non-critical instructions/configurations are sent by A53 to M4F. Could those be moved to a shared memory?

thank you,

Paula

hi，Paula

1. We identified this issue during the project risk assessment stage at the beginning of the project. The specific jitter delay data cannot be obtained in the short term.

2. Both M4F and A53 have bidirectional data interaction

3. If shared memory is used, can the queue method of RPMsg also be adopted to solve the problem of read-write locks? What is the minimum interval allowed for reading and writing?

thank you,

Owens

Hello Owens,

Please tell us more about the waveforms and how you intend to generate them 

If the waveform can be generated by the PWM module, then nanosecond jitter requirements are fine.

However, your statement "IO of the M4F" makes it sound like you are also planning on having the M4F "bitbang" signals by directly driving GPIO signals high or low. Can you please comment more?

Please confirm the part number, and automotive grade or not

I do NOT suggest using the M4F to manually bitbang IO signals if you need nanosecond precision. The M4F was not designed for this usecase. However, the PRU core was designed to read and write input signals with nanosecond level latency, and nanosecond level precision.

For more details about how the PRU GPI / GPO signals are different from the M4F writing to a GPIO module, refer to
[FAQ] What is a PRU core? Why are PRU GPIO signals different from regular GPIOs? 

1) please confirm the exact part number you are using (are you actually using AM620-Q1, or are you using something else, like potentially AM623 or AM625?)

2) Are you looking for a processor that is specifically an automotive part? (a -Q1 part number?)

It does not look like we are planning to release an AM620-Q1 part with a PRU subsystem. However, if an automotive part is needed, we will release AM625-Q1 with a PRU subsystem in late October / November.

Regards,

Nick

hi，Nick

    Most of our waveforms are generated by the PWM controlled by M4F, but there are still a few pin waveforms that are generated by controlling the GPIO when the pwm is interrupted (pwm cnt == 0). The removal of ipc interrupts is to optimize the jitter of these signals。

   We are using the automotive-grade. 

   We initially used the AM6204-Q1. After the 625x was launched, we will switch to the AM6254-Q1

Regards,

Owens