If I have a port pin (i.e., P0.0) configured as output and tie it to another
port pin (i.e., P0.1) configured as input, and in the codes the first
instruction is to set P0.0, followed by next instruction to read P0.1. Will the
execution of these instructions be slowed down so that P0.1 will register the
correct state of P0.0?
GPIO write and read speed
Started by ●May 13, 2011
Reply by ●May 13, 20112011-05-13
--- In l..., hschew00@... wrote:
>
> If I have a port pin (i.e., P0.0) configured as output and tie it to another port pin (i.e., P0.1) configured as input, and in the codes the first instruction is to set P0.0, followed by next instruction to read P0.1. Will the execution of these instructions be slowed down so that P0.1 will register the correct state of P0.0?
>
No they won't be slowed down. Why would they be? Can you tell us what MCU you are using?
I was trying to do about the same thing on an LPC1769. The only difference is that I was writing to a GPIO register and immediately reading the register back. I did this intentionally to determine the propagation delay.
On an LPC1769 the propagation delay from writing to the GPIO port and the signal appearing on the output is >10ns and < ns @ 100-120 MHZ. I figured this out by adding inline NOPs to my code.
I had to add 2 inline assembly NOPs before reading the register back with correct results.
Larry
>
> If I have a port pin (i.e., P0.0) configured as output and tie it to another port pin (i.e., P0.1) configured as input, and in the codes the first instruction is to set P0.0, followed by next instruction to read P0.1. Will the execution of these instructions be slowed down so that P0.1 will register the correct state of P0.0?
>
No they won't be slowed down. Why would they be? Can you tell us what MCU you are using?
I was trying to do about the same thing on an LPC1769. The only difference is that I was writing to a GPIO register and immediately reading the register back. I did this intentionally to determine the propagation delay.
On an LPC1769 the propagation delay from writing to the GPIO port and the signal appearing on the output is >10ns and < ns @ 100-120 MHZ. I figured this out by adding inline NOPs to my code.
I had to add 2 inline assembly NOPs before reading the register back with correct results.
Larry
Reply by ●May 13, 20112011-05-13
--- In l..., "Larry Viesse" wrote:
> --- In l..., hschew00@ wrote:
> >
> > If I have a port pin (i.e., P0.0) configured as output and tie it to another port pin (i.e., P0.1) configured as input, and in the codes the first instruction is to set P0.0, followed by next instruction to read P0.1. Will the execution of these instructions be slowed down so that P0.1 will register the correct state of P0.0?
> > No they won't be slowed down. Why would they be? Can you tell us what MCU you are using?
>
> I was trying to do about the same thing on an LPC1769. The only difference is that I was writing to a GPIO register and immediately reading the register back. I did this intentionally to determine the propagation delay.
>
> On an LPC1769 the propagation delay from writing to the GPIO port and the signal appearing on the output is >10ns and < ns @ 100-120 MHZ. I figured this out by adding inline NOPs to my code.
>
> I had to add 2 inline assembly NOPs before reading the register back with correct results.
>
> Larry
>
I need to add that the peripheral clock is the system core clock / 4 in my previous post.
> --- In l..., hschew00@ wrote:
> >
> > If I have a port pin (i.e., P0.0) configured as output and tie it to another port pin (i.e., P0.1) configured as input, and in the codes the first instruction is to set P0.0, followed by next instruction to read P0.1. Will the execution of these instructions be slowed down so that P0.1 will register the correct state of P0.0?
> > No they won't be slowed down. Why would they be? Can you tell us what MCU you are using?
>
> I was trying to do about the same thing on an LPC1769. The only difference is that I was writing to a GPIO register and immediately reading the register back. I did this intentionally to determine the propagation delay.
>
> On an LPC1769 the propagation delay from writing to the GPIO port and the signal appearing on the output is >10ns and < ns @ 100-120 MHZ. I figured this out by adding inline NOPs to my code.
>
> I had to add 2 inline assembly NOPs before reading the register back with correct results.
>
> Larry
>
I need to add that the peripheral clock is the system core clock / 4 in my previous post.
Reply by ●May 13, 20112011-05-13
--- In l..., hschew00@... wrote:
>
> If I have a port pin (i.e., P0.0) configured as output and tie it to another port pin (i.e., P0.1) configured as input, and in the codes the first instruction is to set P0.0, followed by next instruction to read P0.1. Will the execution of these instructions be slowed down so that P0.1 will register the correct state of P0.0?
>
On the older devices like the LPC2106, the maximum toggle rate on pins was in the low hundreds of kHz. I have forgotten the right answer but it is nowhere near the instruction rate of the CPU.
Things improved a bit with Fast IO that comes with more modern chips. The LPC2148 has that feature. I haven't explored the maximum toggle rate.
Richard
>
> If I have a port pin (i.e., P0.0) configured as output and tie it to another port pin (i.e., P0.1) configured as input, and in the codes the first instruction is to set P0.0, followed by next instruction to read P0.1. Will the execution of these instructions be slowed down so that P0.1 will register the correct state of P0.0?
>
On the older devices like the LPC2106, the maximum toggle rate on pins was in the low hundreds of kHz. I have forgotten the right answer but it is nowhere near the instruction rate of the CPU.
Things improved a bit with Fast IO that comes with more modern chips. The LPC2148 has that feature. I haven't explored the maximum toggle rate.
Richard
Reply by ●May 14, 20112011-05-14
> --- In l..., hschew00@ wrote:
> >
> > If I have a port pin (i.e., P0.0) configured as output and tie it to another port pin (i.e., P0.1) configured as input, and in the codes the first instruction is to set P0.0, followed by next instruction to read P0.1. Will the execution of these instructions be slowed down so that P0.1 will register the correct state of P0.0?
> > No they won't be slowed down. Why would they be? Can you tell us what MCU you are using?
>
> I was trying to do about the same thing on an LPC1769. The only difference is that I was writing to a GPIO register and immediately reading the register back. I did this intentionally to determine the propagation delay.
>
> On an LPC1769 the propagation delay from writing to the GPIO port and the signal appearing on the output is >10ns and < ns @ 100-120 MHZ. I figured this out by adding inline NOPs to my code.
>
> I had to add 2 inline assembly NOPs before reading the register back with correct results.
>
> Larry
>
I use LPC2138 with /01 version. I am running at CCLK = 4 x 12.288MHz with PCLK = 12.288MHz with MAM disabled (I used to have a problem with I enable MAM. Not sure if the problem has been resolved by NXP. Will investigate this part on another post). With a slow GPIO, from the scope, I can see that the pin toggles with a duration of 1us in each state (500kHz). With a fast GPIO, the duration is about 550ns. The result is 450ns and 250ns respectively with MAM fully turn on with fetch cycle of 3. With the above example where P0.0 is an output and P0.1 as input, shouldn't that it will take P0.1 a 1us delay (slow GPIO case) to detect the P0.0 output status while the instructions being executed at CCLK speed (another question are the instructions actually executed at CCLK with MAM off?)? I haven't look at the assembly codes generated, but I have the following in C using Keil compiled as Thumb mode with optimization level 2:
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
Hian
> >
> > If I have a port pin (i.e., P0.0) configured as output and tie it to another port pin (i.e., P0.1) configured as input, and in the codes the first instruction is to set P0.0, followed by next instruction to read P0.1. Will the execution of these instructions be slowed down so that P0.1 will register the correct state of P0.0?
> > No they won't be slowed down. Why would they be? Can you tell us what MCU you are using?
>
> I was trying to do about the same thing on an LPC1769. The only difference is that I was writing to a GPIO register and immediately reading the register back. I did this intentionally to determine the propagation delay.
>
> On an LPC1769 the propagation delay from writing to the GPIO port and the signal appearing on the output is >10ns and < ns @ 100-120 MHZ. I figured this out by adding inline NOPs to my code.
>
> I had to add 2 inline assembly NOPs before reading the register back with correct results.
>
> Larry
>
I use LPC2138 with /01 version. I am running at CCLK = 4 x 12.288MHz with PCLK = 12.288MHz with MAM disabled (I used to have a problem with I enable MAM. Not sure if the problem has been resolved by NXP. Will investigate this part on another post). With a slow GPIO, from the scope, I can see that the pin toggles with a duration of 1us in each state (500kHz). With a fast GPIO, the duration is about 550ns. The result is 450ns and 250ns respectively with MAM fully turn on with fetch cycle of 3. With the above example where P0.0 is an output and P0.1 as input, shouldn't that it will take P0.1 a 1us delay (slow GPIO case) to detect the P0.0 output status while the instructions being executed at CCLK speed (another question are the instructions actually executed at CCLK with MAM off?)? I haven't look at the assembly codes generated, but I have the following in C using Keil compiled as Thumb mode with optimization level 2:
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
IOSET0 = 1;IOCLR0 = 0;
Hian
