Adding capabilities to my ELS system

[WobblyHand]

That's a bummer about the slipping counts. Do you think that globally reducing time spent in ISRs would help, or do you think switching over to hardware encoders is necessary?

Don't know at the moment. But, pulling out excess vegetation out of code is usually good. I need to do a bunch of weeding! Also implement better logging than I had. A lot of unnecessary stuff has crept into the code, (debugging and flailing, trying out new ideas,) so I need to look at it again - especially in the encoder ISR.

I haven't had a chance to get back to my code yet. Too many summer projects going on right now. Hoping to get back to that sooner rather than later. One of the things I hope to do next is look at the code for configuring the hardware encoders. I'm still using the library for that, but would rather distill that code down to something a bit more specific to this project. Doing so for the reads reduced read latency a fair bit.

One of the guys on the Teensy forum is looking into doing a callback on an edge for the QuadEncoder library. I had commented that polling is lame for my application, my algorithm (Bresenham) needs to act synchronously with the edges. If QuadEncoder had callbacks it would be a lot easier to implement Bresenham.

 

[dkemppai]

Not sure what a callback would look like, or what would trigger it. There are interrupts in the quadrature hardware, but those all seem to be related to the index pulse.

On the ELS board here, I brought the spindle encoder A signal to a second pin. Then used a pin interrupt on that signal to trigger a capture of all of the hardware encoder values (and also data logging for debugging). This way the hardware encoder is free to do as it pleases, but I still have a signal synchronous to the spindle that can run code depending on the spindle position. By time stamping that spindle encoder A signal edge AND capturing the four encoder values, at least I have a snapshot of where everything was and when. In my case, that rising edge of the A pulse happens 2000 times per revolution. Which should be plenty fast for anything I'd need to keep track of.

The reason I brought the signal to two pins was because I couldn't sort out an easy way to map an interrupt to that pin once it was mapped to the hardware encoder. The XBAR wouldn't allow that. But a simple wire trace would give the option.