Unexpected results from Encoder::GetRate()

[jhersh]

Originally Posted by vamfun

What I would like, though is an option to modify the algorithms which I could do if the A/B interrupt count and timing was transparent. But Joe /Ni have elected to not make this code open source. We can write our own routines from scratch, but I would be satisfied if a GetEdgeState() function was implemented that provided edge count, direction and time_since_last_edge for the 1x case. This state captures all the information available from the A/B channels and could be easily modified to create whatever distance/rate algorithms you wanted. One could argue that these are available with GetRaw(), GetDirection() and GetPeriod() or their visible subfunctions.. but if called in sequence, I don't think they can guarantee to be synchronized to the same edge event. Maybe Joe can comment on this.

This is yet another demonstration that there has not been enough time for code or documentation. The whole point of the DMA engine is to provide you with information in a synchronous packet. I believe that with the Interrupt and DMA together you can accomplish everything you described or intended.

Here's how:

The DMA packet contains the position, direction, period, and "stalled" indicator (the configurable counter-inactivity timer). Each packet also includes a timestamp. You can configure DMA packets to be sent periodically or you can configure a digital source as the packet clock. If you use one of the encoder phases as the packet clock, then you can just use the timestamp in the packet for your timing. If you hook the packet clock to some unused digital output, you can request DMA packets on demand. You can also use periodic timing and use the distance and direction only. You can also hook one or both of the encoder phases to interrupts. This will not only notify your code, but also timestamp the event (using the same timestamp source as the DMA packets) so you can compare the timestamps of interrupts and DMA packets as needed.

That being said, the one that is built in for you is WAY easier to use so at least for me I would have to have a pretty big problem with that implementation to want to reimplement it on the RTOS using DMA and Interrupts. The reason for including DMA and Interrupts was to make the system be super flexible to support interesting sensor interface requirements.

BTW, you can get the same results that you get with your algorithm by simply adding 1 to the distance if direction is false with the built-in counter and you don't need any of that fancy stuff. But it will be worse!

-Joe