“The read latency values at the following links are considered “best-case,” accounting for the 2 cycle instruction and interconnect introduced latency”.
best case…
Possibly, there is some doc which states min/max execution times? Deterministic or not? etc, etc. Not found. Just not found.
The PRUs are mostly deterministic when accessing resources within the
local PRU-ICSS block. The "mostly" comes from potential contentions
if you have both PRU cores accessing the same resource (eg: PRU0 and
PRU1 both trying to access the local UART) in which case one of the
PRU cores will stall briefly.
The PRUs are less deterministic when accessing resources outside the
PRI-ICSS block (eg: SDRAM or GPIO registers) where the transaction is
subject to synchronization delays, bus congestion on the L3/L4
interconnect, etc.
That looks like old sdk info
IMO these PRU were added because there is little free RTOS support(I don’t consider linux realtime) for this chip for the hobbyist hence you have these PRU(processors) that run bare bones programs loaded by the ARM and get something NOT bloated down
which is what most hard realtime controllers can provide if you run barebones(the easiest way to calculate determinism) or run RTOS with interrupts(worst case timing required). In Avionics and other verified/certified environs you need determinism. I can tell you having worked in that industry no one runs linux the FCC cost to certify it would bankrupt you. I did work at one company that ran Integrity on the ARM used the DSP and the PRU unfortunately this costs big $$ here on this chip your SW support is this group and if your app end use fits well with linux user model its great. I see the PRU as a TI marketing to sell hard realtime users what you could get buying a non muticore processor and running it barebones. If you need all the features linux provides and some real time feature the PRU allows it. I will say they seem to have improved programming language and maybe even have jtag support for PRU. Not sure about c source level debugging. The PRU used to be programmed mistly in assembler. You have the arm dump the program and twiggle gpios to debug.
Unless you have many years of experience calculating determinism is complex even on simple one chip solutions and the fact you ask a question like this after choosing a SoC and reading some old docs makes me realize typing this was a waste of time.
Is this your college assignment run something determinism on Linux?
You can only do no-jitter bit-banging if you use the PRU direct
outputs, and those are unique to each PRU core so there is no
possibility for contention between the PRU cores for access.
Any access to the standard GPIO registers will always have some
jitter, as the write transactions from the PRU have to cross the
on-chip interconnect fabric and transition to a separate clock domain.
That said, the jitter is typically very low (5-10 nS) and is unlikely
to be a significant problem. The very significant jitter seen when
accessing the GPIO registers with the ARM core is related more to task
scheduling and operating system effects than the low-level bus
transactions to the GIPO registers, and does not exist on the PRUs.
I have a project that uses a PRU to unpack run-length compressed data for a photoplotter. It has a loop that supplies the next pixel to the laser every 5 us! The PRU is not even breathing hard to do that. So, it watches for a low-to-high transition on a clock input and then counts out the pixels and decides if this run is used up and has to get the next run.
No problem at all. Now, this is not actually a case where a few ns of jitter would show up, I have not counted out the instruction cycles or anything. The photoplotter provides the pixel clock and the PRU just stays in sync with that.
What surprises me is that why, if the precision of PRUs is their selling point, the original docs do not say a lot about it: when the precision is there, when it is not. Thus, thank you for these clarifications! I was afraid about a rare, occasional jitter, but if it works well for you…
and if your app end use fits well with linux user model its great. I see the PRU as a TI marketing to sell hard realtime users what you could get buying a non muticore processor and running it barebones. If you need all the features linux provides and some real time feature the PRU allows it. I will say they seem to have improved programming language and maybe even have jtag support for PRU. Not sure about c source level debugging. The PRU used to be programmed mistly in assembler. You have the arm dump the program and twiggle gpios to debug.