Lpc2000

I'm trying to capture the width of a pulse using the capture
 timers on the LPC2106 and getting an accurate reading every
 time has proven difficult.  The pulses are 200 to 700
 microseconds long.  I thought that I could capture them in
 the following way:
 
 Algorithm 1:
   o set up capture timer channel 0 to interrupt on each edge
   o on interrupt check level to see if high to indicate a
     rising edge
   o if high, remember captured time and wait for falling edge
   o when falling edge occurs subtract rising edge time and
     queue up the length of the pulse
 
 I implemented this algorithm and my numbers vary quite a bit.
 If I scope the signals, they are clean so the variance is not
 due to noise and is due to interrupt collision or a misunderstanding
 of the timer capture.  The above algorithm will fail if another
 interrupt occurs preventing the captured count from being read
 before another edge transition occurs.  This is probably what is
 happening in my case.  So I've been thinking about how else to
 capture the two edges without software getting in the way.  The
 only way I can think of is to use two capture inputs and a match
 register.
 
 Algorthm 2:
   o the first capture input captures the time on the rising edge
   o the second capture input captures the time on the falling edge
   o the match register provides a timed interrupt in which at
      least two edges have been captured

 In my case I'd set it to be a millisecond since the pulse is
 periodic with about a millisecond period (I'm really measuring the
 duty cycle).  Then comparing the rising and falling edge capture
 times, I can deduce whether I've captured the low pulse (falling
 edge before rising edge) or the high pulse (rising edge before
 falling edge) and calculate the high pulse from the captured times.
 Also by taking a group of measurements, I should get some of
 the high pulse and some of the low pulse.  Using this info, I
 should be able to deduce the period as well instead of measuring
 that independantly.
 
 While this algorithm seems like it should work, it uses two inputs
 per pulse input.  If someone else has a better idea please toss
 it into the arena.
 
 Rob

At 11:05 PM 1/21/05 +0000, you wrote:
>  Algorithm 1:
>    o set up capture timer channel 0 to interrupt on each edge
>    o on interrupt check level to see if high to indicate a
>      rising edge

As I remember there was a discussion of this a while ago.  The upshot was 
it was impossible to read the actual level of a pin set up for input capture.

>  Algorthm 2:
>    o the first capture input captures the time on the rising edge
>    o the second capture input captures the time on the falling edge
>    o the match register provides a timed interrupt in which at
>       least two edges have been captured
>
>  In my case I'd set it to be a millisecond since the pulse is
>  periodic with about a millisecond period (I'm really measuring the
>  duty cycle).  Then comparing the rising and falling edge capture
>  times, I can deduce whether I've captured the low pulse (falling
>  edge before rising edge) or the high pulse (rising edge before
>  falling edge) and calculate the high pulse from the captured times.
>  Also by taking a group of measurements, I should get some of
>  the high pulse and some of the low pulse.  Using this info, I
>  should be able to deduce the period as well instead of measuring
>  that independantly.


Actually you shouldn't need a another timer to make this work.  As long as 
both capture channels run off the same timer then
         - on rising edge
                 - time from last rising edge gives you period
                 - time from last falling edge gives you low duty time
         - on falling edge
                 - time from last falling edge gives you period
                 - time from last rising edge gives you high duty time.

As a nice benefit you period and duty cycle can be updated four times for 
every period.  Filter to suit.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 11:33 PM 1/21/05 -0500, you wrote:
>As a nice benefit you period and duty cycle can be updated four times for
>every period.  Filter to suit.


I just recounted.  Silly me, it's twice for each period.  I was thinking 
two falling and two rising edges but that defines two overlapping periods 
not a single period.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Assuming you'd like to measure the duty cycle of the input signal applied 
one of the capture pins of T0, do the following:

1) setup input pin as capture input and rising edge sensitive
2) provide 4 unsigned int storage namely POSITIVE,NEGATIVE,NEGWIDTH,POSWIDTH

3) in the timer0 interrupt service function check if cap0.x event occured 
(this is your pin)
4) check T0CCR relevant bits if it is programmed for rising edge goto 5 else 
goto 9
5) store captured value in POSITIVE
6) calculate NEGWIDTH = POSITIVE - NEGATIVE
7) setup T0CCR as falling edge sensitive for the next event (negative edge 
will come soon)
8) exit function

9) store captured value in NEGATIVE
10) calculate POSWIDTH = NEGATIVE - POSITIVE
11) setup T0CCR as rising edge sensitive for the next event (positive edge 
will come soon)
12) exit function

The very first reading of the above will be spurious as the algorithm 
requires 3 edges (positive-negative-positive) to get stabilized. However 
this can be avoided with a boolean flag. This flag can be set in the second 
positive edge event and the main program can check this flag and ignore the 
difference values if it is not set yet.

Also make sure you only have one capture or match interrupt in the timer0 as 
some errata causing missed interrupts in the timers exists (at least it 
exists in LPC2214 - you may check yours). If such errata exists and you need 
multiple captures be handled by timer0, you may lookup the code I have 
downloaded last week to resolve the problem.

For the other interrupts causing incorret reading issue, there wont be in 
the above algorithm as far as interrupts dont get disabled more than the 
time between two edges. If you wish you may enable all the interrupts 
assuming you have the enter and exit code of the irq handler modified.

For the dedsired accuracy set you timer0 clock rate accordingly. If you need 
0.1% accurate readings timer0 should be set to count at least 1000 pulses 
between each event.

The above algorith works and gives very stable readings. You may test it 
with a frequency gerenerator output applied to your input pin.

Here is an example code assuming your input is CAP0.2
....
  if(T0IR&0x40) {                                          // check if 
CAP0.2 interrupt interrupt
    T0IR=0x40;                                                // clear 
interrupt flag
    if(T0CCR & 0x40) {                                     // rising edge 
occured
      ps.curr.pos_cap=T0CR2;                               // capture timer 
at this positive edge
      ps.curr.nw=ps.curr.pos_cap-ps.curr.neg_cap;          // calculate 
previous negative width
      __clrio(T0CCR,0x40);
      __setio(T0CCR,0x80);                                 // next int on 
negative edge
    }
    else {
      if(T0CCR&0x80) {                                     // rising edge
        ps.curr.neg_cap=T0CR2;                             // capture timer 
at this negative edge
        ps.curr.pw=ps.curr.neg_cap-ps.curr.pos_cap;        // calculate 
previous positive width
        __clrio(T0CCR,0x80);
        __setio(T0CCR,0x40);                               // next int on 
positive edge
      }
    }
  }
