Official eQEP driver Support

Damn, now that its in the kernel i’m going to have to maintain backwards compatibility =P.

As far as eQEP goes, I think you can enable eQEP 0 without any conflictions. (P9.42 = eQEP0A_in, P9.27 = eQEP0B_in, P9.25 = eQEP0_strobe, and P9.41 = eQEP0_index → all at mode 1). I read above someone wanted to see the eQEP hardware in the angstrom device tree - here’s a patch just for the device tree file.

  • Nathaniel Lewis

0001-Patch-am33xx.dtsi-to-include-device-tree-nodes-for-the-eQEP-units-in-the-SoC.patch (1.57 KB)

eQEP2 is connected to two sets of pins, one of which may also be exposed without disabling the HDMI. Here are the pins:

`

0x038 0x24 /* P8_16 = GPIO2_12 = EQEP2_index, MODE4 /
0x03C 0x24 /
P8_15 = GPIO2_13 = EQEP2_strobe, MODE4 */

0x030 0x34 /* P8_12 = GPIO2_10 = EQEP2A_in, MODE4 */

0x034 0x34 /* P8_11 = GPIO2_11 = EQEP2B_in, MODE4 */

`

  • James Zapico

James:
Thanks. That works for me. Can this be included in the next debian release?

–Mark

Hello,

I’m a bit stuck with your driver and cannot seem to get it working…

I’ve done everything adviced in this discussion and on your “readme” files but whereas the device tree applies itself when I echo, the 4 sysfs entries don’t appear, I just get the usual “modalias power subsystem uevent” entries.

I must have done something wrong but I honnestly don’t see what it could be, does anyone have any idea? =/

ps: I’m running on Angström with the 3.8 kernel modified with your patch and with HDMI disabled.

I have got the eqep2b working fine and dandy, but when I try to add a second encoder using eqep0 i follow the same device tree configurations, and when I go to read the position of eqep0 hooked up to p9.27 and 9.42 I get a position of 0, always! Do you know what could be causing this? Or point me in the direction of someone who has gotten two encoders working at the same time using two eqep modules?

Thanks ya!

Some folks have gotten all three encoders working with Machinekit.

Just guessing, I'd say review your device tree file and make sure you've
got the pin mux settings correct. Note that some encoder input pins
appear on more than one CPU pad...make sure only one of these pins is
set for eQEP usage or you get undefined behavior.

Also, since you're using P9.42, make sure the mux value for both CPU
pads tied to this one pin are setup so they don't conflict (ie: the
unused pin should be set to be a GPIO input or similar.

I would like to make known a bug we ran into with reading the eQEP module that resulted in position values not updating after exactly 1020 reads without closing the file pointer.

Of course you are using a low level read function, not buffered userspace IO like fscanf().
That is, use read() not fscanf(). Then try using seek() back to file begin, offset 0, in between reads.

HTH,

Dick

Hi all,

I’m trying to use the eQEP Linux driver. I can get it to load by adding a device tree overlay, but it doesn’t increment much. I can see that its loaded (called tieqep) with lsmod etc.

I’ve never used a quadrature encoder before, so I question if I just havn’t connected it correctly.

At times it doesn’t increment (reading Position file in /sys/device/ocp/epwmss48… folder), other times it increments or decrements 2 or 3 positions.

If I jiggle the wheel back and forth a small a amount, it counts a lot. The dual hall effect sensor outputs clean and clear waveforms at 3.3v, 90 degrees out of phase, switches phase when change wheel direction just as I expected.

I’m only using channels A and B, did not touch other connections.

I’ve tried using all 3 eQEPs separately (including the 2b overlay for alternate pins of eQEP2). I’ve used Derek Molloy’s P9 and P8 header files.

Currently have proto-cape with pins 35 (A input)and 33 (B input)on P8 header for eQEP1.

Other eQEPs have same behaviour. I’ve also swapped the beaglebone black board with a new one.

I’m using kernel 4.4.9-ti-rt-r25 but with old llibraries and system from like 2015 I think as Simulink doesn’t officially support anything higher. I only upgraded the kernel.

Please let me know if anyone has any advice.

Thanks,
Fisher

I've been using a rotary encoder successfully with the tieqep driver:
https://blog.oshpark.com/2017/04/05/rotary-encoder-breakout-with-pull-up-resistors/

I'm running 4.4.47-ti-r87 on Debian 8.7. I've got it connected to
P8.11 and P8.12. I'm using config-pin to set the mode on those pins.
Details here:
https://github.com/adafruit/adafruit-beaglebone-io-python/blob/eqep/doc/rotary-encoder-eqep-test.md

The position does accurately reflect how many increments I turn the
encoder knob. However, this is at a relatively low rate of speed as I
can not turn the knob as fast a motor with an encoder.

You could try using the Strawson library as an alternative to the
kernel driver. I believe it has support for the encoders:
http://www.strawsondesign.com/#!manual-encoders

regards,
drew

Hi Drew,

Thanks very much for your reply and info, I’ve previously seen your 2 YouTube videos showing your setup from a few years ago which gave me some clues and I downloaded the same image you used then and saw it worked fine.

I had made a mistake by using 5v on the hall sensor as the datasheet claimed it only worked above 5v. I didn’t add anything to reduce its output A and B channels, so I wondered if I damaged QEP 2b or the whole eQEP system.

Thankfully, the board is fine and I’ve found that the issue is actually the wrong mode values in the newer eQEP overlay files.

Nathaniel Lewis originally used modes 0x24 for the index and strobe pins, and 0x34 for channels A and B. It seems that all or most updated images use modes 0x2c for all pins and so it seems that the driver doesn’t work, when its just to do with pull-down resistors being enabled.

So, one doesn’t have to use the Cape-Universal overlay if you don’t want to.

I prefer to use separate overlays at the moment as I’m trying to get Simulink support for eQEP working as well as upgrading Simulink support to work with the newer images (kernel 4 and above as the slots path has changed etc).

Fisher