Lpc2000

Hi Robert,

> That raises a question, I haven't seen answered.  How does the pin toggling 
> speed compare between an LPC running at full speed (60 MHz, no slowdown on 
> the peripheral bus) and an SAM part at it's equivalent full speed?  The 
> only comparisons I've seen refer to pin toggling efficiency rather than 
> maximum rate.

I can answer that I think.
I recently was timing / finetuning an ISR, and for all purposes I was calling the handler
from a loop with a toggle on it like so :

for(;;)
    {
    event_irq_handler();
    PIOA_ODSR ^= 0x04;
    }

My timing was done at 55.296 MHz, Thumb code, and both in RAM and then from Flash
with 1 FWS -  GCC Level 2 Opt.
When first looping the XOR alone, I got a 162.77 nS period or 6.14 Mz.
Then, I also inserted a SODR just before despatching the function pointer from AIC_IVR,
and a CODR after return back into the IRQ handler. (* see below)
When marking some other points in the code with triggers through I/O, at one stage I got
patterns like this :

____---------_____-------______
    
      |   T1   | T2  |  T3  |

T1 = 100 nS
T2 = 50 nS
T3 = 60 nS

The 50 nS low time in the middle is PIOA0.3 switched low and then high.
It's not repetitive of course, but if it was that would equate to almost 20 MHz....
If it's in less looping code, I find the I/O will sustain 8-10 MHz TRUE throughput 
(The APB after all is only 2 cycles)...
Obviously the instruction sequence must have been such that stalls on the pipeline are much lower, and
I've seen several times that Thumb code from Flash executes significantly faster than ARM code.
(the prefetch I guess)

It doesn't beat the LPC2000 MAM of course, that's indisputable - Flash throughput truly seems to
approach 90-95% of RAM throughput.
But fact remains that I measure significantly higher I/O throughput, and without the excessive 
current hog of setting VPBDIV to 1 on LPC2000.

Hope this helps...

( * ) Note :
I only use IRQ vectoring through AIC_IVR, and with a func pointer.
Reason is that GCC :
1.    Still doesn't work properly with IRQ attributes for pro/epilogue.
2.    When using an ENTRY_ISR() and EXIT_ISR() macro, even pushing all R0-R12,
       and declaring function as "naked", it really goes to town :
       I had an IRQ where I used a local variable.
       In specific code setups, the compiler was writing to the local variable by using a 
       stray pointer on R12. (it failed to load R12 properly before indirection with it).

This really peaved me off, it took hours to find it. My RS232 TX ring buffer was 
occasionally being written with a weird character. (the low 8 bits of R12 from within the ISR)
Bugger it !!!
Now I only use IRQ by reading IVR and loading into func pointer...


Cheers,
Kris


[Non-text portions of this message have been removed]