Support and General Use > User Interface and Voice

Iriver touchpad suggestion

<< < (2/2)

keenerd:

I've been studying DSP programming, I know optimization is hard stuff.  I've done less driver reverse engineering, and I know that's even harder.  Didn't mean to imply anything.  But so far everyone who has used my H10 has had to have the "scroll buttons" explained to them, despite have never used an iRiver dap before.  Its the very first thing a new user notices, and its a bit of a turn off.

Rockbox has access to the absolute scrollpad data, with a resolution of 0x400.  Accuracy is low (jitters by about 0x20) so some sort of moving average would be needed for scrolling.  Pressure appears to be a binary value.  That's all under the debug menu.

I'm going to presume that I am missing something, and I'm going the the SVN to figure out what it is.  Because the two-zone behavior matches a comparison to 0x200, but the "top of the pad goes down" implies there is no check against the pressure bit.  (Basically, values around 0x120 are generated at the very top of the pad, but only when the pressure is light and the pressure bit is false.)  

So a dead zone could be as simple as adding one more comparison.  I doubt it is, because it would have been done already.

H10 20Gb

keenerd:
Wow, was I wrong.  Its dirt easy to add the dead zone.

http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/iriver/h10/button-h10.c?view=log&pathrev=10943

--- Code: ---        /* Read scroller */
        if ( GPIOD_INPUT_VAL & 0x20 )
        {
            GPIOD_OUTPUT_VAL &=~ 0x40;
            udelay(50);
            data = adc_scan(ADC_SCROLLPAD);
            GPIOD_OUTPUT_VAL |= 0x40;
           
            if(data < 0x210)
            {
                btn |= BUTTON_SCROLL_DOWN;
            } else {
                btn |= BUTTON_SCROLL_UP;
            }
        }

--- End code ---

Good zone boundaries would probably be 150 and 250, so the middle 25% of the pad is non-responsive.

Oddly enough, the pressure bit is tested (0x20).  So I don't know why the "top of the pad goes down".  Guessing the signal is even more noisy than thought?

The above button code is fairly stateless and instantaneous.  De-noising and/or scrolling requires several samples over time, opposite of how the code is written, and I don't have the slightest clue where that should be implemented.  Really comes down to differentiating between taps, drags and holds.  With a drag-mode-flag, since hold-the-button and pause-the-drag look awfully similar.  Ugh.

keenerd:
Still working on the custom-build tool chain.  I am amused that all the instructions are for cygwin, but it isn't playing friendly with my Arch install.  Once that's sorted out, I guess I'll make a patch and look into getting SVN privileges.  

One thought on how a "simpler" scroller could be implemented:  the scrollpad sets repeat rate for button holds.  Near the center, slow repeat rate.  Near the top/bottom, fast repeat rate.  Linear transition from middle to edge.  Though repeat rate is already adjusted by acceleration, so it might be better to have the scrollpad set variable acceleration.

bluebrother:

--- Quote from: keenerd on February 10, 2007, 11:42:10 AM ---Still working on the custom-build tool chain.  I am amused that all the instructions are for cygwin, but it isn't playing friendly with my Arch install.
--- End quote ---
you can use the script tools/rockboxdev.sh to set up a tool chain. I built mine before the script was available, and it isn't hard at all. You might want to read the CrossCompiler page instead ...

Navigation

[0] Message Index

[*] Previous page