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

[kugel.]

Does this bolster the LCD driver as the culprit?

Possibly. If the Fuze uses the same code, without problems, it really seems to be some lcd driver issue.

[bertrik]

I enabled battery charging on the sansa clip today. The ams sansas use the same charge controller as the v1 sansas, so it wasn't actually that hard to add it. I didn't enable charging for other ams sansas yet, because each player probably needs its own settings (max. charge current and voltage), but it should be relatively easy to add once we have sufficient information.

What is needed for other ams sansa targets is the following:
* max charge current, this can be determined by measuring the current through the USB cable while it is charging in the OF (and the battery is still less than half full).
* max charge voltage, this can be determined by looking at the battery voltage in the battery debug menu, just after the OF has fully charged the battery.
* battery capacity, this can probably be determined by looking at the battery itself (there's probably already pictures of it in the wiki), from sandisk specifications or from the battery manufacturer.

[FlynDice]

e280v2  Read off of battery label

P/N: 54-57-00046
3.7V
750mAh

[saratoga]

e280v2  Read off of battery label

P/N: 54-57-00046
3.7V
750mAh

Thats the same battery as used in the V1.

I didn't enable charging for other ams sansas yet, because each player probably needs its own settings (max. charge current and voltage), but it should be relatively easy to add once we have sufficient information.

The fuze uses another ATL battery, but the exact model appears to be custom.  All ATL batteries are 0.5C recommended for charging, but I'm not sure what the capacity is.  Based on volume, its about 600mAh, so maybe 150 mA would be safe until we find out the exact capacity.

[bertrik]

I updated the SansaCharging page on the wiki with a table that summarises the battery properties / charge settings of the various sansa targets. Please update this as you find out new information.

I forgot one other thing: the battery voltage can be read back through several ADC channels, but some are more useful than others, for example on the c200 the true battery voltage cannot be read back at all (way too high), same problem on e200 but we can read the RTCSUP ADC channel there. So please experiment a bit with this too to find the most representative ADC channel for the battery voltage.

[kugel.]

Some news on the Fuze's Home button (very related to the recent e200v2 button findings).

The Home button is detectable on DBOP_DIN bit 15, but only if the higher bits in DBOP_DOUT are set.

This means, if the background color/backdrop needs to have at least 128/16 bits (RGB888/RGB565) red color values.
The other thing: GPIOB depends on the background color too.

Setting DBOP_DOUT before reading messes up the display, so this is not an option. We have to find a away to set the bits in DBOP_DOUT without affecting the display. We should also investigate how GPIOB is involved (IIUC it shares wires with DBOP).

[FlynDice]

Buttons & scrollwheel working great on e200v2 svn now.  Thank you Domonoky!!

ogg playback works fine as long as I leave the wps screen.  If I just stay at wps the music stops after 2-10 secs.  it will restart if I press the play button twice and then stop again unless I leave wps.  MP3 still reboots.

[kugel.]

Buttons & scrollwheel working great on e200v2 svn now.  Thank you Domonoky!!

This wasn't possible without your findings about the background color. Thanks a lot for that! It'll also enable the Home button on the Fuze.

May I ask a question? Is the wheel jumpy or unreliable? I've noticed that no post to the button queue is skipped. That causes problems on my Fuze (jumpy wheel, randomly changes direction, wrapping lists (or rather not wrapping if wheel is turned more quickly) not working at all).

edit: Just saw the "if (++wheel_click_count < 2)" line, that seems to be the skipping I talked about. I guess it's fine then.

[Chesteta]

On my e200v2 the wheel seems to move very smoothly; it does seem a bit slow; (like i'd like it to accelerate faster if i spin it fast instead of going what seems to be about a constant speed) but that probably can be changed in rockbox settings...

EDIT: also i should note, mp3's play back from the microsd chip (8gb) does work, if you touch the wheel or buttons things stop after ~10 sec.; when first playing an mp3 off the microsd chip, when the back light fades out, the audio does stutter a bit too.  I also noticed that the wheel light seems to 'chirp' on and off as the microsd chip is accessed (I set it to be off by default).  I can try to be more descriptive about the wheel light stuttering if anyone feels it could help

EDIT2: the hold button does not work; it can be on hold and the player will still turn on even...

[sko]

Buttons working fine on my e200v2 now, but I can confirm I can turn the player on even if the HOLD-switch is set to hold.
Mp3-playback isn´t working at all, rockbox just freezes (my mp3 files have at least 192 kBits).
Ogg works with 128 kBits with staying in the wps and with 160 kBits if I leave the wps, with 256 kBits playback stops after 3 or 4 seconds.
But IIRC & IIUC this depends on the mmu (I read something about in the IRC-Log here). May I ask if there are any news about the mmu?

EDIT: forgot to write: wheel is working fine!

[kugel.]

Can some e200 guy try this patch? http://pastie.org/392981

It takes a few parts from the Fuze LCD driver, to unify them a bit. Should not change behavior, but make the code more readable.

[sko]

I'm compiling right now, but I can say that r20040 is not working, the bootloader is loading the firmware but it's hanging before the mainmenu appears.

EDIT: Same with your patch, no mainmenu.

EDIT2: r20042 is good, buttons and wheel are working again.

[FlynDice]

debug-as3525.c line 37    #if defined(SANSA_FUZE) && defined(SANSA_E200V2)

supposed to be || ?

[Hillshum]

I have no clue. But IRC might be the better place to ask...

[sko]

I think "||" is right too, because with it the DBOP-value is shown in the view IO ports menu (see svn log for r20042). With "&&" it isn't visible there (can't be, imho two targets can't be defined).