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]

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.

You can do this by using a timer and an external interrupt. If you were to use the divide-by-256 prescaler, a 16-bit timer would overflow in 1.13 seconds given the 14.7456MHz main clock. Alternately, you could use the timer's compare match mode instead of the timer overflow. This may yield values that are more convenient for calculations.

The ISR for the external interrupt would do nothing more than increment a variable. The ISR for the timer would only need to do iteration counting (if more than 1 pass is required) and then turn off the external interrupt when the counting period is finished, setting a flag to indicate to the mainline code that the data is ready for calculations.

BTW where can I get a free AVR assembler?

There are several. Which to choose depends on what you want to do. For example, Atmel offers AvrAsm2 which is an absolute assembler meaning, of course, that its output is not compatible with a relocating linker. There is also an AVR variant of the Gnu Assember that is part of the avr-gcc toolchain. Parts of the avr-gcc toolchain are installed with ZBasic among which is avr-as. This assembler produces relocatable output that can be linked with other object modules produced by other translators such as avr-gcc.

If you write your assembly language code using the avr-as syntax and observe the register usage conventions of avr-gcc, you can include the assember files in your ZBasic project and, if necessary, invoke procedures from ZBasic.

Gnu Assembler documentation: http://sourceware.org/binutils/docs-2.20/as/

avr-gcc register usage conventions: http://www.nongnu.org/avr-libc/user-man ... _reg_usage

Defining and using external prodecures: http://www.zbasic.net/doc/ZBasicRef.php?page=122

[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]

Here is another gift.

I find it much more convenient to use the Port.Pin format. For example, on the ZX-1280, I would use B.3 instead of 22 to refer to that pin.

[twesthoff]

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

I hate to see you give up. I didn't read your paper, but how accurate do you have to be with the RPM reading?

You should be able to make it work using the built in AVR hardware or with interrupts. These Zbasic chips are at least 25 times faster than the 6502 you used to use. I don't think you would have to use external hardware, but then I don't know all of your specs...

[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.