Unexpected results from Encoder::GetRate()

[vamfun]

Originally Posted by jhersh

Yes... if you did it that way, you would have a small window for the register to change. However, that is why I put both in the same register. Same thing goes for the period, the count, and the stall information. All related; all in the same register.

If instead you did:

INT32 Counter::Chris_Get()
{
	//Now all the information is read in one register access!
	tCounter::tOutput output = m_counter->readOutput(&status);

	// dir = 0 decrements count
	if (output.Direction)
	{
		// if we haven't reversed then update count
		return output.Value;
	}
	else
	{
		// else keep the count at last value
		return output.Value + 1;
	}
       
}

Cheers!
-Joe

Thanks, that's what I was looking for. Duh, I finally found the tcounter.h files in Windriver Chipobject directory that describes the output data structure. Had I found those earlier, I could have figured a few more things out for myself.

I still would like to know the details of your GetRate() algorithm that keeps the rate from reporting on a same edge. Its not obvious where you do this.

Also, could you describe the 4x algorithm equations (like your description of the 1x and 2x earlier).