eQEP on 4.4.19-ti-r41

[Mark A. Yoder]

Hi:

  I'm running BeagleBoard.org Debian Image 2016-08-28 which is running the 4.4.19-ti-r41 kernel.  I've disabled the HDMI (audio and video) and want to use the eQEPs.

ls /lib/firmware/ | grep -i eqep

bone_eqep0-00A0.dtbo

bone_eqep1-00A0.dtbo

bone_eqep2-00A0.dtbo

bone_eqep2b-00A0.dtbo

PyBBIO-eqep0-00A0.dtbo

PyBBIO-eqep1-00A0.dtbo

PyBBIO-eqep2-00A0.dtbo

PyBBIO-eqep2b-00A0.dtbo

shows I have several options.  However none seem to work.

echo bone_eqep1 > $SLOTS 

-bash: echo: write error: File exists

dmesg

[Sep14 16:15] bone_capemgr bone_capemgr: part_number 'bone_eqep1', version 'N/A'

[  +0.000075] bone_capemgr bone_capemgr: slot #9: override

[  +0.000045] bone_capemgr bone_capemgr: Using override eeprom data at slot 9

[  +0.000046] bone_capemgr bone_capemgr: slot #9: 'Override Board Name,00A0,Override Manuf,bone_eqep1'

[  +0.012094] bone_capemgr bone_capemgr: slot #9: bone_eqep1 conflict P8.35 (#4:univ-emmc)

[  +0.008573] bone_capemgr bone_capemgr: slot #9: Failed verification

So it looking like the emmc overlay is controlling the pin.

What's the correct way to get emmc overlay to let me use the pin?

Do I have to get dtb-4.4-ti and edit am335x-boneblack-emmc-overlay.dtb?  If so, what do I edit?

I'm looking for a general approach that I can apply to other pins I want to control.

Thanks...

--Mark

[Mark A. Yoder]

Well, I found half my answer.  A simple:

config-pin -a P8_11 qep

config-pin -a P8_12 qep

gets the eQEP pin muxes set, but once set how do I export them? 

cd /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep

ls 

driver_override  modalias  of_node  power  subsystem  uevent

There are no period, or position files to read.

--Mark

[William Hermans]

echo bone_eqep1 > $SLOTS

-bash: echo: write error: File exists

Yeah, you're going to get this error whenever you load a device tree file that attempts to mux pins that have already been muxed in a different overlay. At minimum, when using config-pin overlay <overlay>. I'm not however sure if one would encounter this error when loading overlays when using the standard "traditional" method.

Are the eQEP modules related to the pwm modules ? I do not remember, but if they are, they'll be listed in /sys/class/pwm . I've never used them . . .

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e476efbe-ffa1-4356-8200-e6f0e32bc3c7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[William Hermans]

OK so hopedully this helps you Mark.

debian@beaglebone:~$ ls /sys/devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm
pwmchip5

debian@beaglebone:~$ ls /sys/class/pwm/pwmchip5
device  export  npwm  power  subsystem  uevent  unexport

debian@beaglebone:~$ ls /sys/class/pwm/pwmchip5
device  export  npwm  power  subsystem  uevent  unexport

debian@beaglebone:~$ sudo sh -c "echo '0' > /sys/class/pwm/pwmchip5/export"
debian@beaglebone:~$ ls /sys/class/pwm/pwmchip5
device  export  npwm  power  pwm0  subsystem  uevent  unexport

debian@beaglebone:~$ ls /sys/class/pwm/pwmchip5/pwm0/
duty_cycle  enable  period  polarity  power  uevent

[William Hermans]

Yeah that probably wont work. It's probably configuring the eQEP module as a PWM. I don't know Mark, it seems broken to me.

Nothing of use here:

debian@beaglebone:~$ sudo find / -type d -name '*qep*'
/sys/bus/platform/drivers/eqep
/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep
/sys/firmware/devicetree/base/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/pinctrl_eqep2_pins
/sys/firmware/devicetree/base/ocp/epwmss@48300000/eqep@0x48300180
/sys/firmware/devicetree/base/ocp/epwmss@48302000/eqep@0x48302180
/sys/firmware/devicetree/base/ocp/epwmss@48304000/eqep@0x48304180
/sys/firmware/devicetree/base/__local_fixups__/ocp/epwmss@48300000/eqep@0x48300180
/sys/firmware/devicetree/base/__local_fixups__/ocp/epwmss@48302000/eqep@0x48302180
/sys/firmware/devicetree/base/__local_fixups__/ocp/epwmss@48304000/eqep@0x48304180
/sys/module/tieqep

