I’m trying to clarify if some indeterminism is implicit in the following scenarios on the PRU side, it doesn’t seems documented. Please correct me if I’m wrong on some behavior.
Scenario A - Using UIO/prussdrv:
1- app mmaps PRU data SRAM
2- app signals PRU code by writing to PRU data SRAM byte 1
3- PRU polls and found byte 1 changed, then process the signal
4- PRU code writes byte 2 in his data SRAM to signal app
5- app reads byte 2
Will the PRU code run deterministically in this scenario? I think yes, because PRU is never touching the DDR3 RAM so there are not hidden variable delays. Please correct me if I’m wrong.
Scenario B - Using remoteproc:
1- app writes a message to /dev/rpmsg_pruXX
2- kernel signals PRU by writing a message in PRU SRAM
3- PRU polls and found there is a message, then process it
4- PRU signals app by sending a message using pru_rpmsg_send()
5- pru_rpmsg_send() writes the message on the vring located at DDR3 RAM
6- pru_rpmsg_send() kicks the host by triggering an interruption
I think point 5 will add indeterminism to the PRU code execution, because writing to
DDR3 RAM is subjected to variable latencies. I’m right? If yes, can you achieve deterministic execution using remoteproc in some other way?