James: Thanks. That works for me. Can this be included in the next debian release?
--Mark On Thursday, May 22, 2014 11:16:27 PM UTC-4, James Zapico wrote: > > 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]> >> wrote: >> >>> On Wed, May 14, 2014 at 4:59 AM, Teknoman117 <[email protected]> >>> 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]. >>>> 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. >>> >> >> -- 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.
