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
On Thursday, May 22, 2014 7:43:01 PM UTC-5, Teknoman117 wrote:
>
> 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
>
>
> On Thu, May 22, 2014 at 4:11 AM, Jason Kridner
> <[email protected]<javascript:>
> > wrote:
>
>> On Wed, May 14, 2014 at 4:59 AM, Teknoman117
>> <[email protected]<javascript:>
>> > wrote:
>>
>>> I don't believe that actually will change the I/O configuration. For
>>> the pin ctrl entry to be adopted, it needs to be used by some driver.
>>> Turns out there is a "pinmux helper" device. Check out this blog post:
>>> http://hipstercircuits.com/enable-serialuarttty-on-beaglebone-black/.
>>> More specifically, this section:
>>>
>>> fragment@2 {
>>> target = <&ocp>;
>>>
>>>
>>> __overlay__ {
>>> test_helper: helper {
>>>
>>>
>>> compatible = "bone-pinmux-helper";
>>>
>>>
>>> pinctrl-names = "default";
>>>
>>>
>>> pinctrl-0 = <&pinctrl_uart5>;
>>>
>>>
>>> status = "okay";
>>>
>>>
>>> };
>>> };
>>> };
>>>
>>>
>>> - Nathaniel
>>>
>>
>> With cape-universal, I believe our new path is to include stuff like this
>> in https://github.com/cdsteinkuehler/beaglebone-universal-io. In that
>> case, you could simply do something like:
>> root@beaglebone:~# config-pin P8.16 qep
>> root@beaglebone:~# config-pin -q P8.16
>> P8_16 Mode: qep
>> root@beaglebone:~# cat /sys/devices/ocp.3/P8_16_pinmux.24/state
>> qep
>>
>> However, with HDMI enabled, I'm not able to find a valid set of pins to
>> put together an entire eQEP. Further, the entries for an eqep don't seem to
>> be in cape-universal. There has been some discussion if they are necessary,
>> but I haven't been able to expose an eqep as of yet. I'll disable HDMI and
>> reboot next, but can those with experience comment on if something like
>> this is necessary:
>>
>> https://github.com/jadonk/beaglebone-universal-io/commit/5394b3e3813913e2b05253a1f06dbdb9f09341b5
>>
>> diff --git a/cape-universal-00A0.dts b/cape-universal-00A0.dts
>> index ad5b388..bc6c005 100755
>> --- a/cape-universal-00A0.dts
>> +++ b/cape-universal-00A0.dts
>> @@ -602,7 +602,7 @@
>> P9_27_gpio_pd_pin: pinmux_P9_27_gpio_pd_pin {
>> pinctrl-single,pins = <0x1a4 0x27>; }; /* Mode 7,
>> Pull-Down, RxActive */
>> P9_27_qep_pin: pinmux_P9_27_qep_pin {
>> - pinctrl-single,pins = <0x1a4 0x21>; }; /* Mode 1,
>> Pull-Down, RxActive */
>> + pinctrl-single,pins = <0x1a4 0x31>; }; /* Mode 1,
>> Pull-Up, RxActive */
>> P9_27_pruout_pin: pinmux_P9_27_pruout_pin {
>> pinctrl-single,pins = <0x1a4 0x25>; }; /* Mode 5,
>> Pull-Down, RxActive */
>> P9_27_pruin_pin: pinmux_P9_27_pruin_pin {
>> @@ -752,7 +752,7 @@
>> P9_92_gpio_pd_pin: pinmux_P9_92_gpio_pd_pin {
>> pinctrl-single,pins = <0x1a0 0x27>; }; /* Mode 7,
>> Pull-Down, RxActive */
>> P9_92_qep_pin: pinmux_P9_92_qep_pin {
>> - pinctrl-single,pins = <0x1a0 0x21>; }; /* Mode 1,
>> Pull-Down, RxActive */
>> + pinctrl-single,pins = <0x1a0 0x31>; }; /* Mode 1,
>> Pull-Up, RxActive */
>> P9_92_pruout_pin: pinmux_P9_92_pruout_pin {
>> pinctrl-single,pins = <0x1a0 0x25>; }; /* Mode 5,
>> Pull-Down, RxActive */
>> P9_92_pruin_pin: pinmux_P9_92_pruin_pin {
>> @@ -1727,4 +1727,24 @@
>> };
>> };
>>
>> +
>> + /************************/
>> + /* eQEP */
>> + /************************/
>> +
>> + fragment@41 {
>> + target = <&eqep0>;
>> + __overlay__ {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <>;
>> +
>> + count_mode = <0>; /* 0 - Quadrature mode, normal 90 phase
>> offset cha & chb. 1 - Direction mode. cha input = clock, chb input =
>> direction */
>> + swap_inputs = <0>; /* Are channel A and channel B swapped? (0 -
>> no, 1 - yes) */
>> + invert_qa = <1>; /* Should we invert the channel A input? */
>> + invert_qb = <1>; /* Should we invert the channel B input? I
>> invert these because my encoder outputs drive transistors that pull down the
>> pins */
>> + invert_qi = <0>; /* Should we invert the index input? */
>> + invert_qs = <0>; /* Should we invert the strobe input? */
>> + };
>> + };
>> };
>>
>>
>>
>>>
>>>
>>> On Tuesday, May 13, 2014 1:55:00 AM UTC-7, Strawson wrote:
>>>>
>>>> Actually, let me be more specific. I use the pinmux lines and enable
>>>> the PWM Subsystem as follows
>>>>
>>>> fragment@0 {
>>>>
>>>> target = <&am33xx_pinmux>;
>>>>
>>>> __overlay__ {
>>>> pinctrl_eqep0: pinctrl_eqep0_pins {
>>>>
>>>> pinctrl-single,pins = <
>>>>
>>>> 0x1A8 0x21 /* P9_41 = GPIO3_20 = EQEP0_index,
>>>> MODE1 */
>>>>
>>>> 0x1AC 0x21 /* P9_25 = GPIO3_21 = EQEP0_strobe,
>>>> MODE1 */
>>>>
>>>> 0x1A0 0x31 /* P9_42 = GPIO3_18 = EQEP0A_in, MODE1
>>>> */
>>>>
>>>> 0x1A4 0x31 /* P9_27 = GPIO3_19 = EQEP0B_in, MODE1
>>>> */
>>>>
>>>> >;
>>>> };
>>>>
>>>> };
>>>> };
>>>>
>>>>
>>>> fragment@1 {
>>>>
>>>> target = <&epwmss0>;
>>>>
>>>> __overlay__ {
>>>> status = "okay";
>>>>
>>>> };
>>>> };
>>>>
>>>>
>>>> I am not using the following fragment passing parameters to the kernel
>>>> driver
>>>>
>>>> fragment@2 {
>>>>
>>>> target = <&eqep0>;
>>>>
>>>> __overlay__ {
>>>> pinctrl-names = "default";
>>>>
>>>> pinctrl-0 = <&pinctrl_eqep0>;
>>>>
>>>>
>>>> count_mode = <0>; /* 0 - Quadrature mode, normal 90 phase
>>>> offset cha & chb. 1 - Direction mode. cha input = clock, chb input =
>>>> direction */
>>>>
>>>> swap_inputs = <0>; /* Are channel A and channel B swapped? (0
>>>> - no, 1 - yes) */
>>>>
>>>> invert_qa = <1>; /* Should we invert the channel A input? */
>>>>
>>>> invert_qb = <1>; /* Should we invert the channel B input? I
>>>> invert these because my encoder outputs drive transistors that pull down
>>>> the pins */
>>>>
>>>> invert_qi = <0>; /* Should we invert the index input? */
>>>>
>>>> invert_qs = <0>; /* Should we invert the strobe input? */
>>>>
>>>>
>>>> status = "okay";
>>>>
>>>> };
>>>> };
>>>>
>>>>
>>>> This is for two reasons. Firstly, I don't see how this would change the
>>>> behavior of the hardware if I'm setting the registers anyway. Secondly, it
>>>> fails to load because eqep is not a part of the
>>>> default am335x-boneblack.dtb located in /boot/uboot/dtbo in debian
>>>>
>>>> When trying to load this, dmesg returns
>>>>
>>>> [ 523.086537] bone-capemgr bone_capemgr.9: slot #10: dtbo
>>>> 'bone_eqep0-00A0.dtbo' loaded; converting to live tree
>>>> [ 523.090030] of_resolve: Could not find symbol 'eqep0'
>>>> [ 523.095581] bone-capemgr bone_capemgr.9: slot #10: Failed to resolve
>>>> tree
>>>>
>>>>
>>>>
>>>> In Angstrom, this file was located in /boot/am335x-boneblack.dtb.
>>>> Attached is a modified version of this that was provided by TI and results
>>>> in the eqep dts loading correctly in angstrom. This file has since changed
>>>> in the Debian release and the fix no longer works. As stated in the first
>>>> post in this thread, it would be nice if the correct eqep entries and your
>>>> driver were included in the public image so that this functionality can be
>>>> used out of the box like pwm.
>>>>
>>>>
>>>> On Monday, May 12, 2014 11:53:08 PM UTC-7, Strawson wrote:
>>>>>
>>>>> Hi Nathaniel. The correct device tree fragments are loaded, pins are
>>>>> multiplexed correctly, and all 3 eqep channels work perfectly with your
>>>>> driver. The supplied mmap code from my last post also works perfectly,
>>>>> but
>>>>> only if I insmod the compiled .ko kernel module first. Strange, I know.
>>>>>
>>>>> On Monday, May 12, 2014 11:41:14 PM UTC-7, Teknoman117 wrote:
>>>>>>
>>>>>> I'll certainly take a look at this next week. Currently in the
>>>>>> middle of finals and Maker Faire is this weekend. And in all honesty,
>>>>>> once
>>>>>> i figure out whats going on with the driver, its still a good idea to
>>>>>> use
>>>>>> the kernel based implementation, mainly because you can take advantage
>>>>>> of
>>>>>> hardware interrupts and not have to busy wait. I know there are sleep
>>>>>> methods, but unless something like Xenomai is being used, you're at the
>>>>>> mercy of the scheduler...
>>>>>>
>>>>>> Although, just to rule it out - are you still applying a device tree
>>>>>> overlay? The supplied DTS files do more than just initialize the
>>>>>> driver,
>>>>>> they setup the IO configuration, as the default board config doesn't
>>>>>> bring
>>>>>> out the eQEP lines.
>>>>>>
>>>>>> - Nathaniel Lewis
>>>>>>
>>>>>> On Saturday, May 10, 2014 12:25:14 AM UTC-7, Strawson wrote:
>>>>>>>
>>>>>>> I believe it is enabled. From my last post: the PWMSS clock config
>>>>>>> returns
>>>>>>> CLKCONFIG 0x111 = 000100010001
>>>>>>>
>>>>>>> According to pg 1492 of the reference manual, PWMSS_EQEP_EN is bit
>>>>>>> 4 in this register which appears to be true. Furthermore the interrupt
>>>>>>> timer register QUTMR
>>>>>>> is incrementing away just fine. Good idea, but no dice.
>>>>>>>
>>>>>>> For good measure I will write this bit anyway, but with |= instead
>>>>>>> of = since some bits are not writable and I wouldn't want to erase the
>>>>>>> enable bits for pwm and ecap.
>>>>>>>
>>>>>>>
>>>>>>> On Friday, May 9, 2014 11:33:23 PM UTC-7, James Zapico wrote:
>>>>>>>>
>>>>>>>> Strawson,
>>>>>>>>
>>>>>>>> It looks like you're not turning the PWM EQEP clock on. There
>>>>>>>> should be something to accomplish what this line from the kernel
>>>>>>>> driver
>>>>>>>> does:
>>>>>>>>
>>>>>>>> // Enable the clock to the eQEP unit
>>>>>>>> status =
>>>>>>>> pwmss_submodule_state_change(pdev->dev.parent,PWMSS_EQEPCLK_EN
>>>>>>>> );
>>>>>>>>
>>>>>>>> I haven't tried this out, but it should be something like
>>>>>>>> *(unsigned long*)(pwm_map_base[0]+PWMSS_CLKCONFIG) =PWMSS_EQEPCLK_EN
>>>>>>>> ;
>>>>>>>>
>>>>>>>> -
>>>>>>>> James
>>>>>>>>
>>>>>>>> On Friday, May 9, 2014 9:25:33 PM UTC-5, Strawson wrote:
>>>>>>>>>
>>>>>>>>> it seems my excitement was short-lived. While reading the position
>>>>>>>>> with the previous (and attached) code does work, it only does so when
>>>>>>>>> Teknoman's eqep driver is loaded. I've added writes to set up the
>>>>>>>>> PWMSS and
>>>>>>>>> eQEP configuration registers and have confirmed by reading them back
>>>>>>>>> that
>>>>>>>>> they are set up the same as the driver does. Any ideas on what I'm
>>>>>>>>> missing?
>>>>>>>>>
>>>>>>>>> // Write the decoder control settings
>>>>>>>>> *(unsigned short*)(pwm_map_base[0]+EQEP_OFFSET+QDECCTL) = 0;
>>>>>>>>> // set maximum position to two's compliment of -1, aka UINT_MAX
>>>>>>>>> *(unsigned long*)(pwm_map_base[0]+EQEP_OFFSET+QPOSMAX)=-1;
>>>>>>>>> // Enable interrupt
>>>>>>>>> *(uint16_t*)(pwm_map_base[0]+EQEP_OFFSET+QEINT) = UTOF;
>>>>>>>>> // set unit period register
>>>>>>>>> *(unsigned long*)(pwm_map_base[0]+EQEP_OFFSET+QUPRD)=0x5F5E100;
>>>>>>>>> // enable counter in control register
>>>>>>>>> *(unsigned short*)(pwm_map_base[0]+EQEP_OFFSET+QEPCTL) =
>>>>>>>>> PHEN|IEL0|SWI|UTE|QCLM;
>>>>>>>>>
>>>>>>>>> SYSCONFIG 0xC
>>>>>>>>> CLKCONFIG 0x111
>>>>>>>>> QEPCTL0 0x9E
>>>>>>>>> QDECCTL0 0x0
>>>>>>>>> QEINT0 0x800
>>>>>>>>> QUPRD0 0x5F5E100
>>>>>>>>> QPOSMAX0 0xFFFFFFFF
>>>>>>>>> QEPSTS0 0xA0
>>>>>>>>> eqep0: -174 eqep1: 544 e^Cp2: 0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>> 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] <javascript:>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> 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] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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.