[William Hermans]

Mark, let us know if you figure anything out. I spent a couple hours on trying to figure this out myself - with no joy.

Something seems very broken, but I did recall that the PWM modules exhibit the same behavior, if you do not load the epwmss modules prior to loading the actual pwmx module in a device tree overlay. But I checked the source file for the eqep2b overlay, and all that seems to be in place.

[Mark A. Yoder]

William:

  Thanks for looking into it.  It looks like you got about as far as I did.  There is something missing that should make the eQEPs appear.

--Mark

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[bkus...@gmail.com]

Mark,

Did you have any luck solving this?  I'm running into the same problem on 4.4.9-ti-r25 and Debian Jessie.

Disabled cape_universal=enable in /boot/uEnv.txt

Set cape_enable=bone_capemgr.enable_partno=bone_eqep1

and also tried various other things.  Can't get config-pin -l to recognize that P8_31, etc are allowed to be eqep.

The 'fragment' definitions are in the dts files, but config-pin doesn't see them.

$ cat /sys/devices/platform/bone_capemgr/slots

 0: PF----  -1 

 1: PF----  -1 

 2: PF----  -1 

 3: PF----  -1 

 6: P-O-L-   0 Override Board Name,00A0,Override Manuf,bone_eqep2

 7: P-O-L-   1 Override Board Name,00A0,Override Manuf,bone_eqep1

$ config-pin -l P8_31

default gpio gpio_pu gpio_pd uart

This error looks bad:

[  456.118649] bone_capemgr bone_capemgr: part_number 'bone_eqep1', version 'N/A'

[  456.118721] bone_capemgr bone_capemgr: slot #7: override

[  456.118762] bone_capemgr bone_capemgr: Using override eeprom data at slot 7

[  456.118809] bone_capemgr bone_capemgr: slot #7: 'Override Board Name,00A0,Override Manuf,bone_eqep1'

[  456.134771] platform 48302180.eqep: Cannot lookup hwmod 'eqep1'

[  456.156907] eqep 48302180.eqep: ver. 1.0

[  456.157294] eqep 48302180.eqep: failed to get clock

[  456.177397] eqep: probe of 48302180.eqep failed with error -2

[  456.177984] bone_capemgr bone_capemgr: slot #7: dtbo 'bone_eqep1-00A0.dtbo' loaded; overlay id #1

$ lsmod |grep eqep

tieqep                  8758  0 

Looks like the driver is failing here

    // Get a handle to the system clock object

    clk = devm_clk_get(&pdev->dev, "fck");

    if (IS_ERR(clk)) {

        dev_err(&pdev->dev, "failed to get clock\n");

        return PTR_ERR(clk);

    }

This patch looks interesting. Maybe the same issue?

https://patchwork.kernel.org/patch/9005611/

Brian

[William Hermans]

Mark,

I wonder if loading a slightly older "bone" kernel would do the trick ? I did however read somewhere( possibly on this group ) no long ago that *some* board file overlays work for some peripherals, and not for others.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/711a3486-9ec0-431d-9a0a-4d3915937a8e%40googlegroups.com.

[Hugh Frater]

Did you ever get any further with this? I'm struggling with eQEP on 4.4.36 - but for different reasons

Hugh

[Drew Fustini]

On Fri, Feb 3, 2017 at 6:02 AM, Hugh Frater <hugh....@gmail.com> wrote:
> Did you ever get any further with this? I'm struggling with eQEP on 4.4.36 -
> but for different reasons

Are you getting an error?

I am able to use eQEP ok with a rotary encoder on 4.4 kernel:

# uname -a
Linux beaglebone 4.4.44-ti-r85 #1 SMP Fri Jan 27 22:16:52

# config-pin p8.11 qep
# config-pin p8.12 qep

# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
-2
<turn the rotary encoder>
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
18

Here are results with 4.1, 4.4 and 4.9:
https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673


-drew

[woody...@yahoo.com]

--------------------------------------------
On Fri, 2/3/17, Drew Fustini <pdp7...@gmail.com> wrote:

