Jitter

[Paul Lamar]

Thanks Don,

I'll spend some more time with the docs.

Paul Lamar

[Paul Lamar]

As I understand it inputcapture is recording the elapsed time between active edges of the input signal. That is less accurate for my purposes.
What I want is a counter than can count pulses for a fixed period of time.
Is there something in the 1280 that does that. The old 6522 via had
the hardware to do that.

100 teeth on the flywheel coming in at 125 revs per second
(at 7500 RPM} is 12500 counts in one second.
That means in .6 second you have 7500 counts coming in.
Note; the 13 bit read out needs no further calculations.
That and other tricks like it are described in a IEEE
paper.

Microprocessor-Based System for Roll-Down and Acceleration Tests
by D.K. Lynn, C.R. Derouin, and Paul Lamar
Los Alamos Scientific Laboratory
Published in IEEE Proceedings 29th Vehicular Technology Conference
Arlington, Illinois, March 28-30, 1979

(The technical details of the Lamar Instruments real time
automotive road test system.)

That is by far the most accurate and fastest way
of determining RPM. It requires a bit of external hardware
however.

It looks like a couple of cheap CD4520's and a 555 will do
the job. The down side is it uses two 8 bit ports but the 1280
has ports to spare. The Int latency becomes unimportant as the
.6 second timing is done by the 555 which disables
the input count and then signals the Int.

This is the same idea as CountTransitions however during the long counting process processor interrupts are >>> NOT <<<< disabled.

BTW where can I get a free AVR assembler?

Paul Lamar

[dkinzer]

[Paul Lamar]

Thanks Don,

Still studying the AVR hardware interrupt stuff.
I am making a stand alone doc file on it I will send when it is done.
Pages and pages. I think my old scheme for multiple hardware
interrupt handling was simpler and better than the AVR

I am thinking I might implement that in hardware off loading AVR processor time.

Here is a excerpt from my IEEE paper by way of explanation of what
I am trying to do. This was a 1 MHZ 6502.

I really want to get this BASIC to work for precise hardware timing control.
Due to the data types I know that is not completely obtainable but I
would like to come as close as possible.

Using a multitasking OS like Real Time Linux and an Atom PC board was
considered but that would require C programing. Too steep a learning
curve for my readers. I like BASIC better.

Paul Lamar

[GTBecker]

You might consider using a free-running counter, InputCapture and an
interrupt.

If the ICP line and the interrupt are tied together, the counter value
at the edge of the ICP is latched; simultaneously, your interrupt
service routine code starts, which fetches the ICP counter value and
subtracts the previous ICP counter value from it to determine the period
between edges. The free-running counter itself is never disabled,
serving as a simple timebase of whatever resolution you like.

[Paul Lamar]

I give up

I am not going to use ISR's.
I'll do all the real time stuff in hardware.

Here is another gift.

Paul Lamar

[dkinzer]

[twesthoff]

[GTBecker]

Just reinforcing don't give up:

Perhaps you might take a step back and reconsider the design,
considering current technology. Unless you need to duplicate the method
that you implemented on a 6502 - a far less capable machine compared to
today's MPUs - perhaps you might find a more natural solution by
reevaluating the problem, given the resources available on a ZX-family
machine. Determining RPM, in particular, is not currently a difficult
thing to do.