...

I hope you will be able to see your readings soon...

Kerem


----- Original Message ----- 

From: "chazeltopman" <rob@...>
To: <lpc2000@yahoogroups.com>
Sent: Saturday, January 22, 2005 1:05 AM
Subject: [lpc2000] accurate pulse measurements


>
>
> I'm trying to capture the width of a pulse using the capture
> timers on the LPC2106 and getting an accurate reading every
> time has proven difficult.  The pulses are 200 to 700
> microseconds long.  I thought that I could capture them in
> the following way:
>
> Algorithm 1:
>   o set up capture timer channel 0 to interrupt on each edge
>   o on interrupt check level to see if high to indicate a
>     rising edge
>   o if high, remember captured time and wait for falling edge
>   o when falling edge occurs subtract rising edge time and
>     queue up the length of the pulse
>
> I implemented this algorithm and my numbers vary quite a bit.
> If I scope the signals, they are clean so the variance is not
> due to noise and is due to interrupt collision or a misunderstanding
> of the timer capture.  The above algorithm will fail if another
> interrupt occurs preventing the captured count from being read
> before another edge transition occurs.  This is probably what is
> happening in my case.  So I've been thinking about how else to
> capture the two edges without software getting in the way.  The
> only way I can think of is to use two capture inputs and a match
> register.
>
> Algorthm 2:
>   o the first capture input captures the time on the rising edge
>   o the second capture input captures the time on the falling edge
>   o the match register provides a timed interrupt in which at
>      least two edges have been captured
>
> In my case I'd set it to be a millisecond since the pulse is
> periodic with about a millisecond period (I'm really measuring the
> duty cycle).  Then comparing the rising and falling edge capture
> times, I can deduce whether I've captured the low pulse (falling
> edge before rising edge) or the high pulse (rising edge before
> falling edge) and calculate the high pulse from the captured times.
> Also by taking a group of measurements, I should get some of
> the high pulse and some of the low pulse.  Using this info, I
> should be able to deduce the period as well instead of measuring
> that independantly.
>
> While this algorithm seems like it should work, it uses two inputs
> per pulse input.  If someone else has a better idea please toss
> it into the arena.
>
> Rob
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Assuming you'd like to measure the duty cycle of the input signal applied
one of the capture pins of T0, try the following:

1) setup input pin as capture input and rising edge sensitive
2) provide 4 unsigned int storage namely POSITIVE,NEGATIVE,NEGWIDTH,POSWIDTH

3) in the timer0 interrupt service function check if cap0.x event occured
(this is your pin)
4) check T0CCR relevant bits if it is programmed for rising edge goto 5 else
goto 9
5) store captured value in POSITIVE
6) calculate NEGWIDTH = POSITIVE - NEGATIVE
7) setup T0CCR as falling edge sensitive for the next event (negative edge
will come soon)
8) exit function

9) store captured value in NEGATIVE
10) calculate POSWIDTH = NEGATIVE - POSITIVE
11) setup T0CCR as rising edge sensitive for the next event (positive edge
will come soon)
12) exit function

The very first reading of the above will be spurious as the algorithm
requires 3 edges (positive-negative-positive) to get stabilized. However
this can be avoided with a boolean flag. This flag can be set in the second
positive edge event and the main program can check this flag and ignore the
difference values if it is not set yet.

Also make sure you only have one capture or match interrupt in the timer0 as
some errata causing missed interrupts in the timers exists (at least it
exists in LPC2214 - you may check yours). If such errata exists and you need
multiple captures be handled by timer0, you may lookup the code I have
downloaded last week to resolve the problem.

For the other interrupts causing incorret reading issue, there wont be in
the above algorithm as far as interrupts dont get disabled more than the
time between two edges. If you wish you may enable all the interrupts
assuming you have the enter and exit code of the irq handler modified.

For the dedsired accuracy set you timer0 clock rate accordingly. If you need
0.1% accurate readings timer0 should be set to count at least 1000 pulses
between each event.

The above algorith works and gives very stable readings. You may test it
with a frequency gerenerator output applied to your input pin.

Here is a sample code assuming your input is CAP0.2
....
  if(T0IR&0x40) {                                          // check if
CAP0.2 interrupt interrupt
    T0IR=0x40;                                                // clear
interrupt flag
    if(T0CCR & 0x40) {                                     // rising edge
occured
      ps.curr.pos_cap=T0CR2;                               // capture timer
at this positive edge
      ps.curr.nw=ps.curr.pos_cap-ps.curr.neg_cap;          // calculate
previous negative width
      __clrio(T0CCR,0x40);
      __setio(T0CCR,0x80);                                 // next int on
negative edge
    }
    else {
      if(T0CCR&0x80) {                                     // rising edge
        ps.curr.neg_cap=T0CR2;                             // capture timer
at this negative edge
        ps.curr.pw=ps.curr.neg_cap-ps.curr.pos_cap;        // calculate
previous positive width
        __clrio(T0CCR,0x80);
        __setio(T0CCR,0x40);                               // next int on
positive edge
      }
    }
  }
...

I hope you will be able to see your readings soon...

Kerem


----- Original Message ----- 

From: "chazeltopman" <rob@...>
To: <lpc2000@yahoogroups.com>
Sent: Saturday, January 22, 2005 1:05 AM
Subject: [lpc2000] accurate pulse measurements


