Rockbox

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?

Warning: Undefined array key "useheading" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 1099 Warning: Undefined array key "target" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557 Warning: Trying to access array offset on value of type null in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557

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)
{

  if (!timer2_pwm_on) {
      do_scrollwheel();         /* Handle scrollwheel and tick tasks */
      TIMER2_INTCLR = 0;  /* clear interrupt */
      return;
  }

  timer2_pwm_state ^= 1;
  if (timer2_pwm_state) {
      TIMER2_BGLOAD = timer2_cycles_pwmon;
      _backlight_pwm(1);
  } else {
      TIMER2_BGLOAD = timer2_cycles_pwmoff;
      _backlight_pwm(0);
      do_scrollwheel();  /* Handle scrollwheel and tick tasks */
  }

  TIMER2_INTCLR = 0;  /* clear interrupt */

}

patch without the ‘weird’ switch usage.

19:51 < kugel> ranmachan: IMO, unless you write a generic driver that can be

             used by other (non-samsa) targets, the #define shouldn't be in 
             the <target>.h file. that's usually for optional stuff that 
             works on more on a single (or related range of) target(s)

#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.