Multi input Pulsin in ASM non blocking

hkiela

I am looking for an object in assembly, capable of measuring puls width on multiple inputs.

The ideal object should have a similar interface like the quadrature encoder object, i.e. a pinnumber, variable and count as in Quadrature Encoder v1.0.

The object should run in assembly for speed reasons. It should be non blocking, when no signal is connected by means of a timeout for example and continue with the next pin to measure. The associated variable should get a negative value (-1) signalling a timeout.

Not being too fluent in ASM, I hope that some one has a jump start object that I could use further

Henk

pjv

Hello Henk;

The multi-threading scheduler I have written might be quite suitable for your application. But it depends on what resolution and what precision, and how many inputs you might be looking for, and you have not provided any such details.

Typically the scheduler could handle something in the order of 2 inputs with 1 uSec resolution and typical accuracy of 1 uSec for speeds up to 100 Khz, or say 10 inputs with 1 uSec resolution and typical accuracy of 2 or so uSec for speeds up to 10 Khz. Lower speeds permit a larger number of inputs, and will bring up the typical accuracy. The resolution remains at 1 uSec regardless of speed or point count.

Cheers,

Peter (pjv)

localroger

This is not too hard to do with a little knowledge of PASM and how to pass the results back to the presumably Spin app that will either use or report them. The trick is that you won't be able to use WAITPEQ or WAITPNE. With those instructions you can measure pulses to 1 clock cycle resolution and fully document pulses down to about 12 clocks wide. Measuring multiple pulses you'll have to poll in PASM, in a loop, which means both your temporal resolution and minimum pulse width will go to more like 20-30 clocks or more. If that's not good enough then you need to use a cog for each signal. Cogs can communicate timing between themselves very quickly by toggling pins; if one cog raises and OUTA another will see it on INA without the hub delay.

hkiela

Thanks Peter,
I am measuring typically frequencies from 10 hz to 100 kHz. A resolution of 1 us should be sufficient in most cases. I would like to be able to connect up to for example 8 inputs.The current Pulsin in Spin is far too slow to leave time for other tasks in that cog and blocks if the signal drops away.

hkiela

One cog should be able to monitor all inputs sequentially. Suppose there are 8 independent signals with a frequency between 1000 and 4000 Hz, a typical measurement shoudl average over 2 or 5 cycles (a parameter to select?) and then move on to the next input, wich would mean, taht a total cycle for 8 inputs would be possible within 50 ms with a decent resolution, even with polling in pasm.

henk