CP7 Backlight

Since the CP7 already uses an “I” socket… It would be awesome if you could add an I2C digital pot to the CP7 to allow for dimming / turning off the backlight. Maybe something like this…

This would allow for much better control over power consumption. At a minimum, it would be nice if there were pads somewhere to allow a pot to be added by the user.

If I’m a moron and this ability already exists somewhere and I’m not seeing it, please educate me.


couldn’t agree more - all backlights should be software controllable and include things like a transistor if necessary to be able to drive it with PWM.

I think this has been requested on every LCD ever, except FEZ Touch, because that had backlight control. :wink:

1 Like

I think this is already available. Someone will confirm back.

Socket G Pin 9 is the backlight control pin. So you can turn on/off or dim it through that pin.

1 Like

We will be adding this to the driver.



It is not pwm but if you are suing premium then use Signal Generator to software PWM. Some mainboards adds PWM on that pin as well so check.

So, is this question only regarding those that would not be using the CP7 with Gadgeteer? My assumption was that you would be adding something like

display_CP7.BacklightIntensity = 50;

If it’s going to be dependent on premium features, then does that mean the driver would not work with OSHW boards?

Driver can only do on and off by default.

So, if you have a premium board and you wanted to use Signal Generator to dim it then you would have to compile a custom driver? Yuck. :frowning:

We are getting too lazy with gadgeteer :slight_smile:

This is why Hyrda need premimum libs. Fastest Gadgeteer on the block and it can’t dim a backlight :frowning:

I think my tablet’s going to need a custom board just so it can access that pin with PWM.

@ Skewworks -

Gus is always busy in the GHI secret laboratory. Who knows what will be the fastest next month or the month after?

What we need is an RPLLite version of OutputCompare(). I started on it once but got frustrated with RLPLite and ran out of time before I made much progress. Any RLP experts out there want to take this on? Who would match my $50 for a reward?

Of course, even if we had a working RLPLite version of OutputCompare that wouldn’t solve the problem because there would still be a dependency issue. So, what we really need is a NETMF core level SignalGenerator. So, the question is how do create such a function in a way that it could be included in NETMF core?

1 Like

I’ll chip in, especially if it’s the latter!

More useful would be a driver for the hardware timers. Then, you’d get OutputCompare plus a giant list of other things, such as PWM in, encoder input, PinCapture (non-blocking), and other possibilities depending on the MCU in use. The advanced timers of the STM32 have lots of possibilities.

@ Gus - Any solution if I want to use CP7 with Chipworkx module.? Any extension board to support the I socket from Chipworkx Dev kit for example ? Or perhaps is it simply possible to use it from the same connectic as the existing 4.3’’ ?

Or finallty, I’m missing some other stuffs that explain it wont be a good idea…

You can use extender modules to wire it to Chipworkx. There are about 20 wires to run.