PRU 200MHz clock outpout

[Le Costaouec Vincent]

Hello,

I'm using the PRU, and I have found out that the maximum frequency for a PRU clock is 66 Mhz (or 50Mhz if the duty cycle is at 50%).
In the PRU TRM, the data sheet told us that the clock of the PRU is at 200MHz.

So ma question is :
Is there a way to push out on a PIN a 200MHz ( or a clock frequency > 66 MHz) on the BeagleBone Black ?
If so have you an example on how to do so ?

In addition, I would like to known what is the maximum frequency that I can reach to read a PIN value (GPIO PIN and PRU dedicated PIN) ?
If eventually you know a good example who read data and load them into a register I will be pleased to hear about it ;-)


Thanks by advance
Regards

Vincent
"Enjoy life no matter what !"

[Dennis Lee Bieber]

On Wed, 4 May 2016 02:47:43 -0700 (PDT), Le Costaouec Vincent
<vincent.l...@gmail.com> declaimed the
following:

>Hello,
>
>I'm using the PRU, and I have found out that the maximum frequency for a
>PRU clock is 66 Mhz (or 50Mhz if the duty cycle is at 50%).
>In the PRU TRM, the data sheet told us that the clock of the PRU is at
>200MHz.
>

And how did you determine that 66MHz? By scoping a square-wave output
pin toggle? Off-hand you'd need three instruction cycles for that.

pin high 1
pin low 2
jump -2 3 (<G> or is that -3 if the PC has incremented already)

200MHz / 3cycles => 66.67MHz

50MHz would result from putting a NOP at "1.5" to get the 50% duty
cycle.

The instruction clock is running 200MHz, it isn't a promise of the
fastest software output clock you can write using the PRU.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Le Costaouec Vincent]

Hello,
Yes to determine the 66.6Mhz I have use the following code :

PRU_GPIO_TOGGLE:
    SET PIN            //pin high                                 1
    CLR PIN           // pin low                                  2
       
    QBA PRU_GPIO_TOGGLE // jump -2                3

For the 55Mhz I have use this one  :

PRU_GPIO_TOGGLE:
    SET PIN            //pin high                                          1
    XOR r0,r0,0       // like a nope doing nothing interesting 2
    CLR PIN           // pin low                                           3        
    QBA PRU_GPIO_TOGGLE // jump                             4

And then I just have to scope it.

Thanks for the information.

Just in case have you got some information about the maximum frequency that I can reach to read a PIN value (GPIO PIN and PRU dedicated PIN) ?

Regards
Vincent

[Dennis Lee Bieber]

On Wed, 4 May 2016 05:59:34 -0700 (PDT), Le Costaouec Vincent
<vincent.l...@gmail.com> declaimed the
following:

>Just in case have you got some information about the maximum frequency that
>I can reach to read a PIN value (GPIO PIN and PRU dedicated PIN) ?
>

I think the answer likely depends on what you are doing with the data
you read...

After all (take into account I don't know the PRU instruction set --
this is pseudo-code)

read pin, reg
jump -1

would be reading the pin at 100MHz, but does nothing with it...

read pin, reg
skip nz, reg #hypothetical skip if reg is non-zero
jump -2
... #do stuff

samples the pin at 66MHz so long as the pin is low, but once it reads high
it depends upon how many instructions follow.

If using the main processor and the default "file system" read
operation, expect very low sample rates. File system access is too slow to
read a DHT11 sensor (a stream of "0" bits are a low-high cycle with a total
length of 80uS, or about 13kHz, and you'd need to sample at about 26kHz to
catch just the high/low transition, and really need more samples to be able
to determine the length of the high (both 0 and 1 have ~50uS low, with a
28uS high for 0, and 80uS high for 1). Memory mapped to the pins will be
faster (supposedly it can be used to read the DHT11), but still unlikely to
approach PRU sample rates.

http://hackaday.com/2013/12/07/speeding-up-beaglebone-black-gpio-a-thousand-times/

Memory mapped, toggling a pin, only got up to less than 3MHz from the main
processor.

If you just need to react to a change in pin state -- it may be
possible to hook into an interrupt.