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...
--
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
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
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
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'
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
That looks like old sdk infoIMO 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 downwhich is what
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
