newbie question: best ways to improve frequency meter

dfletch

Hi!

Yesterday I created a little tool in the object exchange called "Frequency Meter". It has some promise but I've run into some issues I could use a hand with.

1) It currently blocks execution during the sampling routine. I'd like to have a feature like "start sampling and notify me when sampling is done". How should I achieve this? Pass the address of a long to the function and then modify the long upon completion (stored temporarily as an object var)? Is that the best way?

2) The assembly WAITPNE blocks forever if the pin never changes. Is there some way to code a timeout without starting another cog? My singing seven frequency meter demo actually uses all 8 cogs, so I'd like to avoid starting one more.

Project:
obex.parallax.com/objects/256/

Oh and btw, woo project # $100

dfletch

Ack, scratch question #1 totally figured it out. I'll have a polling method on the frequency meter to test if it's still running. Rev 0.5 coming shortly.

Still wondering about #2 though.

deSilva

Most people determine a pulsewidth in the same way as you have done, as these are just 5 or 6 instructions. They live with the rare situation of a hang-up

The correct way is to engage the two counters A and B

A shall count the ticks for a high level.
B shall count falling edges as a safety belt.

(1) Make sure you are in a low phase
(2) clear PHSA and PHSB
(3) Wait until PHSB becomes >0
(4) When your interloop activities had been too extensive, you might read 2 or more in PHSB. You have to decide what to do with it.. Has it been a glitch? A VERY high frequency?
(5) Otherwise PHSA gives you the result searched for...

Note that this is not a good method to look for pulses <200 ns. In that time scale you better count the falling edges for a specific time (e.g. 1 ms, or more for increased accuracy.

There are many threats here discussing one aspect or the other of locked WAIT situations...

Goran (Sweden)

Dave,
I had a similar project that nedded this #2,
I read the CNT before the WAITPNE and after I read the CNT again and compared it with the previous, If it then was over a certain value I did a "quit"
code snippet**********
PUB Controll 'This make sure the process cont. if pin in the WAITPNE never activates
InitTime 'Read the first store of CNT
if rctempInit + cnt >2000
flag:=4
********************************'
Hope this helped.
Goran (Sweden)

dfletch

deSilva: Thanks! The counters sound great. Reading the separate appnote in detail now.

Goran: Aha yes of course because the thing that's blocking is the combination of waiting for pos/neg edge, so between them I could do some work. /me smacks forehead, so obvious now I think I'll look into counters though, since I think it will boost the resolution of the counter!

Cheers,

--fletch

deSilva

dfletch said...
.....I think it will boost the resolution of the counter!

Not necessarily much... The WAITPEQ is up to the tick (12.5 ns) and you read CNT a fixed and constant time later (50 ns). So this is exact as it can be.

When reading through your code I just see that you need the falling edge only. So this is something the counters are really made for

In my example above I assumed you needed also the pulse width, which you don't.
This will make your loops even simpler

dfletch

deSilva: Hmm yeah I should have realized that the bottleneck is in the data collection, messing with WRLONG is a bit expensive. Maybe I could use cog ram instead to shave some cycles.

Thanks again for the great tips, and for that awesome assembly tutorial

Cheers,

--fletch