This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9570 - Sansa e200v1: Increased runtime by ~20%
Attached to Project:
Rockbox
Opened by Toni (ahellmann) - Saturday, 22 November 2008, 16:11 GMT+2
Last edited by Andree Buschmann (Buschel) - Friday, 26 December 2008, 16:44 GMT+2
Opened by Toni (ahellmann) - Saturday, 22 November 2008, 16:11 GMT+2
Last edited by Andree Buschmann (Buschel) - Friday, 26 December 2008, 16:44 GMT+2
|
DetailsThis patch improves the runtime on flash based players with PP5022 and PP5024 (Sansa e200v1/c200v1) per battery cycle by about 20%. The average current at MP3 playback decreases from 34mA to 28mA. This could be achieved by powering off the SD controller when not needed and switching off the PLL at 30MHz. Only tested on Sansa E200v1 with no negative side effects.
|
This task depends upon
Closed by Andree Buschmann (Buschel)
Friday, 26 December 2008, 16:44 GMT+2
Reason for closing: Accepted
Additional comments about closing: First part (SD) committed with r19194. Second part (clocking) must be combined with a kind of gui boost to keep gui fast enough.
Friday, 26 December 2008, 16:44 GMT+2
Reason for closing: Accepted
Additional comments about closing: First part (SD) committed with r19194. Second part (clocking) must be combined with a kind of gui boost to keep gui fast enough.
I will look into this tonight on my Sansa, but one question: Buschel played around with the PLL at 24 and 30MHz clock speed, and reported no improvement (though he tested via battery bench and not with a meter). I see you've basically enabled his old code. Did your tests show a difference? If so, how much?
Also, since you were interested in SD card support, have you seen recently
FS#8663? We still have occasional file corruption when writing to the SD card in rockbox (either copying between volumes or when in rockbox USB mode).Regarding
FS#8663I have no idea. Is the remaining problem still the '2bytes inserted'? In one of my experiments I did move the USB buffers into IRAM (same as gevaerts did) and got no file corruption. I don't know, why he gave up with that idea.One question before I commit the PLL. The patch leaves the comment " /******** CPUFREQ_NORMAL = 24MHz without PLL ********/" in place, but I think that should be "30MHz without PLL" correct?
I don't remember the exact details but I believe the PLL is needed for clock speeds above some minimum value. Buschel or amiconn could probably give you a better answer.
1. The mp3-decoder nows runs @22MHz on PP502x, but the lowest unpatched clock is 30MHz. So, we are waisting 8MHz which equals ~2-2.5mA (3MHz = ~1mA).
2. This patch enables the path for 24MHz (including the disabled PLL). The coded added in this patch configures the PLL, but the PLL is not used (as the clock source is still set to 24MHz). Therefor the change results in running the clock @24Mhz.
This perfectly explains the savings of ~2mA.
So, the changes in system-pp502x.c can be reduced to use "#if 1" instead of "#if 0" to activate the 24MHz clock.