Rockbox Development > New Ports

SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

<< < (360/386) > >>

bilditup1:
The 'auto-reboot to OF on USB' feature from 26116 is really cool. Kudos to funman et al for working on this, and to AMS for being considerate. I wonder though, funman - did you ask them for other datasheets as well, or was this the most important one? What's the upshot of getting these sheets from an audio perspective?

funman:
Well I only asked for this one (yesterday), I wouldn't know what else I could ask for.

As for audio, I don't know, audio works pretty well already.

It seems even line out works, but we need to detect dock plugging (tenfoot is working on it)

csavery:
funman: I'm still seeing scrollwheel lock up in r26114. I have an idea what it is but I'm not familiar with the code so I'm pretty much just poking in the dark and just putting this out there as a question.

In button-fuzev2.c there is the change as of r26060,

long v = (time - last_wheel_post);
    if (v < WHEEL_LOOP_INTERVAL) /* avoid too frequent updates */
        return ;

I see v is defined as long and not unsigned long. According to my calcs with timer freq of 1.5 MHz this will wrap into a negative number in about 23 minutes. This is round about the time taken for the scroll wheel to lock up. So I had the idea that if the scroll wheel doesn't move for 23 minutes and no event is posted then the time delta would be negative and cause this function to return without processing the event for another 23 minutes until it wraps positive again. Is this possible?

In my tests it takes approx this much time to freeze and only with no wheel activity. Unfortunately due to how long you have to wait it's rather slow to test.

ssorgatem:
I've observed the scrollwheel freeze too, after leaving the fuze some minutes inactive (they may well hace been more than 23 minutes)

funman:
csavery: it looks possible, i have seen the wheel stop working and work again when testing charging.

I didn't measure the time elapsed but it might have been multiples of 23 minutes.

Instead of counting the number of timer ticks I think we should just count rockbox ticks separately because they overflow in much longer time (248 days with HZ=100).

If you have a patch can you post it on flyspray?

thanks!


If you use a current build with Clip+ it will try to reboot to OF on USB plug, but with current mkamsboot it will fail and power off the Clip+
So you should:

* Not plug USB
* Keep center button pressed when plugging USB
* Reinstall the bootloader (the last bootloader will work) with a mkamsboot build from SVN or wait for a new mkamsboot release.
I'm not sure if we will make a mkamsboot release soon because there is some good progress on USB support in rockbox on all the models (AMSv1 & v2), perhaps we should just wait for the drivers to work.

What is the opinion of the other devs on this?

Navigation

[0] Message Index

[#] Next page

[*] Previous page