>
>
> I'm trying to capture the width of a pulse using the capture
> timers on the LPC2106 and getting an accurate reading every
> time has proven difficult.  The pulses are 200 to 700
> microseconds long.  I thought that I could capture them in
> the following way:
>
> Algorithm 1:
>   o set up capture timer channel 0 to interrupt on each edge
>   o on interrupt check level to see if high to indicate a
>     rising edge
>   o if high, remember captured time and wait for falling edge
>   o when falling edge occurs subtract rising edge time and
>     queue up the length of the pulse
>
> I implemented this algorithm and my numbers vary quite a bit.
> If I scope the signals, they are clean so the variance is not
> due to noise and is due to interrupt collision or a misunderstanding
> of the timer capture.  The above algorithm will fail if another
> interrupt occurs preventing the captured count from being read
> before another edge transition occurs.  This is probably what is
> happening in my case.  So I've been thinking about how else to
> capture the two edges without software getting in the way.  The
> only way I can think of is to use two capture inputs and a match
> register.
>
> Algorthm 2:
>   o the first capture input captures the time on the rising edge
>   o the second capture input captures the time on the falling edge
>   o the match register provides a timed interrupt in which at
>      least two edges have been captured
>
> In my case I'd set it to be a millisecond since the pulse is
> periodic with about a millisecond period (I'm really measuring the
> duty cycle).  Then comparing the rising and falling edge capture
> times, I can deduce whether I've captured the low pulse (falling
> edge before rising edge) or the high pulse (rising edge before
> falling edge) and calculate the high pulse from the captured times.
> Also by taking a group of measurements, I should get some of
> the high pulse and some of the low pulse.  Using this info, I
> should be able to deduce the period as well instead of measuring
> that independantly.
>
> While this algorithm seems like it should work, it uses two inputs
> per pulse input.  If someone else has a better idea please toss
> it into the arena.
>
> Rob
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

We am doing something similar with two capture inputs to the
same timer.
 - setup 1st capture input to capture the time of the rising edge
 - setup 2nd capture input to capture the time of the falling edge
   and to cause an interrupt.
 - the interrupt routine saves the difference between the two as
   the pulse duration.
 - the interrupt routine could also save the raw values for period
   and duty cycle calculations (we don't need that so don't do it).

Regards
-Bill Knight
http://www.theARMPatch.com


On Fri, 21 Jan 2005 23:05:45 -0000, chazeltopman wrote:

 I'm trying to capture the width of a pulse using the capture
 timers on the LPC2106 and getting an accurate reading every
 time has proven difficult.  The pulses are 200 to 700
 microseconds long.  I thought that I could capture them in
 the following way:

 Algorithm 1:
   o set up capture timer channel 0 to interrupt on each edge
   o on interrupt check level to see if high to indicate a
     rising edge
   o if high, remember captured time and wait for falling edge
   o when falling edge occurs subtract rising edge time and
     queue up the length of the pulse

 I implemented this algorithm and my numbers vary quite a bit.
 If I scope the signals, they are clean so the variance is not
 due to noise and is due to interrupt collision or a misunderstanding
 of the timer capture.  The above algorithm will fail if another
 interrupt occurs preventing the captured count from being read
 before another edge transition occurs.  This is probably what is
 happening in my case.  So I've been thinking about how else to
 capture the two edges without software getting in the way.  The
 only way I can think of is to use two capture inputs and a match
 register.

 Algorthm 2:
   o the first capture input captures the time on the rising edge
   o the second capture input captures the time on the falling edge
   o the match register provides a timed interrupt in which at
      least two edges have been captured

 In my case I'd set it to be a millisecond since the pulse is
 periodic with about a millisecond period (I'm really measuring the
 duty cycle).  Then comparing the rising and falling edge capture
 times, I can deduce whether I've captured the low pulse (falling
 edge before rising edge) or the high pulse (rising edge before
 falling edge) and calculate the high pulse from the captured times.
 Also by taking a group of measurements, I should get some of
 the high pulse and some of the low pulse.  Using this info, I
 should be able to deduce the period as well instead of measuring
 that independantly.

 While this algorithm seems like it should work, it uses two inputs
 per pulse input.  If someone else has a better idea please toss
 it into the arena.

 Rob






Yahoo! Groups Links

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> At 11:05 PM 1/21/05 +0000, you wrote:
> >  Algorithm 1:
> >    o set up capture timer channel 0 to interrupt on each edge
> >    o on interrupt check level to see if high to indicate a
> >      rising edge
> 
> As I remember there was a discussion of this a while ago.  The upshot was 
> it was impossible to read the actual level of a pin set up for input capture.

   Not impossible, just convoluted:
     o Set PINSEL0 back to GPIO for that pin
     o read input value from IOPIN
     o change PINSEL0 back to timer capture

> Actually you shouldn't need a another timer to make this work.  As long as 
> both capture channels run off the same timer then
>          - on rising edge
>                  - time from last rising edge gives you period
>                  - time from last falling edge gives you low duty time
>          - on falling edge
>                  - time from last falling edge gives you period
>                  - time from last rising edge gives you high duty time.
> 
> As a nice benefit you period and duty cycle can be updated four times for 
> every period.  Filter to suit.

 You must service the interrupt before the capture is overwritten, otherwise
 the measurement will be made longer by that time.  I was looking for a way
 to depend on hardware only in case the software was taking too long with
 other interrupts.  With one channel it can't be done but with two channels
 (same timer) on two pins this can be captured in hardware and to prevent
 the captured times from being overwritten, the match register is set to
 stop the counter timer at a specified time and also generate the interrupt.

 Originally I was getting a lot of noise using one channel trying to capture
 both edges because I was doing this to two signals at the same time.  When
 I rearranged my state machine for that timer to time the two signals sequentially
 instead of parallel, most of the noise went away.  Now I only get an occasional
 time, out of parameter.  Also I'm not catching each edge since that would be
 too much data.  I'm only catching one pulse out of one hundred so I don't have
 the preceding edge times to calculate the period.  I figure I'll capture the
 period data initially and then use in subsequent calculations since the
 period is constant.

 The next step is to take this data and process it.  The data is coming from
 a tilt sensor and I want to be able to discern the following patterns in time:
  o angle of tilt (easy just read the average value)
  o a tap; (not sure how to do this yet)
  o a shake; (again not sure how to do this either)
 The duty cycle of the sensor is proportional to accelleration due to movement
 or gravity (ADXL202) and I'm taking a sample every 100 ms.  If anyone else has
 experience in classifiying inputs over time, I'd be interested in your stories.

 Rob

At 01:23 AM 1/23/05 +0000, you wrote:


