Home arrow Support arrow Forums

Luminary Micro Forums

orinem

Expert Boarder
Click here to see the profile of this user

2006/10/18 13:09

Another GPIO question

GPIO Timing...

If I were to loop back one pin of say PortA to another pin of PortA, one set as output, the other input, how long will it take between setting the output pin and being able to read back the change on the input pin?

Certainly, if that loopback is an external device with a propagation delay of 140 nS, running the CPU at 6MHz, I will not see the input pin change for several CPU clocks...

Orin.

login or register to reply

LMI Eric

Moderator
Click here to see the profile of this user

2006/10/18 13:35

Re:Another GPIO question

A write to the GPIO takes 2 system clocks before the data shows up on the output pin (1 cycle for the write, 1 cycle to go though the peripheral bridge). Reading back data takes twice as long (2 cycles for the read request to go through and 2 cycles for the data to come back).

Adding that up, your best case scenario would be 6 cycles between writing the pin and getting the data back (this assumes a STR instruction followed by a LDR). You will have to factor in propagation delays of course, but 6 cycles is the theoretical best case assuming no delay.

login or register to reply

orinem

Expert Boarder
Click here to see the profile of this user

2006/10/18 14:27

Re:Another GPIO question

LMI Eric wrote:
A write to the GPIO takes 2 system clocks before the data shows up on the output pin (1 cycle for the write, 1 cycle to go though the peripheral bridge). Reading back data takes twice as long (2 cycles for the read request to go through and 2 cycles for the data to come back).

Adding that up, your best case scenario would be 6 cycles between writing the pin and getting the data back (this assumes a STR instruction followed by a LDR). You will have to factor in propagation delays of course, but 6 cycles is the theoretical best case assuming no delay.


Thanks Eric.

I didn't find this in the datasheets. If it's there, could you point me to it.

How does the CPU pipelining affect this?

What it boils down to is this:

STR
Delay
LDR

Where Delay is X plus external propagation delay. What must X be to see a change on an input pin caused by the STR?

BTW, the forum times out logins too quickly to edit replies.

Orin.

login or register to reply

LMI Eric

Moderator
Click here to see the profile of this user

2006/10/18 15:41

Re:Another GPIO question

That information isn't published in the data sheet since the exact performance is heavily dependant on the instruction stream. The 6 cycles I mentioned applies to the case where you have a STR followed by a LDR.

The number of NOPs you need will depend on your propagation delay. You automatically get 2 system clocks (~334ns at 6MHz) to let the pin settle if you do a STR followed directly by a LDR since the read request has to go through the peripheral bridge. For your example of a 140ns propagation delay, you wouldn't need any NOPs. If you were running at 50MHz (20ns clock period), you would want 5 NOPs to account for the 140ns.

In this particular example the processor pipelining wouldn't really have an effect. Doing a STR followed by a LDR (say cycles 1 and 2 respectively), the LDR can't access the bus until cycle 3, and the GPIO input data won't be latched until the rising edge of cycle 5 (and available on the sytem bus at cycle 6). Again, you'd have 2 system clocks of delay between puting the data on the output pin (rising edge of cycle 3) and latching the input data (rising edge of cycle 5).

login or register to reply

orinem

Expert Boarder
Click here to see the profile of this user

2006/10/19 02:09

Re:Another GPIO question

LMI Eric wrote:

The number of NOPs you need will depend on your propagation delay. You automatically get 2 system clocks (~334ns at 6MHz) to let the pin settle if you do a STR followed directly by a LDR since the read request has to go through the peripheral bridge. For your example of a 140ns propagation delay, you wouldn't need any NOPs. If you were running at 50MHz (20ns clock period), you would want 5 NOPs to account for the 140ns.



Putting this one to rest...

The 'offending' code:

MOVS r0,#0x04
MOV r1,#0x40004000
STR r0,[r1,#0x10]
nop
nop
MOV r0,r1
LDR r0,[r0,#0x40]

This now works at 6MHz. It needs only one more nop at 20MHz.

I re-ordered my C code to do useful work rather than nops. It's fun trying to get a somewhat square clock bit-banging a not-quite-SSPI protocol with the CPU running at 6MHz. I got up to about 200 KHz.

Thanks again, Orin.

login or register to reply