As others noticed you miscalculated the period but there are more errors in
your post.

1) miscalculated the period.

2) For 5MHz the period is 0.2us as you say but then you state that 'i
required interrupts on raising edges only. So interrupt may arrive at every
0.1us.' Two possible mistakes in this sentence. A wave period is indeed it's
full cycle as so you have one rising edge per period, as with any periodic
wave, at whatever point of the wave you're looking at now in one period time
you'll be at that same point. The other mistake is that you say 'rising
edges only' which makes me think that you thought there would less than one
rising edge per period maybe one rising edge every two 'periods' or so, but
after you divide time in half. When you divide time you multiply frequency.
If there were a rising edge every 0.1us you would effectively have two
rising edges per 'period (of 0.2us)', if you wanted one rising edge every
two 'periods (of 0.2us)' the time between rising edges would be 0.4us.

3) None of this math is needed to notice that 72MHz is only 72 times greater
than 1MHz as so it could never be a thousand times greater than 5MHz. When
you got your final result it should have ringed some bells.

Don't take me wrong... I'm not trying to make you fell bad or something...
I'm just trying to help and to make you notice that maybe you should have
put a little more thought on that.

Regards,
Bernardo Marques.

On Fri, Mar 25, 2011 at 5:17 PM, mohammed fazal wrote:

> Hello Bernardo,
>
> Your view of thinking is Okay? Please think the points below,
>
> 1) LPC2478 CPU running @ 72MHz, i.e 72000000 clock cycles per seconds. one
> clock cycle time period is 0.138 ns.
>
> 2) My external clock signal is 5Mhz, i.e 5000000 clocks per second. one
> clock cycle time period 0.2 us. And i required interrupts on raising edges
> only. So interrupt may arise at every 0.1us.
>
> 3) Per assembly instruction execution (for any C code) will take 0.138 ns
> or 3 x 0.138 ns or (pipeline, decode, or if any) time duration only as CPU
> running on 72MHz speed but it will not not 70MHz clocks ( by which u meant
> 14x 4 clocks duration for per assembly instruction).
>
> So CPU has 0.138ns/0.2us = 1449 instruction execution time for between 5MHz
> external clock input. hence why it wil not work for MHz signals?
>
> --- On *Thu, 24/3/11, Bernardo * wrote:
> From: Bernardo
> Subject: Re: [lpc2000] Re: Fast GPIO scaning speed of LPC2478
> To: l...
> Date: Thursday, 24 March, 2011, 9:27 PM
> Mohammed, I don't want to be rude but have you tried to think? Mike's
> answer to your question was quite good and should have cleared it out for
> you.
> You're facing the same problem because you're creating the same problem.
> 5MHz gives you 14 clocks (at 72MHz) to do the job. You cannot have an
> interrupt, reset the flag, do whatever you want to do and return in less
> than 14 clocks. One C instruction in your ISR will probably generate more
> than 14 instructions which in turn will take longer than 14 clocks to run.
> Reduce the signal you want to interrupt the uC to the kHz region and write
> your ISR efficient and fast. You'll never be able to do what you want to do
> (whatever may it be) with MHz signals.
>
> Regards,
> Bernardo Marques.
> On Thu, Mar 24, 2011 at 3:48 PM, mohammed
> > wrote:
>
> I have reduced my clock signal for 5MHz. Still i am facing same problem. I
> suspected that, Is LPC2478 CPU is running on 72MHz after PLL
> configuration!!!
>
> How can I check it out externally by scoping LPC24xx pins?
>
> --- In l...,
> "Michael Anton" wrote:
> >
> > You're kidding right? This would be 5 clocks at 70MHz between rising
> edges
> > at 14MHz. This is impossible to do in software. The time required to get
> > into the interrupt handler alone is longer than this.
> >
> > Slow down your external clock, and see if it works.
> >
> > Mike
> >
> > -----Original Message-----
> > From: l...[mailto:
> l... ]On
> Behalf
> > Of fazal.usicmku
> > Sent: Saturday, February 05, 2011 10:25 PM
> > To: l...
> > Subject: [lpc2000] Fast GPIO scaning speed of LPC2478
> >
> >
> > Hello,
> >
> > I want to scan an external clock line at the speed of 14MHz and required
> to
> > handle interrupt service at every external clock raising edge.
> >
> > LPC2478 running @ 70MHz. But I am not getting interrupt at all the
> raising
> > edge of the external clock!..
> >
> > can any one help me to solve this problem.
> >
> > Thanks
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> Start a New Thread

Hi all! I'm impressed by the amount of messages flowing about this issue.

Did any one suggest an FPGA as a solution for the task? Given the time
constraints, it would be much more relevant than a microcontroller...

Cheers
--
Olivier Gautherot
o...@gautherot.net
On Fri, Mar 25, 2011 at 12:29 PM, Bernardo wrote:

