John is correct. My logging could be more clear. The "time between" is
the since the last rising edge of the input pulse as detected by the update
function of the encoder running in the base thread. The "counts between"
is the number of base thread runs since the last rising edge input pulse.
Th
On Sun, Jul 1, 2012, at 04:59 PM, Jon Elson wrote:
> Scott Hasse wrote:
> > Are you perhaps associating the wrong run count and run times log entries?
> > In the four-line log snippet you show I believe the middle two entries
> > would be associated with each other. I see the times between di
Scott Hasse wrote:
> Are you perhaps associating the wrong run count and run times log entries?
> In the four-line log snippet you show I believe the middle two entries would
> be associated with each other. I see the times between divided by runs
> between to be quite stable. I have run the
Are you perhaps associating the wrong run count and run times log entries? In
the four-line log snippet you show I believe the middle two entries would be
associated with each other. I see the times between divided by runs between to
be quite stable. I have run the latency tests and get about
Scott Hasse wrote:
> Jun 30 17:48:41 scott-desktop kernel: [ 4078.255547] ENCODER runs between:
> 60
> Jun 30 17:48:41 scott-desktop kernel: [ 4078.256330] ENCODER time between:
> 796760
> Jun 30 17:48:41 scott-desktop kernel: [ 4078.256344] ENCODER runs between:
> 40
> Jun 30 17:48:41 scott-deskto
I in essence made the sort of simplified counter you suggest from the
encoder.c with the addition of some logging in the update thread and the
addition of some fields to the cntr struct to keep track of runs between
counts and time between counts:
static void update(void *arg, long period)
{
c
