Are PRUs really deterministic, and well documented, ant not obsolete...

[daveyj...@gmail.com]

Hi, I have read this nice ad for PRUs http://www.staroceans.org/documents/TI-sdk/spry264.pdf which states how deterministic the PRUs are,

"each PRU has its own single-cycle I/O" etc. Then I wanted details...

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit "Content is no longer maintained and is being kept for reference only! "

http://processors.wiki.ti.com/index.php/PRU-ICSS "Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only."

http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "The PRU write instruction is a fire-and-forget command that executes in ~1 cycle"

that tilde...


"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.

-----------------------------------------------

I do not want to be pessimistic.... but neither I want to reverse-engineer these "deteministic" units, that do not really look that-deterministic. And that docs obsolete or missing??? What is it all about?

[Charles Steinkuehler]

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.

On 1/8/2019 6:48 AM, daveyj...@gmail.com wrote:
> Hi, I have read this nice ad for PRUs
> http://www.staroceans.org/documents/TI-sdk/spry264.pdf which states how
> deterministic the PRUs are,
>

> "*each PRU has its own single-cycle I/O*" etc. Then I wanted details...
>
> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit "Content
> is* no longer maintained and is being kept for reference only!* "

>
> http://processors.wiki.ti.com/index.php/PRU-ICSS "Please note as of

> Wednesday, August 15th, 2018 this wiki *has been set to read only*."

>
> http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "The PRU write

> instruction is a fire-and-forget command that executes in *~*1 cycle"
>
> *that tilde...*
>
>
> "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.*

>
> -----------------------------------------------
>
> I do not want to be pessimistic.... but neither I want to reverse-engineer
> these "deteministic" units, that do not really look that-deterministic. And
> that docs obsolete or missing??? What is it all about?
>
>
>
>

--
Charles Steinkuehler
cha...@steinkuehler.net

[Mark Lazarewicz]

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?

Sent from Yahoo Mail on Android

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/8976d66c-9bb4-40b9-aec9-b33874d42b99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[daveyj...@gmail.com]

Hi Charles and lazarman,

I do not do anything serious enough to require certificates stating that these docs are true, I just wanted to have the docs... Just "it will be one or two cycles if...." which, if true, is likely known by the designers of the chip. Which I eventually got from Charles' post.

Thanks lazarman for the insight concerning the industry.

[Charles Steinkuehler]

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.

On 1/9/2019 3:06 AM, ithinu wrote:
> So it means that I can do no-jitter bit banging if only one PRU accesses
> the GPIO, and if the unit does not use any shared resources? That would be
> great.
>
> On Tuesday, January 8, 2019 at 10:43:36 PM UTC+1, Charles Steinkuehler

> wrote:
>>
>> 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.
>>

>> cha...@steinkuehler.net <javascript:>
>>
>


--
Charles Steinkuehler
cha...@steinkuehler.net

[TJF]

There's a pretty easy method to test bit-bangig with direct GPIO. Just run the example

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruToggle

You can adapt the PRU firmware using PASM assembler and test whatever you need. Choose one of the C, Python or FreeBASIC firmware loaders.

Regards

[jmelson]

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.

Jon

[daveyj...@gmail.com]

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...