Here you say that the eQEP can handle 1 MHz input but on the github page 
you say the clock speed is  100 MHz. Is one of these a mistake or are these 
not the same thing? I'm looking for the max read frequency for quadrature 
encoders.
-Thank You

On Tuesday, July 16, 2013 at 10:10:33 AM UTC-7, Teknoman117 wrote:
>
> So there are three eQEP units in the beaglebone, one per timer subsystem. 
>  Unfortunately only two of them have all their pins broken out on the 
> original beaglebone (eQEP1 and eQEP2.  eQEP0 only has channel B and the 
> index pin broken out.  renders the unit useless).  The Beaglebone Black has 
> all three broken out.  The only mux options for the eQEP pins have them on 
> the lcd_data lines so you can't use an LCD or HDMI on either of the 
> beaglebones.  The eQEP0 pins on the black share lines with the audio 
> controller.  Just a heads up.
>
> I'm actually putting together a kernel module (platform driver) that fits 
> in nicely with the device tree.  Its still mostly a big hack right now, but 
> it will support the three measurement modes of the eQEP unit -> absolute 
> position, frequency measurement (counts per unit time), and pulse width - 
> where it measures the width of the encoder pulses.  But yes, what you want 
> to do is entirely possible.  I'm using the input subsystem of linux.  So 
> you'll just listen to an /dev/input/ device like so:
>
> /dev/input/by-path/platform-48302180.eqep-event  (eQEP 1)
>
> And when you get an event, you'd read the ADC.  The issue is that the 
> hardware wasn't designed to alert the device a lot.  For instance there is 
> not "position changed" event from the hardware.  The only way to implement 
> that is to set the max position to 1 and listen for overflow or underflow 
> events.  At that point you loose the advantage of having the hardware 
> because of the sheer amount of interrupts flooding the CPU, as eQEP is 
> designed to handle up to 1 MHz input.  I'll have the sources up on my 
> Github in a few days when I can assure people the driver doesn't break 
> stuff.  On the kernel side of things, I'm coming up with an abstraction, a 
> lot like the linux/pwm abstraction, because the kernel doesn't have an 
> abstraction for position sensors.  And there are a lot of things I'd like 
> to do with the unit, like high frequency PID control of a motor, but on the 
> kernel side so its very responsive.  I'm just trying to decouple the 
> hardware driver from the input driver.  
>
> - Nathaniel Lewis
>

-- 
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].
For more options, visit https://groups.google.com/d/optout.

Reply via email to