Lpc2000

Sorry if this question has been addressed before.  I searched through
the messages and didnt see anything.  I have decided that I dislike
the yahoo group design.

I just started using the LPC2148 for its fast I/O.  And so far I have
not been disappointed.  But I have really only been outputting at high
speeds.  My design now, requires the ARM to react to an outside event
and I only have ~850ns from the time my indication goes high to when
it goes low.  All my work needs to get done in that tiny space.  

So I hooked my external indication to an input pin.  I set up my
FIOMASK so only that pin is visible and I hand assembled the tightest
loop possible.  The C equivalent is:
  while(1) {
      if(FIOPIN) {
          FIOSET = my signal pin
          FIOCLR = my signal pin
      }
  }

What I found using a logic analyzer, sampling at 500MHz, is that the
time between my external indication going high and the time my signal
pin goes high is about ~230ns.  I am running my ARM at 58.9MHz (I will
be changing to 60MHz when parts get in).  I realize that a couple
clock cycles get wasted raising my signal pin and a couple may get
lost if I am in the 'while' jump, but why is it taking so long to
register the external input?  Does using the mask register carry any
overhead, seems silly if it did?

What is the fastest number of clocks the ARM can recognize that there
is input?

Oh, one more thing, I was initially going use an external interrupt
FIQ before I learned of my ~850ns window.  So the initial design has
the external indication coming in on P0.15.  I havent tried using a
different input pin yet.  I only mention it because there may be some
type of overhead when using a pin that could also be set as an
external interrupt.

Thanks for any help,

Vern

Hi Vern,

> What I found using a logic analyzer, sampling at 500MHz, is that the
> time between my external indication going high and the time my signal
> pin goes high is about ~230ns.  I am running my ARM at 58.9MHz (I will
> be changing to 60MHz when parts get in).  I realize that a couple
> clock cycles get wasted raising my signal pin and a couple may get
> lost if I am in the 'while' jump, but why is it taking so long to
> register the external input?  Does using the mask register carry any
> overhead, seems silly if it did?

An interesting experiment might be to compare the response of using an
external interrupt pin set as a FIQ.  It seems it should be slower than
polling FIOPIN, but curious as to the results.

Joel

> An interesting experiment might be to compare the response of using an
> external interrupt pin set as a FIQ.  It seems it should be slower than
> polling FIOPIN, but curious as to the results.
>

I recall reading somewhere about the timing in this situation.  If I
remember correctly, it can potentially be a very broad range of clock
cycles (mostly depending on the instruction being executed at the
moment).  I didnt even try because I need very deterministic code.  I
cant have my response time in one situation, too much different than
another situation.

Even so, I will see if I cant get you some numbers for the jump to the
FIQ routine for you.  Besides polling the FIOPIN, I tried FIQs in a
little different way.  I set up the external interrupt triggered FIQ
but I didnt enable FIQs.  The VICFIQStatus register will still change,
so I polled that.  The only reason why I tried was for the built in
edge detection on external interrupts.  I cant remember the timing
values, I will see if I can rerun that test also.

Vern

Hello,

On Saturday 31 December 2005 17:31, deliconn wrote:
> Sorry if this question has been addressed before.  I searched through
> the messages and didnt see anything.  I have decided that I dislike
> the yahoo group design.
>
Yes.

> I just started using the LPC2148 for its fast I/O.  And so far I have
> not been disappointed.  But I have really only been outputting at high
> speeds.  My design now, requires the ARM to react to an outside event
> and I only have ~850ns from the time my indication goes high to when
> it goes low.  All my work needs to get done in that tiny space.
>
> So I hooked my external indication to an input pin.  I set up my
> FIOMASK so only that pin is visible and I hand assembled the tightest
> loop possible.  The C equivalent is:
>   while(1) {
>       if(FIOPIN) {
>           FIOSET = my signal pin
>           FIOCLR = my signal pin
>       }
>   }
>
> What I found using a logic analyzer, sampling at 500MHz, is that the
> time between my external indication going high and the time my signal
> pin goes high is about ~230ns.  I am running my ARM at 58.9MHz (I will
> be changing to 60MHz when parts get in).  I realize that a couple
> clock cycles get wasted raising my signal pin and a couple may get
> lost if I am in the 'while' jump, but why is it taking so long to
> register the external input?  Does using the mask register carry any
> overhead, seems silly if it did?
>
> What is the fastest number of clocks the ARM can recognize that there
> is input?
>
I don't think your 230ns are too bad. At 58.9 MHz you have 16.98ns per cycle.
The smallest loop I could come up with looks like this:

loop:
ldr r0, [FIOPIN] (reg holding address of IOPIN)
tst r0, MASK
strne OUTMASK, [FIOSET] (reg holding address of IOSET)
strne OUTMASK, [FIOCLR] (reg holding address of IOSET)
b loop