Subject: Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41
To: "Beagle Board" <beagl...@googlegroups.com>
Date: Friday, February 3, 2017, 11:18 PM

--
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/CAEf4M_CgQ-B0qmtLa1XtNSLcnyvY0ewK47vC%3DCt%2Bejndna91sQ%40mail.gmail.com.

For
more options, visit https://groups.google.com/d/optout.

i in celelaltare provincii romanesti aflate sub opresiunea straina au avut mari adunari plebiscitare. La 20 mai 1848 la Cernauti in prezenta unor prezentanti de frunte ai clerului boierimii si fruntasilor taranimii dupa izbateri sustinute au fost adoptate 12 dorinte intre care la loc de frunte se Iau separarea Bucovinei de Galitia conservarea nationalitatii romane si earea de scoli nationale autonomia provinciala defiintarea clacii si a dijmei isfacerea de Mitropolia Ortodoxa de la Karlowitz si alegerea episcopului de atre un Congres bisericesc alcatuit din clerici si mireni. La 15 27 iunie 1848 la jgoj in Banat sub presedintia lui Eftimie Murgu o Adunare de 12 000 de ameni a decretat intre altele respectarea nationalitatii romanesti oficializarea nbii romane inarmarea poporului dupa putinta in rastimp de 6 zile cu sfensive iar dupa ce se va arma de catre stat atunci sa paseasca ofensive .

[Hugh Frater]

I was getting weird values - it turns out I didn't correctly understand how to use pin-config & the universal overlay. When I configured the pins correctly, everything works.

[Drew Fustini]

Thanks for following up.

I've been using the tieqep module to read absolute position count of a rotary encoder knob.  I'm curious what other use cases people have for eQEP?

The reason I ask is I think a new driver needs to be written and it would be good to know which features of the eQEP peripheral should be implemented.

The existing tieqep driver is out of tree and seems unlikely to be included in the mainline Linux kernel.  We are able to use it on BeagleBone because Robert includes it as a patch in his kernel builds.

The IIO subsystem now has infrastructure for encoders.  I am thinking that an IIO driver should be written for eQEP with the goal of being merged into the mainline kernel.

Thoughts?

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1276f9da-9966-4171-a03c-4915d94e8e6b%40googlegroups.com.

[William Hermans]

On Sat, Feb 25, 2017 at 11:23 AM, Drew Fustini <pdp7...@gmail.com> wrote:

Thanks for following up.

I've been using the tieqep module to read absolute position count of a rotary encoder knob.  I'm curious what other use cases people have for eQEP?

I'm not sure I would have an out of the ordinary use for eqep personally.

The reason I ask is I think a new driver needs to be written and it would be good to know which features of the eQEP peripheral should be implemented.

Why do you think a new driver needs to be written ?

The existing tieqep driver is out of tree and seems unlikely to be included in the mainline Linux kernel.  We are able to use it on BeagleBone because Robert includes it as a patch in his kernel builds.

The IIO subsystem now has infrastructure for encoders.  I am thinking that an IIO driver should be written for eQEP with the goal of being merged into the mainline kernel.

Thoughts?

Thoughts . . .So personally, I really do not like anything IIO. I do not like the driver, I do not like the IIO "community support", and I think it's unnecessary for the ADC as it is. However, for simple ADC use cases, it's what we have, so I put up with it.

But if you're intent on having something IIO, and new driver . . . the ecap modules probably fits into that category better. The ecap module now, I could find all kinds of "out of the ordinary" uses for.

[Drew Fustini]

On Feb 25, 2017 5:35 PM, "William Hermans" <yyr...@gmail.com> wrote:
> Why do you think a new driver needs to be written ?

My desire is to get support for eQEP upstream in the mainline Linux kernel.  I don't believe it is easy to get new misc drivers merged.  IIO seems to be the only subsystem that is suitable but I'd be interested know of other subsystems that would be appropriate.

> But if you're intent on having something IIO, and new driver . . . the ecap modules probably fits into that category better. The ecap module now, I could find all kinds of "out of the ordinary" uses

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.

Thanks

Drew

[William Hermans]

On Tue, Feb 28, 2017 at 3:41 PM, Drew Fustini <pdp7...@gmail.com> 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*.

[gh7...@gmail.com]

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

==