>
> As others noticed you miscalculated the period but there are more errors in
> your post.
>
> 1) miscalculated the period.
>
> 2) For 5MHz the period is 0.2us as you say but then you state that 'i
> required interrupts on raising edges only. So interrupt may arrive at every
> 0.1us.' Two possible mistakes in this sentence. A wave period is indeed it's
> full cycle as so you have one rising edge per period, as with any periodic
> wave, at whatever point of the wave you're looking at now in one period time
> you'll be at that same point. The other mistake is that you say 'rising
> edges only' which makes me think that you thought there would less than one
> rising edge per period maybe one rising edge every two 'periods' or so, but
> after you divide time in half. When you divide time you multiply frequency.
> If there were a rising edge every 0.1us you would effectively have two
> rising edges per 'period (of 0.2us)', if you wanted one rising edge every
> two 'periods (of 0.2us)' the time between rising edges would be 0.4us.
>
> 3) None of this math is needed to notice that 72MHz is only 72 times
> greater than 1MHz as so it could never be a thousand times greater than
> 5MHz. When you got your final result it should have ringed some bells.
>
> Don't take me wrong... I'm not trying to make you fell bad or something...
> I'm just trying to help and to make you notice that maybe you should have
> put a little more thought on that.
>
> Regards,
> Bernardo Marques.
>
> On Fri, Mar 25, 2011 at 5:17 PM, mohammed fazal wrote:
>
>> Hello Bernardo,
>>
>> Your view of thinking is Okay? Please think the points below,
>>
>> 1) LPC2478 CPU running @ 72MHz, i.e 72000000 clock cycles per seconds. one
>> clock cycle time period is 0.138 ns.
>>
>> 2) My external clock signal is 5Mhz, i.e 5000000 clocks per second. one
>> clock cycle time period 0.2 us. And i required interrupts on raising edges
>> only. So interrupt may arise at every 0.1us.
>>
>> 3) Per assembly instruction execution (for any C code) will take 0.138 ns
>> or 3 x 0.138 ns or (pipeline, decode, or if any) time duration only as CPU
>> running on 72MHz speed but it will not not 70MHz clocks ( by which u meant
>> 14x 4 clocks duration for per assembly instruction).
>>
>> So CPU has 0.138ns/0.2us = 1449 instruction execution time for between
>> 5MHz external clock input. hence why it wil not work for MHz signals?
>>
>> --- On *Thu, 24/3/11, Bernardo * wrote:
>> From: Bernardo
>> Subject: Re: [lpc2000] Re: Fast GPIO scaning speed of LPC2478
>> To: l...
>> Date: Thursday, 24 March, 2011, 9:27 PM
>> Mohammed, I don't want to be rude but have you tried to think? Mike's
>> answer to your question was quite good and should have cleared it out for
>> you.
>> You're facing the same problem because you're creating the same problem.
>> 5MHz gives you 14 clocks (at 72MHz) to do the job. You cannot have an
>> interrupt, reset the flag, do whatever you want to do and return in less
>> than 14 clocks. One C instruction in your ISR will probably generate more
>> than 14 instructions which in turn will take longer than 14 clocks to run.
>> Reduce the signal you want to interrupt the uC to the kHz region and write
>> your ISR efficient and fast. You'll never be able to do what you want to do
>> (whatever may it be) with MHz signals.
>>
>> Regards,
>> Bernardo Marques.
>> On Thu, Mar 24, 2011 at 3:48 PM, mohammed
>> > wrote:
>>
>> I have reduced my clock signal for 5MHz. Still i am facing same problem. I
>> suspected that, Is LPC2478 CPU is running on 72MHz after PLL
>> configuration!!!
>>
>> How can I check it out externally by scoping LPC24xx pins?
>>
>> --- In l...,
>> "Michael Anton" wrote:
>> >
>> > You're kidding right? This would be 5 clocks at 70MHz between rising
>> edges
>> > at 14MHz. This is impossible to do in software. The time required to get
>> > into the interrupt handler alone is longer than this.
>> >
>> > Slow down your external clock, and see if it works.
>> >
>> > Mike
>> >
>> > -----Original Message-----
>> > From: l...[mailto:
>> l... ]On
>> Behalf
>> > Of fazal.usicmku
>> > Sent: Saturday, February 05, 2011 10:25 PM
>> > To: l...
>> > Subject: [lpc2000] Fast GPIO scaning speed of LPC2478
>> >
>> >
>> > Hello,
>> >
>> > I want to scan an external clock line at the speed of 14MHz and required
>> to
>> > handle interrupt service at every external clock raising edge.
>> >
>> > LPC2478 running @ 70MHz. But I am not getting interrupt at all the
>> raising
>> > edge of the external clock!..
>> >
>> > can any one help me to solve this problem.
>> >
>> > Thanks
>> >
>> >
>> >
>> >
>> >
>> > Yahoo! Groups Links
>> >
>
> Start a New Thread

--- In l..., Olivier Gautherot wrote:
>
> Hi all! I'm impressed by the amount of messages flowing about this issue.
>
> Did any one suggest an FPGA as a solution for the task? Given the time
> constraints, it would be much more relevant than a microcontroller...

I do not think the actual problem was defined, just 5Mhz interrupts to do something, but what ??!!

The problem may be hidden in here somewhere, if the OP would like to explain a little more.......
don

Start a New Thread