Slew rate when toggling Enhanced GPIO pins in the PRU?

GoogleGroups
1

Hello All,

I’m trying to create a clock using the PRU, and I have it working to an extent, but I am noticing a discrepancy between what I read in the TRM and what I’m seeing. When I use a series of SET CLR SET CLR commands on a pin, they do not resolve completely before the next command. When I seperate each command by a delay, the rising edge of the clock takes ~90ns to go from 0V to 3.3V. I was under the impression that this operation would be performed at around ~5ns. I have attached the reading from my oscilloscope. My question is, is what I am seeing normal or am I doing something wrong?

Thank you.

2

When I seperate each command by a delay, the rising edge of the clock takes ~90ns to go from 0V to 3.3V. I was under the impression that this operation would be performed at around ~5ns. I have attached the reading from my oscilloscope. My question is, is what I am seeing normal or am I doing something wrong?

What kind of a delay are you using ? But if this delay has to interact with an on chip timer of the L3 interconnect . . . it’s going to take a lot longer than ~5NS. Which is what I would think you’re finding out now, but I’m no expert . . .

3

John,

Just a random thought here . . . perhaps adding a NOP or two would be better than using a delay function. A Single NOP would / should be exactly 5ns . . .

4

Sorry . . I forgot to mention that I’ve read somewhere that the TI ASM compiler / language does not make use of the ARM NOP instruction. In this case though . . .

mov r0, r0

Would probably work as well. Here is some discussion on the subject. http://stackoverflow.com/questions/1875491/nop-for-iphone-binaries

5

I’ve used this code via pruss_remoteproc and I believe it toggles the PRU gpio every cycle when I removed the delay.

https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/119bd86dbe7bd76011b7b28fd04da2ddb03c8d1e/examples/PRU_gpioToggle/PRU_gpioToggle.c

BTW, you need to keep your scope probes short or you will see ringing because of the fast transition times.

Regards,
John

6

Straight out Set/Clear would theoretically run at 100MHz (two instructions
of 5ns each), but when you connect them to the chip I/O, there are effects
of interconnect between the PRU and the I/O resources, Charles Steinkuehler
wrote it up in
https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p

However, the rise time of the signal as seen by your oscilloscope is
totally unrelated to that: the signal on a pin should change within a IO
clock cycle and the skew you're seeing must be due to the RC(L) delays due
to factors such as the state of the pullup on the IO pin, capacitances and
inductances within the package, on your board and in your oscilloscope
probe and cable.