>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> > At 11:05 PM 1/21/05 +0000, you wrote:
> > >  Algorithm 1:
> > >    o set up capture timer channel 0 to interrupt on each edge
> > >    o on interrupt check level to see if high to indicate a
> > >      rising edge
> >
> > As I remember there was a discussion of this a while ago.  The upshot was
> > it was impossible to read the actual level of a pin set up for input 
> capture.
>
>    Not impossible, just convoluted:
>      o Set PINSEL0 back to GPIO for that pin
>      o read input value from IOPIN
>      o change PINSEL0 back to timer capture


I stand corrected.  I had forgotten about that.


> > Actually you shouldn't need a another timer to make this work.  As long as
> > both capture channels run off the same timer then
> >          - on rising edge
> >                  - time from last rising edge gives you period
> >                  - time from last falling edge gives you low duty time
> >          - on falling edge
> >                  - time from last falling edge gives you period
> >                  - time from last rising edge gives you high duty time.
> >
> > As a nice benefit you period and duty cycle can be updated four times for
> > every period.  Filter to suit.
>
>  You must service the interrupt before the capture is overwritten, otherwise
>  the measurement will be made longer by that time.


True but with a 1 mS period you've got a long time between edges.  Unless 
you expect to change by the duty cycle between extremes in one period of 
course.

>I was looking for a way
>  to depend on hardware only in case the software was taking too long with
>  other interrupts.  With one channel it can't be done but with two channels
>  (same timer) on two pins this can be captured in hardware and to prevent
>  the captured times from being overwritten, the match register is set to
>  stop the counter timer at a specified time and also generate the interrupt.


Why not just interrupt on the edge captures?  I wouldn't expect it to take 
1% of your CPU even going a full bore, the calculations are just not very 
intensive.  Even interrupting only on rising or falling edges and 
calculating for both would work and you might avoid the race condition in 
the timer interrupt.


>  Originally I was getting a lot of noise using one channel trying to capture
>  both edges because I was doing this to two signals at the same time.  When
>  I rearranged my state machine for that timer to time the two signals 
> sequentially
>  instead of parallel, most of the noise went away.  Now I only get an 
> occasional
>  time, out of parameter.  Also I'm not catching each edge since that would be
>  too much data.  I'm only catching one pulse out of one hundred so I 
> don't have
>  the preceding edge times to calculate the period.  I figure I'll capture the
>  period data initially and then use in subsequent calculations since the
>  period is constant.
>
>  The next step is to take this data and process it.  The data is coming from
>  a tilt sensor and I want to be able to discern the following patterns in 
> time:
>   o angle of tilt (easy just read the average value)
>   o a tap; (not sure how to do this yet)
>   o a shake; (again not sure how to do this either)

Tap and shake sound like frequency domain measurements.  First you will 
need to know the spectrum I would think.  You may well need faster response 
than the 5Hz (remember good old Nyquist) you have with your current 
sampling.  It wouldn't surprise me if you needed quite a bit higher.  Do 
you have any data collected for those events (presumably from some sort of 
lab setup)?

>  The duty cycle of the sensor is proportional to accelleration due to 
> movement
>  or gravity (ADXL202) and I'm taking a sample every 100 ms.  If anyone 
> else has
>  experience in classifiying inputs over time, I'd be interested in your 
> stories.


Hmm, 100mS is pretty slow and would suggest you can capture each edge 
without a problem (ie you are not expecting the duty cycle to change 
frequently).  I would expect taps to exhibit high frequencies though.  How 
about a simple test?  Can you hear a tap?  If so that suggests frequencies 
well above 5Hz.  If the frequencies get into the few hundred Hz or above 
region then you will definitely need to revisit your method and might well 
need to revisit your sensor choice.  Another possible test, put the signal 
from the accelerometer on to a DSO or logic analyzer with a large storage 
depth and perform a tap and shake, that should give you a good idea of how 
quickly to signal is changing and some lower bounds to the frequency.

It's been a while since I looked at those sensors but as I remember the 
period drifted as a function of time and temperature.  I had several 
possible projects for them but they didn't pan out so I never actually used 
them.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Can't you just use a single timer and toggle the bits in the control 
register that set the trigger edge? I haven't studied LPC2000 in any 
great detail yet, but this is so basic every 4,8and 16 bitter I've 
worked with that had a capture channel could do this. Then just check 
the edge control bits to determine if you need a result.

Al

Bill Knight wrote:

> We am doing something similar with two capture inputs to the
> same timer.
> - setup 1st capture input to capture the time of the rising edge
> - setup 2nd capture input to capture the time of the falling edge
>    and to cause an interrupt.
> - the interrupt routine saves the difference between the two as
>    the pulse duration.
> - the interrupt routine could also save the raw values for period
>    and duty cycle calculations (we don't need that so don't do it).
> 
> Regards
> -Bill Knight
> http://www.theARMPatch.com
> 
> 
> On Fri, 21 Jan 2005 23:05:45 -0000, chazeltopman wrote:
> 
> I'm trying to capture the width of a pulse using the capture
> timers on the LPC2106 and getting an accurate reading every
> time has proven difficult.  The pulses are 200 to 700
> microseconds long.  I thought that I could capture them in
> the following way:
> 
> Algorithm 1:
>    o set up capture timer channel 0 to interrupt on each edge
>    o on interrupt check level to see if high to indicate a
>      rising edge
>    o if high, remember captured time and wait for falling edge
>    o when falling edge occurs subtract rising edge time and
>      queue up the length of the pulse
> 
> I implemented this algorithm and my numbers vary quite a bit.
> If I scope the signals, they are clean so the variance is not
> due to noise and is due to interrupt collision or a misunderstanding
> of the timer capture.  The above algorithm will fail if another
> interrupt occurs preventing the captured count from being read
> before another edge transition occurs.  This is probably what is
> happening in my case.  So I've been thinking about how else to
> capture the two edges without software getting in the way.  The
> only way I can think of is to use two capture inputs and a match
> register.
> 
> Algorthm 2:
>    o the first capture input captures the time on the rising edge
>    o the second capture input captures the time on the falling edge
>    o the match register provides a timed interrupt in which at
>       least two edges have been captured
> 
> In my case I'd set it to be a millisecond since the pulse is
> periodic with about a millisecond period (I'm really measuring the
> duty cycle).  Then comparing the rising and falling edge capture
> times, I can deduce whether I've captured the low pulse (falling
> edge before rising edge) or the high pulse (rising edge before
> falling edge) and calculate the high pulse from the captured times.
> Also by taking a group of measurements, I should get some of
> the high pulse and some of the low pulse.  Using this info, I
> should be able to deduce the period as well instead of measuring
> that independantly.
> 
> While this algorithm seems like it should work, it uses two inputs
> per pulse input.  If someone else has a better idea please toss
> it into the arena.
> 
> Rob
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> Yahoo! Groups Links
> 
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>. 
> 
>

