Max. speed using GPIO via R30/R31 from PRU software

HI,

We will discuss across team experts and will get back to you as soon as we can.

Thanks & regards,
Sivaraj K

Hello Christopher,

What is the frequency you are running the PRU subsystem (PLL0_SYSCLK2) ?

At which point you are measuring the time between these two signals ?

You can calculate the instruction cycle time based on the PRU subsystem frequency. When you measure the time between two signals at the SOC pins, it includes the die to package pin propagation delay.

If you measure the signals at peripheral end, the measuring time is instruction cycle time + die to package pin propagation delay + physical trace propagation delay.

Regards,

Senthil

Hello Senthil,

we are running OMAPL-138 at 372MHz, therefore our PRU is running at 186MHz. We are measuring at the SOC package pins. We can see a proper rectangle form of the signals, no ramp up, how it would be caused by any capacties.

Regards
Christopher

Hi Christopher, 

Christopher Schulze said:

Our question is: Is this the maximum speed for switching GPIO pins via pru software or do we have to change our configuration?

I don't think we have any specific data on this. 

Based on some other experiments that were done by another customer , for something similar, I recall the time to be less than 100 ns. 

There is about 2-4 CPU cycles for internal delays/prop delay etc, rest of it should really be just PRU latency etc. 

Your code snippet looks good, so does your CPU/PRU speed. It seems like you don't have any issues on the GPIOs itself (looking at your response to Senthil's query)

Only other things to check would be,

1) Make sure that this is a stand alone test. If there are other masters/initiators in the system,t hat are competing with this PRU traffic , it could add to latency

2) Perhaps try another set of GPIO for input/output, to see if you see the same delay

3) Investigate where you are running your critical code for and there are no dependency on program execution for external vs internal memory etc. 

Regards

Mukul 

Hi Mukul,

Just talked to Christopher today.

in one additional test we even stopped the ARM core to avoid any delay caused by any case of interconnection but still measure 233ns. It's customer HW and the while loop seems to be Ok.

the only thing we need to clarify is the timing behaviour of these two PINs used by my customer.

I already forwarded our measurement of 50ns driving a PIN while reacting on external event.

I'll send you an email (offline with more data)

Thanks and best regards

Karim

 

Hi Mukul, 

I have similar application on OMAPL137 and I noticed that when I run PRU code which changes GPIO pin state (peripherial, not R30, R31 PRU regs) with frequency about 300khz, PRU activity kills Linux application. Our goal is to have 500khz but at the moment it seems impossible. I suppose that PRU activity on GPIO kills EMAC which is used to send ADC samples to HOST pc. 

I've modified MSTPRI0,1,2 register to change EMAC priority it helps a bit but still we are far from 500khz on GPIO line. 

What else can be done to fix this problem? 

Here is my clock configuration: 

C674X_0: GEL Output: 

C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: | Clock Information |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output:
C674X_0: GEL Output: PLLs configured to utilize crystal.
C674X_0: GEL Output: ASYNC3 = PLL0_SYSCLK2
C674X_0: GEL Output:
C674X_0: GEL Output: NOTE: All clock frequencies in following PLL sections are based
C674X_0: GEL Output: off OSCIN = 24 MHz. If that value does not match your hardware
C674X_0: GEL Output: you should change the #define in the top of the gel file, save it,
C674X_0: GEL Output: and then reload.
C674X_0: GEL Output:
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: | PLL0 Information |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output:
C674X_0: GEL Output: PLL0_SYSCLK1 = 456 MHz
C674X_0: GEL Output: PLL0_SYSCLK2 = 228 MHz
C674X_0: GEL Output: PLL0_SYSCLK3 = 91 MHz
C674X_0: GEL Output: PLL0_SYSCLK4 = 114 MHz
C674X_0: GEL Output: PLL0_SYSCLK5 = 114 MHz
C674X_0: GEL Output: PLL0_SYSCLK6 = 456 MHz
C674X_0: GEL Output: PLL0_SYSCLK7 = 50 MHz

Regards Grzegorz

Hi all, 

I have problem with GP2[4] line, when I run the following macro on PRU0 on omapl137 PRU0 activiti kills linux on ARM core. I tested with other GPIO e.g GP1[11] and same code works fine. I see that quare waveform is generated on GPIO2[4] same as GP1[11] but in case of GP2[4] it kills ARM. What can couse this problem ? Any ideas ? 

macro GPIO_TEST
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 SBBO cs2_bit, cs2_reg, 0, 1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 xor r1,r1,r1
 SBBO cs2_bit, cs2_reg, 4, 1
.endm

Hi Grzegorz
Can you clarify what you mean by "kills ARM" or "kills EMAC"?
from your first post it appeared that you may have a bandwidth/latency/contention type issue.
However from your second post it appears that it maybe more on the choice of pin/GPIO that is making a difference?

Quick cursory review i cannot think of why GP2[4] vs GP1[11] should make a difference.
Is this a custom hardware or a TI EVM - if custom hardware , anything else on these GPIOs?

The GP2[4] seems to be mux'd with pru ios - can you confirm that there is no issue using GPIOs mux'd with PRU IO vs GPIOs that are not mux'd with PRU IOs?

Regards
Mukul

Thanks for the update on this. Glad to hear that you were able to debug and resolve the issue.
I don't have any data points on GPIO frequency but curious if you are able to also get to your desired goal of 500 khz?

Regards
Mukul

Hi Mukul, 

Yes, I was able to achievie 500ksps with regular GPIO controlled by PRU. In our application we use TI ads8568 ADC at 500ksps and mentioned GP4.2 is used as a CS line. We use OMAPL137 and LIDD (LCDC) controller to read data from ADC. Using PRU allows us to control  data acquisition with user defined frequency up to 500ksps. 

Regards Grzegorz