Help needed understanding XScale GPIO performance (n00b alert)

Hi Guys, Looking for clues to enlighten my darkness, and pointers to the FM I should read...

I'm using a dev kit with a PXA270.The 'scope is connected to a random GPIO pin (90 as it happens), and I'm using a tiny prog (extract below) to toggle the pin. Given that the CPU is set up for, and reports itself as, working at core freq = 520MHz, I don't understand why the GPIO pin is toggling with a period of about 800ns. After all, the loop requires roughly a dozen machine cycles, so I was expecting the loop period to be an order of magnitude smaller. What have I misunderstood about the phrase, "Doh!" so far?

Here's the loop, disassembled in gdb:

while(1) { *pGPCR2 = nBIT90; // clear bit 90

0x00008820 : ldr r3, [r11, #-28] 0x00008824 : ldr r2, [r11, #-32] 0x00008828 : str r3, [r2] *pGPSR2 = nBIT90; // set bit 90 0x0000882c : ldr r2, [r11, #-28] 0x00008830 : ldr r1, [r11, #-36] 0x00008834 : str r2, [r1] } 0x00008838 : b 0x8820

Thanks, and sorry, etc...

--
jim
Reply to
jim
Loading thread data ...

Is this a standalone snippet or is it running inside an OS? Is the MMU enabled? Are you running out of 32-bit RAM, with cache enabled?

Reply to
larwe

ARMs often have very slow I/O, it depends which internal bus is used.

Leon

Reply to
Leon

I think the PX bus frequency enters into the equation here, more than the CPU clock frequency. I don't have PXA270 documentation handy but on PXA255, the PX bus will be somewhere between 50MHz and 133MHz, depending on core clocks configuration.

According to your figures, that sounds like it's not the end of the story though. Is the space pointed by pGPCR2 and pGPSR2 cached and/or buffered?

I read somewhere (but can't remember where) that GPIO i/o is very slow on PXA processors. Perhaps the pin state is not updated synchonously with the write to the GPIO controller? The maximum toggle rate would then be less than the fastest rate at which you can write to the GPIO controller.

You could modify your loop in a couple of ways to get a bit more information:

1) Reduce the I/O to just GPIO

asm("adr r0, =pGPCR2"); asm("adr r1, =pGPSR2"); asm("mov r3, #nBIT90"); loop: asm("str r3, [r0]"); asm("str r3, [r1]"); asm("b loop");

I can't vouch for the assembler as I can't test it right now but the point is to set things up first before looping so that the loop just toggles GPIO. The maximum GPIO output rate is then 2 * measured frequency. This might tell us something.

2) Read back the writes to the GPIO controller to force out writes (in case they're buffered)

unsigned int volatile read_back; while (1) { *pGPCR2 = nBIT90; read_back = *pGPCR2;

*pGPSR2 = nBIT90; read_back = *pGPSR2; }

Regards

Tim

Reply to
Tim Clacy

larwe schrieb:

[snip]

Hi Iarwe, It's a userland prog under a flavour of Linux (OSELAS), about which I still learning (fast!). I assume the MMU is enabled, and the prog is indeed in RAM. Don't know about the cache (yet). Thanks for the clues!

--
jim
Reply to
jim

Leon schrieb:

Hi Leon, Good clue, thanks much!

--
jim
Reply to
jim

Tim Clacy schrieb: [snip]

Rodger.

I don't know enough about the CPU/OS yet to say with certainty, but this is a good clue anyway.

Rodger.

Yup. I'll give it a try.

Tim, thanks very much indeed for taking the time and trouble to reply in such detail. I really appreciate it!

--
jim
Reply to
jim

Further to that, the Philips LPC21xx ARM chips are in fact slower than AVRs at toggling I/O pins, although they might be clocked at 60 MHz.

Leon

Reply to
Leon

The new models (e.g. lpc2101/2/3) have a different GPIO arrangement: rather than through the APB bus GPIO is attached directly to the ARM7 local bus, resulting in 3x speedup (they quote clock/4 toggling speed, e.g. 17.5 MHz on a 65MHz part).

Reply to
przemek klosowski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.