chazeltopman wrote:

> 
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
>  > At 11:05 PM 1/21/05 +0000, you wrote:
>  > >  Algorithm 1:
>  > >    o set up capture timer channel 0 to interrupt on each edge
>  > >    o on interrupt check level to see if high to indicate a
>  > >      rising edge
>  >
>  > As I remember there was a discussion of this a while ago.  The upshot 
> was
>  > it was impossible to read the actual level of a pin set up for input 
> capture.
> 
>    Not impossible, just convoluted:
>      o Set PINSEL0 back to GPIO for that pin
>      o read input value from IOPIN
>      o change PINSEL0 back to timer capture
> 
>  > Actually you shouldn't need a another timer to make this work.  As 
> long as
>  > both capture channels run off the same timer then
>  >          - on rising edge
>  >                  - time from last rising edge gives you period
>  >                  - time from last falling edge gives you low duty time
>  >          - on falling edge
>  >                  - time from last falling edge gives you period
>  >                  - time from last rising edge gives you high duty time.
>  >
>  > As a nice benefit you period and duty cycle can be updated four times 
> for
>  > every period.  Filter to suit.
> 
> You must service the interrupt before the capture is overwritten, otherwise
> the measurement will be made longer by that time.  I was looking for a way
> to depend on hardware only in case the software was taking too long with
> other interrupts.  With one channel it can't be done but with two channels
> (same timer) on two pins this can be captured in hardware and to prevent
> the captured times from being overwritten, the match register is set to
> stop the counter timer at a specified time and also generate the interrupt.

Unless you have really poorly written software (like monstrous ISR's) it 
is highly unlikely that you w9ill miss any edge event when using an 
ADXL202. The devuice is simply too slow. I often run them at 1kHz sample 
rate or higher. An 8MHz MSP430 gives me 8000 clock cycles for the entire 
period. the actual measssurement range covers just the centre 50% of the 
duty cycle, so 50% = 0g, -25% = -2g 75% = +2g. Therefore the shortest 
time between edges will be at the -2g or +2g points, these are, 
nominally of course, 2000 clock cycles apart at 8MHz, at LPC2000 clock 
speeds this should be even easier. Certainly I would look very closely 
at any system that could not service interrupts that occurred at such 
large intervals.

> 
> Originally I was getting a lot of noise using one channel trying to capture
> both edges because I was doing this to two signals at the same time.  When
> I rearranged my state machine for that timer to time the two signals 
> sequentially
> instead of parallel, most of the noise went away.  Now I only get an 
> occasional
> time, out of parameter.  Also I'm not catching each edge since that would be
> too much data.  I'm only catching one pulse out of one hundred so I 
> don't have
> the preceding edge times to calculate the period.  I figure I'll capture the
> period data initially and then use in subsequent calculations since the
> period is constant.

Why waste your time with a wider bandwidth then? set the ADXL202 to 1Hz 
or whatever sample rate you actually need, this reduces noise as well.

> 
> The next step is to take this data and process it.  The data is coming from
> a tilt sensor and I want to be able to discern the following patterns in 
> time:
>   o angle of tilt (easy just read the average value)

You need to extract any possible motion from this. If you have no motion 
then low pass filtering or very slow sampling will give you tilt angle.

>   o a tap; (not sure how to do this yet)

Probably can't do this decently at such low sample rates. Either a 
sustained peak detector or a bandpass filter will get you this. Just 
look for the centre of a stretched peak if using an IIR filter, or 
moving average. Generally the peak acceleration is in one direction for 
a tap (although it could occur between the 2 sensing axes).

>   o a shake; (again not sure how to do this either)

Same as above, but look for oscillations not peaks. A shake will 
transition either side of 0g probably with similar sized peaks.

Al

> The duty cycle of the sensor is proportional to accelleration due to 
> movement
> or gravity (ADXL202) and I'm taking a sample every 100 ms.  If anyone 
> else has
> experience in classifiying inputs over time, I'd be interested in your 
> stories.
> 
> Rob
> 
> 
> 
> 
> ------------------------------------------------------------------------
> Yahoo! Groups Links
> 
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>. 
> 
>

Al
Yes you can, if you want to implement two interrupts per cycle.
The project this was for had a number of interrupts firing off
much of the time.  Because we had a conviemt capture pin, the
decision was made to use it instead.

-Bill

On Sun, 23 Jan 2005 23:23:10 +1030, onestone wrote:


Can't you just use a single timer and toggle the bits in the control 
register that set the trigger edge? I haven't studied LPC2000 in any 
great detail yet, but this is so basic every 4,8and 16 bitter I've 
worked with that had a capture channel could do this. Then just check 
the edge control bits to determine if you need a result.

Al

Bill Knight wrote:

> We am doing something similar with two capture inputs to the
> same timer.
> - setup 1st capture input to capture the time of the rising edge
> - setup 2nd capture input to capture the time of the falling edge
>    and to cause an interrupt.
> - the interrupt routine saves the difference between the two as
>    the pulse duration.
> - the interrupt routine could also save the raw values for period
>    and duty cycle calculations (we don't need that so don't do it).
> 
> Regards
> -Bill Knight
> http://www.theARMPatch.com
> 
> 
> On Fri, 21 Jan 2005 23:05:45 -0000, chazeltopman wrote:
> 
> I'm trying to capture the width of a pulse using the capture
> timers on the LPC2106 and getting an accurate reading every
> time has proven difficult.  The pulses are 200 to 700
> microseconds long.  I thought that I could capture them in
> the following way:
> 
> Algorithm 1:
>    o set up capture timer channel 0 to interrupt on each edge
>    o on interrupt check level to see if high to indicate a
>      rising edge
>    o if high, remember captured time and wait for falling edge
>    o when falling edge occurs subtract rising edge time and
>      queue up the length of the pulse
> 
> I implemented this algorithm and my numbers vary quite a bit.
> If I scope the signals, they are clean so the variance is not
> due to noise and is due to interrupt collision or a misunderstanding
> of the timer capture.  The above algorithm will fail if another
> interrupt occurs preventing the captured count from being read
> before another edge transition occurs.  This is probably what is
> happening in my case.  So I've been thinking about how else to
> capture the two edges without software getting in the way.  The
> only way I can think of is to use two capture inputs and a match
> register.
> 
> Algorthm 2:
>    o the first capture input captures the time on the rising edge
>    o the second capture input captures the time on the falling edge
>    o the match register provides a timed interrupt in which at
>       least two edges have been captured
> 
> In my case I'd set it to be a millisecond since the pulse is
> periodic with about a millisecond period (I'm really measuring the
> duty cycle).  Then comparing the rising and falling edge capture
> times, I can deduce whether I've captured the low pulse (falling
> edge before rising edge) or the high pulse (rising edge before
> falling edge) and calculate the high pulse from the captured times.
> Also by taking a group of measurements, I should get some of
> the high pulse and some of the low pulse.  Using this info, I
> should be able to deduce the period as well instead of measuring
> that independantly.
> 
> While this algorithm seems like it should work, it uses two inputs
> per pulse input.  If someone else has a better idea please toss
> it into the arena.
> 
> Rob
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> Yahoo! Groups Links
> 
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>. 
> 
> 




