- Status Closed
- Percent Complete
- Task Type Patches
- Category LCD
-
Assigned To
Tobias Diedrich - Operating System Sansa c200
- Severity Low
- Priority Very Low
- Reported Version Release 3.4
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Rockbox
Opened by Tobias Diedrich - 2010-03-17
Last edited by Tobias Diedrich - 2010-03-23
Opened by Tobias Diedrich - 2010-03-17
Last edited by Tobias Diedrich - 2010-03-23
FS#11119 - Implement software pwm to control c200v2 display brightness
The original firmware uses software pwm to control display brightness.
Attached patch implements this on rockbox.
Closed by Tobias Diedrich
2010-03-23 09:07
Reason for closing: Accepted
Additional comments about closing:
2010-03-23 09:07
Reason for closing: Accepted
Additional comments about closing:
Committed.
The style of your code is quite a bit strange IMO, confusing to read.
Is there no other way to set the backlight brightness on your c200v2?
Which part is confusing?
AFAICS there’s no other way. They don’t use the current source that’s used in other models and the original firmware also does PWM (see http://forums.rockbox.org/index.php?topic=14064.msg163799#msg163799 “OF (c200-03.02.05) has fiq handler for backlight pwm at 0x3d38, which reads the model variable from 0x202e9 (at 0x3d48) and backlight toggling at 0x3d8c (on) and 0x3da0 (off).”).
Without my microoptimization do_sw_pwm should look like this:
static inline void do_sw_pwm(void)
{
}
patch without the ‘weird’ switch usage.
19:51 < kugel> ranmachan: IMO, unless you write a generic driver that can be
#ifdef HAVE_BACKLIGHT_SW_PWM replaced by #if defined(SANSA_C200V2)
Oops, I found that I had swapped the on/off time variables (In two places, so it _did_ the right thing, but :))
Fixed that.
Also, I thought a bit about it and changed it so that the ‘upper layer’ is always called during the longer cycle.
Otherwise in the very worst case the cpu would only have less than about 3000 cycles at 60MHz to execute all tick handlers.
This way it should always have about 15000000 cycles instead in the very worst case. ;)
Actually, I have thought about implementing buttonlight brightness with software pwm, should be easily doable with your work :)
I already have that working on my local tree.
However it doesn’t work reliably for the ‘other’ c200v2 buttunlight, since the on/off-function accesses SD_MCI_POWER, if you’d call that from interrupt context it would race against other accesses to that register. I tried it: It resulted in occasional random display freezes for some reason.. I haven’t looked at what SD_MCI_POWER actually is used for though. On my variant the main buttonlight is on A5, so it’s not an issue for me.