GPIO Speed

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dirtyBits on Sun Apr 24 07:26:17 MST 2011
I'm trying to figure out the maximum toggle speed supported by LPCXpresso LPC1343.

Here is my code;

#include "LPC13xx.h"
#include "gpio.h"
#include <cr_section_macros.h>
#include <NXP/crp.h>
__CRP const unsigned int CRP_WORD = CRP_NO_CRP ;

#define LED_PORT 0// Port for led
#define LED_BIT 7// Bit on port for led
#define LED_ON 1// Level to set port to turn on led
#define LED_OFF 0// Level to set port to turn off led

int main(void) {

 GPIOInit();
 GPIOSetDir( LED_PORT, LED_BIT, 1 );

 while(1)
 {
  GPIOSetValue( LED_PORT, LED_BIT, LED_ON );
  GPIOSetValue( LED_PORT, LED_BIT, LED_OFF );
 }
return 0 ;
}

and here is the output;

[IMG]http://i53.tinypic.com/33w5k5j.jpg[/IMG]

it's < [B]1 MHz[/B] :confused: [SIZE=2][FONT=Arial Black][B]How to speed this up??[/B][/FONT][/SIZE] :cool:

Regards

PS: It's my first program on LPCXpresso and just exploring it. So plz help me learn!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by elef on Fri Jan 06 04:02:34 MST 2012

Quote: ArneB
Yep, you are of course right, but it will speed up everything else (e.g. branching) and the remaining application. I have achieved a speedup of nearly 30% in my application for the time critical tasks just by programming the FLASHTIM register...

sorry i forgot to mention, but already tried that, i had it set to 0 (1 cycle)

For those that are interested, changing this from the default does speed up the application by about 10 to 20% from my tests (yours may be different depending what you are doing of course).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArneB on Fri Jan 06 03:08:03 MST 2012
Yep, you are of course right, but it will speed up everything else (e.g. branching) and the remaining application. I have achieved a speedup of nearly 30% in my application for the time critical tasks just by programming the FLASHTIM register...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Fri Jan 06 02:50:47 MST 2012

Quote:

there are two more things you can try to speed up your GPIO performance:

That is not going to change the fact that I/O access takes 2 cycles...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArneB on Fri Jan 06 02:47:52 MST 2012
Hi Elef,

there are two more things you can try to speed up your GPIO performance:

1) Program the FLASHTIM register to avoid wait cycles during flash accesses. In my application (running at 12 MHz on a LPC1114, too) it looks like this:

main.h

// Add missing LPC1114 register
typedef struct
{
    uint32_t flashtim;
} tflashtim;
#define LPC_FLASHTIM ((tflashtim *) 0x4003C010)

main.c

LPC_FLASHTIM->flashtim &= 0xFFFFFFFC;   // Set Flash memory access to <20 MHz (0 Wait states)

2) Try placing your procedure into RAM. This can be easily done with the cr_section_macros. It was already documented several times in the forum how to do it.

Good luck !

lpcware · ‎06-15-2016

Content originally posted in LPCWare by elef on Fri Jan 06 02:23:47 MST 2012

Quote: Zero
ARM?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0432c/CHDCICDF.html

thanks, str takes 2 cycles on M0

thanks guys!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Jan 06 02:18:13 MST 2012
ARM?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0432c/CHDCICDF.html

lpcware · ‎06-15-2016

Content originally posted in LPCWare by elef on Fri Jan 06 02:11:09 MST 2012
wow thanks for the quick response! that clears up a lot!
where did you read the GPIO on M0 taking 2 cycles? i'd love to read up on it.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Fri Jan 06 02:05:09 MST 2012
IIRC, access to GPIO on M0 takes 2 cycles. Most instructions are single cycle, but the I/O isn't...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by elef on Fri Jan 06 01:56:28 MST 2012
this thread has been a great read! so i decided to try it for myself.
They only difference is, i have a LPC1114 (M0 not M3) and unfortunately i can't reproduce the results.

On the M3, you were able to get 6Mhz output from a 12Mhz input clock.
I have set my clock to 12Mhz (verified this with clkout), and i can only get 3Mhz on the output.
Can someone point me in the right direction? Does the M0 use 2 clock cycles per instruction compared to the M3?

I have programmed a while(1) with optimisation -o2 and hundreds of these in there, so the branch delay at the end is negligible i assume?

        TURN_LED1_ON;
 320:    50d1          str    r1, [r2, r3]
        TURN_LED1_OFF;
 322:    50d0          str    r0, [r2, r3]
        TURN_LED1_ON;
 324:    50d1          str    r1, [r2, r3]
        TURN_LED1_OFF;
 326:    50d0          str    r0, [r2, r3]

So is the str command a 2 clock cycle command? I can step through it in the debugger and the PC counter increments by 2 each time, so how to tell if it uses 1 or 2 clock cycles?

EDIT: just to clarify, im trying to get from 3Mhz output, to 6Mhz output, while keeping the 12Mhz clock, IF it is possible?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dirtyBits on Sat Jul 09 00:28:27 MST 2011