Yahoo! Groups Links

I'm using 3 capture channels (3 signals). I have linking each signal
to an capture pin and also linked to a generic input. The captures are
configured for rising edge and falling edge and I see which the state
in IOPIN. but i'm also with problems, read stupid values.

Someone can say that will be wrong.

Thanks
         Domingos

void captura(void){

   ISR_ENTRADA();
			
	if(T1IR & TIR_CR0I){		//interrupt in channel0 (eixo dos xx)
	   T1IR |= TIR_CR0I;
	    
	    acel_cap_eixo_x();

	}

	else if(T1IR & TIR_CR1I){		//interrupcao no canal1 (eixo dos yy)
	   T1IR |= TIR_CR1I;

	   //acel_cap_eixo_y();

	}

	else if(T1IR & TIR_CR2I){		//interrupcao no canal2 (eixo dos zz)
	   T1IR |= TIR_CR2I;			//apaga a flag de interrupcao

	  // acel_cap_eixo_z();

	}

	VICSoftIntClr = (1<<VIC_TIMER1);


	VICVectAddr = 0x00000000;             // clear this interrupt from
the VIC
	ISR_SAIDA();                           // recover registers and return
}




void acel_cap_eixo_x(void){
	u32 tpu; 
	
	if(IOPIN0 & ACEL_asc_x){		//verify if rising edge
		tpu=T1CR0;
		                                             
duty_x=(float)(ACEL_T2_x-ACEL_T1_x)/(float)(tpu-ACEL_T1_x));
		ACEL_T1_x=tpu;
		
	}else{			//falling edge
		ACEL_T2_x = T1CR0;
		 
	      	}
return;
}


..........(identical function for other axes)
























Citando onestone <onestone@...>:

> 
> Can't you just use a single timer and toggle the bits in the control 
> register that set the trigger edge? I haven't studied LPC2000 in any 
> great detail yet, but this is so basic every 4,8and 16 bitter I've 
> worked with that had a capture channel could do this. Then just check 
> the edge control bits to determine if you need a result.
> 
> Al
> 
> Bill Knight wrote:
> 
> > We am doing something similar with two capture inputs to the
> > same timer.
> > - setup 1st capture input to capture the time of the rising edge
> > - setup 2nd capture input to capture the time of the falling edge
> >    and to cause an interrupt.
> > - the interrupt routine saves the difference between the two as
> >    the pulse duration.
> > - the interrupt routine could also save the raw values for period
> >    and duty cycle calculations (we don't need that so don't do it).
> > 
> > Regards
> > -Bill Knight
> > http://www.theARMPatch.com
> > 
> > 
> > On Fri, 21 Jan 2005 23:05:45 -0000, chazeltopman wrote:
> > 
> > I'm trying to capture the width of a pulse using the capture
> > timers on the LPC2106 and getting an accurate reading every
> > time has proven difficult.  The pulses are 200 to 700
> > microseconds long.  I thought that I could capture them in
> > the following way:
> > 
> > Algorithm 1:
> >    o set up capture timer channel 0 to interrupt on each edge
> >    o on interrupt check level to see if high to indicate a
> >      rising edge
> >    o if high, remember captured time and wait for falling edge
> >    o when falling edge occurs subtract rising edge time and
> >      queue up the length of the pulse
> > 
> > I implemented this algorithm and my numbers vary quite a bit.
> > If I scope the signals, they are clean so the variance is not
> > due to noise and is due to interrupt collision or a misunderstanding
> > of the timer capture.  The above algorithm will fail if another
> > interrupt occurs preventing the captured count from being read
> > before another edge transition occurs.  This is probably what is
> > happening in my case.  So I've been thinking about how else to
> > capture the two edges without software getting in the way.  The
> > only way I can think of is to use two capture inputs and a match
> > register.
> > 
> > Algorthm 2:
> >    o the first capture input captures the time on the rising edge
> >    o the second capture input captures the time on the falling edge
> >    o the match register provides a timed interrupt in which at
> >       least two edges have been captured
> > 
> > In my case I'd set it to be a millisecond since the pulse is
> > periodic with about a millisecond period (I'm really measuring the
> > duty cycle).  Then comparing the rising and falling edge capture
> > times, I can deduce whether I've captured the low pulse (falling
> > edge before rising edge) or the high pulse (rising edge before
> > falling edge) and calculate the high pulse from the captured times.
> > Also by taking a group of measurements, I should get some of
> > the high pulse and some of the low pulse.  Using this info, I
> > should be able to deduce the period as well instead of measuring
> > that independantly.
> > 
> > While this algorithm seems like it should work, it uses two inputs
> > per pulse input.  If someone else has a better idea please toss
> > it into the arena.
> > 
> > Rob
> > 
> > 
> > 
> > 
> > 
> > 
> > Yahoo! Groups Links
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
------------------------------------------------------------------------
> > Yahoo! Groups Links
> > 
> >     * To visit your group on the web, go to:
> >       http://groups.yahoo.com/group/lpc2000/
> >        
> >     * To unsubscribe from this group, send an email to:
> >       lpc2000-unsubscribe@yahoogroups.com
> >       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >        
> >     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>. 
> > 
> > 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

_________________________________________________________
CEAC Cursos de forma\ufffd\ufffdo profissional - pe\ufffda informa\ufffd\ufffdes aqui.:
http://ceac.online.pt/

At 04:05 PM 1/23/05 +0000, you wrote:
>void acel_cap_eixo_x(void){
>         u32 tpu;
>
>         if(IOPIN0 & ACEL_asc_x){                //verify if rising edge
>                 tpu=T1CR0;
>
>duty_x=(float)(ACEL_T2_x-ACEL_T1_x)/(float)(tpu-ACEL_T1_x));


I haven't gone through this in any sort of detail, but doing floating point 
in an interrupt is at least questionable.  At the very least you need to 
check if your compiler supports it.  BTW despite the casts the above will 
be done in double precision.

Also, please trim those parts of the previous post you are not referring to.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Thanks Bill, I'm earwigging here for a while trying to pick up enough on 
the LPC2139 to seem as if I know what I'm doing. ;?}

Al

Bill Knight wrote:

> Al
> Yes you can, if you want to implement two interrupts per cycle.
> The project this was for had a number of interrupts firing off
> much of the time.  Because we had a conviemt capture pin, the
> decision was made to use it instead.
> 
> -Bill
> 
> On Sun, 23 Jan 2005 23:23:10 +1030, onestone wrote:
> 
> 
> Can't you just use a single timer and toggle the bits in the control
> register that set the trigger edge? I haven't studied LPC2000 in any
> great detail yet, but this is so basic every 4,8and 16 bitter I've
> worked with that had a capture channel could do this. Then just check
> the edge control bits to determine if you need a result.
> 
> Al
> 
> Bill Knight wrote:
> 
>  > We am doing something similar with two capture inputs to the
>  > same timer.
>  > - setup 1st capture input to capture the time of the rising edge
>  > - setup 2nd capture input to capture the time of the falling edge
>  >    and to cause an interrupt.
>  > - the interrupt routine saves the difference between the two as
>  >    the pulse duration.
>  > - the interrupt routine could also save the raw values for period
>  >    and duty cycle calculations (we don't need that so don't do it).
>  >
>  > Regards
>  > -Bill Knight
>  > http://www.theARMPatch.com
>  >
>  >
>  > On Fri, 21 Jan 2005 23:05:45 -0000, chazeltopman wrote:
>  >
>  > I'm trying to capture the width of a pulse using the capture
>  > timers on the LPC2106 and getting an accurate reading every
>  > time has proven difficult.  The pulses are 200 to 700
>  > microseconds long.  I thought that I could capture them in
>  > the following way:
>  >
>  > Algorithm 1:
>  >    o set up capture timer channel 0 to interrupt on each edge
>  >    o on interrupt check level to see if high to indicate a
>  >      rising edge
>  >    o if high, remember captured time and wait for falling edge
>  >    o when falling edge occurs subtract rising edge time and
>  >      queue up the length of the pulse
>  >
>  > I implemented this algorithm and my numbers vary quite a bit.
>  > If I scope the signals, they are clean so the variance is not
>  > due to noise and is due to interrupt collision or a misunderstanding
>  > of the timer capture.  The above algorithm will fail if another
>  > interrupt occurs preventing the captured count from being read
>  > before another edge transition occurs.  This is probably what is
>  > happening in my case.  So I've been thinking about how else to
>  > capture the two edges without software getting in the way.  The
>  > only way I can think of is to use two capture inputs and a match
>  > register.
>  >
>  > Algorthm 2:
>  >    o the first capture input captures the time on the rising edge
>  >    o the second capture input captures the time on the falling edge
>  >    o the match register provides a timed interrupt in which at
>  >       least two edges have been captured
>  >
>  > In my case I'd set it to be a millisecond since the pulse is
>  > periodic with about a millisecond period (I'm really measuring the
>  > duty cycle).  Then comparing the rising and falling edge capture
>  > times, I can deduce whether I've captured the low pulse (falling
>  > edge before rising edge) or the high pulse (rising edge before
>  > falling edge) and calculate the high pulse from the captured times.
>  > Also by taking a group of measurements, I should get some of
>  > the high pulse and some of the low pulse.  Using this info, I
>  > should be able to deduce the period as well instead of measuring
>  > that independantly.
>  >
>  > While this algorithm seems like it should work, it uses two inputs
>  > per pulse input.  If someone else has a better idea please toss
>  > it into the arena.
>  >
>  > Rob
>  >
>  >
>  >
>  >
>  >
>  >
>  > Yahoo! Groups Links
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > ------------------------------------------------------------------------
>  > Yahoo! Groups Links
>  >
>  >     * To visit your group on the web, go to:
>  >       http://groups.yahoo.com/group/lpc2000/
>  >       
>  >     * To unsubscribe from this group, send an email to:
>  >       lpc2000-unsubscribe@yahoogroups.com
>  >       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>  >       
>  >     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>  >       Service <http://docs.yahoo.com/info/terms/>.
>  >
>  >
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> Yahoo! Groups Links
> 
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>. 
> 
>

Hi,

someone can help me to notice because the following happens:

I have 3 PWM (of accelerometers ADXL202E)with periods of more or less
100Hz and I want to measure the duty cycle. If I only enable 2 of the
3 interruptions that pretend everything works well, but if I enables
the third interruption the results are not the expected (the duty
cycle have errors, for example I'm an duty cycle of 0.50 and once in a
while appear pick 1.5).

I'm using LPC2129 and the GCC 3.4.1 compiler for ARM.


T1CCR |= TCCR_CR0_I | TCCR_CR0_R | TCCR_CR0_F; // enable timer1
interrupt on rising edge of CR0 capture (eixo dos xx)

T1CCR |= TCCR_CR1_I | TCCR_CR1_R | TCCR_CR1_F;

T1CCR |= TCCR_CR2_I | TCCR_CR2_R | TCCR_CR2_F;



//interrupt function

void captura(void){
   ISR_ENTRADA();
			
		
	if(T1IR & TIR_CR0I){		
	   T1IR |= TIR_CR0I;
	    
	    acel_cap_eixo_x();

	}

	if(T1IR & TIR_CR1I){		
	   T1IR |= TIR_CR1I;

	   acel_cap_eixo_y();

	}

	if(T1IR & TIR_CR2I){		
	   T1IR |= TIR_CR2I;			

	  acel_cap_eixo_z();

	}

	VICSoftIntClr = (1<<VIC_TIMER1);


	VICVectAddr = 0x00000000;             // clear this interrupt from
the VIC
	ISR_SAIDA();                           // recover registers and return
}





void acel_cap_eixo_x(void){
	u32 tpu; 
	
	if(IOPIN0 & ACEL_asc_x){	//verify rising edge
	   tpu=T1CR0;
           INS_ACEL_ESCREVE(0,
((ACEL_T2_x-ACEL_T1_x)<<14)/(tpu-ACEL_T1_x));
	   
           ACEL_T1_x=tpu;
		
	}else{			//falling edge
	   ACEL_T2_x = T1CR0;
		
	      	}
return;
}

...
...


#define  ACEL_BUFFER_TAM  8
#define  ACEL_BUFFER_MASK  0x07

static u32   	ACEL_BUFFER[3][ACEL_BUFFER_TAM+1];
static unsigned char	ACEL_BUFFER_ESC[3];


char INS_ACEL_ESCREVE(char eixo, u32 valor){
	
	if( (ACEL_BUFFER_ESC[eixo]+1)&ACEL_BUFFER_MASK ==
ACEL_BUFFER_LER[eixo] ) 
		return -1;
		
	ACEL_BUFFER[eixo][ACEL_BUFFER_ESC[eixo]]=valor;
	ACEL_BUFFER_ESC[eixo]++;
	
	if(ACEL_BUFFER_ESC[eixo]>ACEL_BUFFER_TAM){
		ACEL_BUFFER_ESC[eixo]=0;
	}

Thanks 
      Domingos
_________________________________________________________
CEAC Cursos de forma\ufffd\ufffdo profissional - pe\ufffda informa\ufffd\ufffdes aqui.:
http://ceac.online.pt/

--- In lpc2000@yahoogroups.com, dasbento@a... wrote:
> 	   T1IR |= TIR_CR0I;
> 	   T1IR |= TIR_CR1I;
> 	   T1IR |= TIR_CR2I;	
These three lines will turn off all the interrupts if more than one happens at the same time 
since it is oring a value onto itself and then writing it back.  If others are set they will be 
written back too.  You need to change the |= to just =.

> 	if(IOPIN0 & ACEL_asc_x){	//verify rising edge
You cannot read the iopin level while the iopin is assigned to the timer.  You must switch it 
to GPIO with PINSEL0 first, read it, then switch back.

Rob

Thanks Rob!!!

    The problem was to clean the interruption flags, as you said. The
part of reading the iopin, I can do because I have connected PWM to
the capture pin and a GPIO...

            Domingos




Citando chazeltopman <rob@...>:

> 
> 
> --- In lpc2000@yahoogroups.com, dasbento@a... wrote:
> > 	   T1IR |= TIR_CR0I;
> > 	   T1IR |= TIR_CR1I;
> > 	   T1IR |= TIR_CR2I;	
> These three lines will turn off all the interrupts if more than one
happens
> at the same time 
> since it is oring a value onto itself and then writing it back.  If
others
> are set they will be 
> written back too.  You need to change the |= to just =.
> 
> > 	if(IOPIN0 & ACEL_asc_x){	//verify rising edge
> You cannot read the iopin level while the iopin is assigned to the
timer. 
> You must switch it 
> to GPIO with PINSEL0 first, read it, then switch back.
> 
> Rob
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

_________________________________________________________
CEAC Cursos de forma\ufffd\ufffdo profissional - pe\ufffda informa\ufffd\ufffdes aqui.:
http://ceac.online.pt/

By the way also beware of this problem noted in the LPC2106 errata sheet:

In summary, while software is writing to the Interrupt Register, any Match or Capture event 
(which  are configured to interrupt the core) occurring at the same time may result in the 
subsequent  interrupt not being recognized.  Similarly for the Capture event, if a capture 
event occurs while a Match event is being is serviced  then the Capture event might be 
missed if the software and hardware accesses coincide.

 I'm enabling the channel interrupts for the timer only one at a time.

Rob

--- In lpc2000@yahoogroups.com, dasbento@a... wrote:

> 
> Thanks Rob!!!
> 
>     The problem was to clean the interruption flags, as you said. The
> part of reading the iopin, I can do because I have connected PWM to
> the capture pin and a GPIO...
> 
>             Domingos
> 
> 
> 
> 
> Citando chazeltopman <rob@n...>:
> 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, dasbento@a... wrote:
> > > 	   T1IR |= TIR_CR0I;
> > > 	   T1IR |= TIR_CR1I;
> > > 	   T1IR |= TIR_CR2I;	
> > These three lines will turn off all the interrupts if more than one
> happens
> > at the same time 
> > since it is oring a value onto itself and then writing it back.  If
> others
> > are set they will be 
> > written back too.  You need to change the |= to just =.
> > 
> > > 	if(IOPIN0 & ACEL_asc_x){	//verify rising edge
> > You cannot read the iopin level while the iopin is assigned to the
> timer. 
> > You must switch it 
> > to GPIO with PINSEL0 first, read it, then switch back.
> > 
> > Rob
> > 
> > 
> > 
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> 
> _________________________________________________________
> CEAC Cursos de formação profissional - peça informações aqui.:
> http://ceac.online.pt/