Lpc2000

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