Quote: Zero
I trust my Tektronix Scope and therefore I think your Logic-Toy is kidding you (or it's setup is wrong) :eek::eek:

You were right Zero,
I've changed [B]SYSAHBCLKDIV [/B]from 1 to [B]6[/B] (it divided the system clock by given number). Now I'm getting full 16 cycles with 6 MHz frequency and a branch delay!

Plz check the settings below;
[IMG]http://i52.tinypic.com/t52dd1.jpg[/IMG]

And the output that I'm getting;
[IMG]http://i56.tinypic.com/fohnp3.jpg[/IMG]

It is reasonable to assume that, with LPC1343 running at full 72MHz the toggle freqency of the code is higher than [B]20MHz[/B] which can not be measured by Saleae Logic (Toy )
@ Bobi

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dirtyBits on Fri Jul 08 22:40:11 MST 2011
Thank you Zero,
Really helpful!!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Jul 08 16:53:15 MST 2011

Quote: dirtyBits
Also, how do you find out any irregularity from Disassembly?

Just read it :eek:

Instructions are is explained in:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/index.html

Also referenced in:

http://support.code-red-tech.com/CodeRedWiki/ArmCpuInfo?action=show&redirect=CortexM3_InstructionSet

With a few years experience I know that an instruction like:

          LED_ON;
0x00000312 <main+18>: str   r1, [r3, #0]

is optimized and cycle counter in 'Core Registers' should show me how many cycles are needed.

As mentioned in this thread sometimes fetch and execute effects result in unexpected behaviour.
So the only way to check code is to use a scope and see if the code is working as expected.

I still don't know what you are trying to do, but your disassembly isn't surprising

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dirtyBits on Fri Jul 08 13:54:03 MST 2011

Quote: Zero
I trust my Tektronix Scope and therefore I think your Logic-Toy is kidding you (or it's setup is wrong) :eek::eek:

A silly question but Curious to know.

If you are running the same code as me, your Disassembly will be the same as mine, right?
Also, how do you find out any irregularity from Disassembly? One need to check for cycles with main function? i.e. main+2, main+4 etc?

LPC_GPIO0->DIR |= (1<<7);
0x00000300 <main>:    ldr   r2, [pc, #80]; (0x354 <main+84>)
0x00000302 <main+2>:  ldr   r3, [r2, #0]
0x00000304 <main+4>:  orr.w r3, r3, #128; 0x80
0x00000308 <main+8>:  str   r3, [r2, #0]

In other words, could you plz give an example of how to check irregularity for the above code?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Jul 08 13:43:06 MST 2011
I trust my Tektronix Scope and therefore I think your Logic-Toy is kidding you (or it's setup is wrong) :eek::eek:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dirtyBits on Fri Jul 08 13:33:51 MST 2011

Quote: Zero
Sorry, can't follow you. My scope shows nice 1 cycle ON / OFF signals (13ns) and after 16 packets a branch delay.

So I don't understand timing of your picture (is your 1343 running at 24MHz :confused:) and the problem :confused:

@ Zero
It is running at 72MHz, confirmed! So how come you are getting only 13nS :confused: while me 41.7nS ??

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dirtyBits on Fri Jul 08 13:23:55 MST 2011

Quote: Zero
Select SYSCTL in Peripherals View and read SYSPLLCTRL in Memory View :eek:

Found it...
MSEL is 5

[IMG]http://i52.tinypic.com/s2yvz8.jpg[/IMG]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Jul 08 13:18:05 MST 2011

Quote: dirtyBits
Ok [B]SYSPLLCTRL_Val[/B] in [B]system_LPC13xx.c[/B] is;
[B]#define SYSPLLCTRL_Val 0x00000025[/B]

But how to read SYSPLLCTRL_Val [B]with debugger?[/B] :o :o

Select SYSCTL in Peripherals View and read SYSPLLCTRL in Memory View :eek:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dirtyBits on Fri Jul 08 13:10:21 MST 2011

Quote: Zero
No Table 55, in Rev. 3 — 14 June 2011 it's Table 58. PLL configuration examples :eek:

:o :o :o

lpcware · ‎06-15-2016

Content originally posted in LPCWare by dirtyBits on Fri Jul 08 13:07:29 MST 2011

Quote: Zero
1. Use LPC_GPIO0->DIR[COLOR=Red] |[/COLOR]= (1<<7)

2. Use debugger to read SYSPLLCTRL_Val, should match with your setup in system_LPC13xx.c (if you use CMSIS). If MSEL=5 and M=MSEL+1 your board is running with 12MHz * M = 72MHz. See 'Table 55' of user manual :eek:

Ok [B]SYSPLLCTRL_Val[/B] in [B]system_LPC13xx.c[/B] is;
[B]#define SYSPLLCTRL_Val 0x00000025[/B]

But how to read SYSPLLCTRL_Val [B]with debugger?[/B] :o :o

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Jul 08 13:06:18 MST 2011
No Table 55, in Rev. 3 — 14 June 2011 it's Table 58. PLL configuration examples :eek: