eQEP not reading meaningful values

[Hugh Frater]

Hi, I'm getting started on a control system that needs to read 2x quadrature encoders. One is a 1000 line, the other a 2000 line, but that is really immaterial. I have the physical interface sorted (one needs a 26lv32 to glue it to the BBB, the other is open collector), and the traces look good on the scope.

I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal cape. I can load Nathaniel Lewis' overlays (supplied with the clean install of Jessie) just fine with no errors in dmesg.

However when I 'cat position' in each of the relevant sys entries (having moved my encoder A/B lines to the relevant pins each time), I get a changing value but it isn't meaningful. Am I missing something, or is it more likely that I've blown up the inputs? I did power on the servo drive (that was connected to the 26lv32 breakout board) by accident when the BBB wasn't powered up.

I've tested with a simple 24ppr 'audio style' encoder and again don't get meaningful results.

Do I have to mess about with config-pin for each of the eQEP inputs, or should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set up the pins for me?

There's so much old documentation floating about it's hard to identify what is current and what is no longer relevant now that the universal-cape is in existence.

Regards, Hugh

[abhilash h]

Hi hugh,  

It never worked for me in 4.x kernel. I used to get same values. So i swutched back to 3.8 kernel . 

--
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 beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hugh Frater]

Hi Abhilash,

That's interesting, I will try and downgrade. May I ask what image you are using now (Angstrom, Debian etc)?

Hugh

[abhilash h]

I had used debian . And it worked with busybox rfs and 3.8 kernel also .

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com.

[Hugh Frater]

Thanks, I'm currently trying to downgrade to a 3.8 revision, 1st attempt resulted in a 'won't boot, all the LEDs are on' so I guess I missed a step.

[abhilash h]

I had used debian 7.9 

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/39682a43-a9ad-42a6-9906-751c77e102bd%40googlegroups.com.

[Hugh Frater]

I'll give 7.9 a go and let you know my findings, thanks.

[abhilash h]

For sure it will work.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7502f82c-ed74-4b74-9999-ebcd51bb91e4%40googlegroups.com.

[Hugh Frater]

I got it to work properly in 4.4.x - using the universal cape and running config-pin P8_11 qep & config-pin P8_12 qep

[Matthijs van Duin]

On Friday, 3 February 2017 13:17:20 UTC+1, Hugh Frater wrote:

However when I 'cat position' in each of the relevant sys entries (having moved my encoder A/B lines to the relevant pins each time), I get a changing value but it isn't meaningful. Am I missing something, or is it more likely that I've blown up the inputs? I did power on the servo drive (that was connected to the 26lv32 breakout board) by accident when the BBB wasn't powered up.

Verify the ports are working correctly in GPIO mode first.

 

Do I have to mess about with config-pin for each of the eQEP inputs, or should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set up the pins for me?

When using overlays they should setup pinmux correctly. config-pin uses cape-universal (which conflicts with pretty much any overlay). Beware that eQEP 2 has two pinmux options, for which two separate overlays exist.

Double-check pinmux e.g. using my show-pins utility.

Also, it looks like the driver isn't configured correctly for your purposes by the overlay, so you may need to adjust that.

The eqep driver is known to have buggy power management, try disabling automatic runtime pm using:

    for i in /sys/bus/platform/drivers/eqep/*/power/control; do echo enabled >"$i"; done

(Note: I personally don't actually have any experience with the eqep driver, I've only used the eqep modules via uio. I actually made a python example for that, although it's unmaintained since I came to the conclusion I don't actually like python.)

Matthijs

[abhilash h]

Hi hugh,

Can you share the link of universal cape 

On Fri, 10 Feb 2017 at 3:23 PM, abhilash h <abhit...@gmail.com> wrote:

Hi hug

--

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 beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7ff174d2-d920-4934-b7b3-9da58390774e%40googlegroups.com.

[Charles Steinkuehler]

On 2/10/2017 3:54 AM, abhilash h wrote:
> Hi hugh,
> Can you share the link of universal cape

It should be built into the kernel if you are using anything fairly
recent and built by Robert C Nelson (basically any of the available
Debian uSD images).

The original source (for the 3.8.13 kernel) can be found here:

https://github.com/cdsteinkuehler/beaglebone-universal-io

...while RCN's versions updated for 4.x kernels live alongside all the
other bb.org overlays:

https://github.com/RobertCNelson/bb.org-overlays/tree/master/src/arm

--
Charles Steinkuehler
cha...@steinkuehler.net