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 On Sunday, 23 April 2017 09:23:27 UTC+10, Drew Fustini wrote: > > On Thu, Apr 20, 2017 at 11:30 AM, <[email protected] <javascript:>> > wrote: > > 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 > -- 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/501c9199-d0c0-47e5-96b5-51686a4c74fd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
