AVR-Chat

On Thu, Apr 30, 2009 at 8:54 PM, A & T Schrum <agschrum@mindspring.com> wrote:
> With the timer running at CK/1, then does it not run at the CPU clock
> speed?

Yes, that's what I intended.

> That would mean that instructions that take a couple of cycles to execute will allow for
> a couple of cycles on the timer to pass.

Correct, and I would still expect to get different readings in integer "ticks".
I described this to someone earlier as like measuring bricks with a
ruler that only does inches.
If I pile 10 bricks into a line, and get 95 inches, then I know each
brick is 9.5 inches.

In my case, I'm also measuring another "pile of bricks" and finding
out how much difference there is between the length of bricks from the
two sources, if you follow.

> The sequence of steps you do in finding the 5 wave forms are very repeatable. The final transition on the fifth cycle to where you detect it and stop happens between where you last read the signal (and it is false) to where you read it and it is true. Then you stop the timer. The resolution that you will get is essentially the size of your last "while" statement check for the last transition of your waveform.

Correct, but this is true for both measurements. So I expect that it
will all come out in the wash.

Also, this problem did not surface when I was taking readings from
each sensor individually, it's only when I subtract the second one
from the first that I see this behavior.


> That loop is a bit test and branch not equal or equal which is probably three cycles (and three counts on the timer). All the rest in front is essentially ignored and the instructions stopping the timer are a fixed constant relative to the granularity of the timer values.

Right..

> Optimization of -Os reduces space at the loss of efficient processing in the code. It may be that the last "while" statement is done in a manner that is less efficient in time than the other and you end up with 12 clocks.

hmm.. Again, I did not see this until I started subtracting one sensor
from the other.

> Check the assembly code of that last loop and that should correspond to the granularity of your timer value.

I'll be looking at that tomorrow.

> If you want greater accuracy, either sample more waveforms (how about 15 since you have a multiple of three in your timer value), or use an external trigger to stop the counter (if possible).

This is a road that I'd rather not go any farther down.  My sample
routine happens inside an ISR, so that it is atomic, and it can take a
fair amount of time.  I'd love to find a more effective way to do
this.  The input capture hardware is tempting, but I'd have to add
external hardware since I only have one input that I can use that way,
but two sensors.  Another method would be an external counter, but
again more hardware.


> Does this seem reasonable?

That's pretty much the lines I've been thinking down, but why would I
get smooth integer values then for each sensor taken individually?

-- 
There is no computer problem which cannot be solved by proper
application of a sufficiently large hammer.