What if I need a capture timer?

ManAtWork

Hello,

for my current project I need to measure the speed of a motor and do several calculations based on that. The speed signal is a frequency proportional to motor speed (sort of encoder signal). To achieve good resolution even when the frequency is low it would be nice if I could not only count pulses but could also get information about when exactly a pulse arrived.

I know, I could WAITPEQ on the input pin and record the CNT value. But first, I dont want to waste a seperate cog only for watching a single pin. Second there is the problem when the speed drops to zero and no more pulses·will arrive at all. In that case the cog will wait forever and fails to report the speed change.

I have studied the documents for the counter modes. There is an EDGE mode that counts signal edges. There are several logic modes but none of them seems to be useful for capturing the time of events. Everything would be fine if there was some sort of "store CNT in PHSx each time an input change happens". I could then spin in a loop checking for new values and calculating speed as inverse of the delta times.

Can the feedback modes be configured somehow that the counter counts until a special input condition is met and then stops? Any other idea?

Thanks

Timmoore

It sounds similar to something I did a while ago. I wanted to time a pulse without using a cog. Again the counters wouldn't do exactly what I needed. I ended up with the following, I used the counter to count the high time of the pulse but I had a routine called from an existing cog that could call often enough for the fastest pulse. The routine would check the pin state, start the counter if needed, get the counter vaue and store it if needed. The polling time had to be fast enough to get there 1 per pulse, for me one per 0.5ms, but the counter measured the pulse width.

I attached my code which was based on someone elses, look at 2 routines - DemuxVexCog uses a cog, Poll does the same thing as DemuxVexCog but without using a Cog, the requirement is that it is called by another cog at least every 0.5ms.

Bean

I don't see the problem with the encoder stopped. Sure the cog won't update, but the encoder is not moving...So there is no need to update anyway.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

Mike Green

It is not a waste for a separate cog to be assigned a simple task. It's a legitimate use of a cog.

There is no counter mode like what you suggest and there is no way to stop a counter automatically when a condition is met.

I suggest you write an assembly routine to count pulse edges. At 50ns per instruction, even a complex routine would be able to give you a resolution on the order of microseconds. The routine could have a timeout as well so that it can detect when the pulse frequency is near zero.

Mike Huselton

Mike

I agree - cogs are cheap, especially at the reduced price. Solve the problem at hand in the simplest way possible.
Exotic techniques can always come later, when you really need every single cog.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

ManAtWork

Reduced price? What reduced price? Anyway... I only have space for one propeller on my board and cogs are only cheap as long as you don't run out of them. I have to control more than one motor, I forgot to mention.

Thanks for the suggestions. I think I will do it like Mike said and manually poll the pin with an additional timeout. If the resolution is not sufficient I can add a more complicated timer technique later, like Tim suggested. Measuring the high time since the last poll is a good idea. Unfortunatelly, my pulses are a bit narrower, 2µs worst case. I have to use a tight assembler loop so I don't miss one (which could be at least detected by a second timer counting edges).

Cheers

Timmoore

What else are you doing? If you need to save cogs, other functionality maybe easier, for example if the motors are DC brushed there are objects that can generate the necessary pwm for multiple motors in 1 cog.

kwinn

You could always use a counter to count the number of pulses and the CNT register to measure time and then use either the time between pulses or the number of pulses per unit time (depending on which gives better accuracy) to determine speed.

Phil Pilgrim (PhiPi)

ManAtWork,

One thing you haven't mentioned is the duty cycle of the tach input. Is it 50% or some other value. This will have a bearing on your solution.

-Phil