A load requires at least 3 cycles, the test 1 cycle and the store 2 cycles. 6 
cycles or ~102ns are the absolute minimum. If the store's condition isn't 
fulfilled, it takes 1 cycle, and the branch takes 3 cycles.
If the input isn't high in time for the ldr, up to 14 cycles or ~238ns are 
going to pass. These are optimum values, where no additional delay beyond 
that of the ARM7TDMI-S instruction cycle timing occurs. What does your 
assembly look like, and does the code run from single-cycle memory?

> Oh, one more thing, I was initially going use an external interrupt
> FIQ before I learned of my ~850ns window.  So the initial design has
> the external indication coming in on P0.15.  I havent tried using a
> different input pin yet.  I only mention it because there may be some
> type of overhead when using a pin that could also be set as an
> external interrupt.
>
> Thanks for any help,
>
> Vern

Kind regards,

Dominic

Hi Dominic,

Thanks for taking the time to reply.

> I don't think your 230ns are too bad. At 58.9 MHz
> you have 16.98ns per cycle.
> The smallest loop I could come up with looks like
> this:
> 
> loop:
> ldr r0, [FIOPIN] (reg holding address of IOPIN)
> tst r0, MASK
> strne OUTMASK, [FIOSET] (reg holding address of
> IOSET)
> strne OUTMASK, [FIOCLR] (reg holding address of
> IOSET)
> b loop
> 
> A load requires at least 3 cycles, the test 1 cycle
> and the store 2 cycles. 6 
> cycles or ~102ns are the absolute minimum. If the
> store's condition isn't 
> fulfilled, it takes 1 cycle, and the branch takes 3
> cycles.
> If the input isn't high in time for the ldr, up to
> 14 cycles or ~238ns are 
> going to pass. These are optimum values, where no
> additional delay beyond 
> that of the ARM7TDMI-S instruction cycle timing
> occurs. What does your 
> assembly look like, and does the code run from
> single-cycle memory?

I am running my code from the internal SRAM on the
LPC2148.  My assembly is the same as yours.  I have
preloaded registers with values and addresses before I
enter my loop, just like you have. 

I think that a redesign may be in order.  Anyone know
a good 250MHz ARM7 with local SRAM.  Just kidding.

Thanks again.

Vern



		
__________________________________________ 
Yahoo! DSL \ufffd Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com

> I am running my code from the internal SRAM on the
> LPC2148.  My assembly is the same as yours.  I have
> preloaded registers with values and addresses before I
> enter my loop, just like you have.
> 
> I think that a redesign may be in order.  Anyone know
> a good 250MHz ARM7 with local SRAM.  Just kidding.

Have you considered implementing your interface via PLD (CPLD/FPGA) based
state machine?

Joel

> Have you considered implementing your interface via
> PLD (CPLD/FPGA) based
> state machine?

I use a CPLD now, it generates the external interrupt
from an address range asserted by another processor. 
That frees my ARM up from making a bunch of
comparisons and memory fetches.  I am not able to move
all the processing to a CPLD because of the diverse
responses the project requires.  My ARM uses an 8K
jump table to react to its input.  I know, thats a
huge table and many of the locations wont be used, but
I need a deterministic response over all of them. 
Even though I only use a small percentage of the
location at any one time, I dynamically reconfigure
them during execution.  So it many be possible to have
all of them used at least once.

Cost is of the highest priority, so a powerful enough
FPGAs may be out of the question.  Beyond that, I dont
think I am capable of creating a useful core.

I am looking into a couple ARM9s.  Is there such a
thing as an ARM9 with local flash/SRAM?  I think I
read a press release from Philips a while back for
chip like this, something like an LPC3000 maybe.  I
havent been able to find anything concrete, so figure
it wont be available anytime soon anyway.

Thanks for the suggestion.

Vern



		
__________________________________________ 
Yahoo! DSL \ufffd Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com

> I use a CPLD now, it generates the external interrupt
> from an address range asserted by another processor.
> That frees my ARM up from making a bunch of
> comparisons and memory fetches.  I am not able to move
> all the processing to a CPLD because of the diverse
> responses the project requires.  My ARM uses an 8K
> jump table to react to its input.  I know, thats a
> huge table and many of the locations wont be used, but
> I need a deterministic response over all of them.
> Even though I only use a small percentage of the
> location at any one time, I dynamically reconfigure
> them during execution.  So it many be possible to have
> all of them used at least once.
> 
> Cost is of the highest priority, so a powerful enough
> FPGAs may be out of the question.  Beyond that, I dont
> think I am capable of creating a useful core.

The Altera MAX II CPLDs are essentially non-volatile FPGAs.  This might be
of interest, if anything to see the MAX II capabilities:
http://www.altera.com/literature/ds/ds_maxII_develop_board.pdf

Joel