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.

Reply via email to