I think the primary use for the eQEP is to decode shaft encoders that are being used to replace analog controls for volume control, tuning, tone controls, etc.
In other words, knobs for applications suited for them, but you don't digitize the analog knob output, you go directly into the digital domain inside the shaft encoder. There are also some industrial applications for measuring speed (and position) of motors, belts, etc. The shaft encoder has two switches that open and close in a quadrature "gray code" pattern so you get rotation and un-ambiguous direction of rotation. The problem is that they usually come in applications greater than two. We use them for radio controls, but our application uses 12. So, rather than deal with the vagaries of a real time process running underneath an OS, we just programmed a PIC to watch all 12 simultaneously, and the Linux OS can ask the PIC the status of any or all of the knobs when it gets around to it. So using the eQEP inside the BBB is fine for learning how shaft encoders work, but I don't see using it for real world applications with more than one or two knobs. --- Graham == On Tuesday, February 28, 2017 at 6:02:17 PM UTC-6, William Hermans wrote: > > > > On Tue, Feb 28, 2017 at 3:41 PM, Drew Fustini <[email protected] > <javascript:>> wrote: > >> >> eCAP is interesting as there seems to be two modes: capture input, and >> PWM output. The use of eCAP as PWM output is already supported in mainline >> as part of epwmss. >> >> However, the eCAP input driver written Matt Porter is still out-of-tree >> and carried as a patch by Robert. At least this my understanding after >> chatting with Robert Nelson and Michael Welling last week. >> >> eCAP input seems to be another candidate to upstream. Question is which >> subsystem fits best. >> >> > You know I'm not really sure. I've never used the ecap module before, but > my impressions form what I've read that the ecap is similar to a high speed > ADC, except instead of "capturing" voltage levels. ecap captures logic > level transitions. High's, to low, low to highs.. > > Again I'm not sure for this specific application, in terms of speed, but > imagine a car with a high RPM engine at the drag strip. Where one could > monitor the rotation speed of the engine's cam, and adjust engine timing > based on engine RPM. I've discussed this a few times in the past with a > person talking about maximizing an engines performance curve. But with an > engine operating at let's say 30,000 RPMs, an ADC would need an insane > amount of sample per second. I think at one time we calculated this out to > somewhere around 2-3Msps minimum. With pulse counting however, which is all > you'd really need an ADC for with this application. I think "samples per > second" could be mitigated some. > > Of course with this application mentioned above. One would probably have > to use the PRU's, but I'm also not sure in this case if the ecap module, > the PRU's or the beaglebone board in general would be up to the task. > Because not only would one need to count RPM pulses, but one for this > application would have to act on those pulses. The X15 most definitely > could handle this. > > Anyway, I'm not sure if that really helps with the question in general. > It's just a thought I've had once in a while for several years now. I have > had other ideas similar to this one where I *think* pulse counting could in > fact be used instead of ADCs. For various other projects I've considered in > the past. *shrug*. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2bb63ba3-e2cd-4b15-a6b9-92e199f3538b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
