But setBacklight(dimvalue) isnt working properly on this hardware i thought. Value LOW turns off the backlight and value HIGH turns it on at highest brightness. Nothing happend by changing values 1-255, backlight is still at full brightness and potentiometer is changing just contrast of letters. The question is how can I modify backlight brightness ? Is it even possible on that hardware ?
It is working properly on that hardware.
As I said in the previous post:
setBacklight(dimvalue) was being misused as it takes a dimvalue and not a HIGH/LOW argument.
While it happens to work on this hardware, it would give a very dim backlight on other hardware
HIGH/LOW are invalid parameters for setbacklight(dimvalue);
And while using HIGH happens to turn on the backlight for this h/w because the h/w doesn't
support dimming, it would be very dim on other hardware that does support dimming.
More details below....
This was discussed in another thread (not surprisingly). It is not a hardware matter. The hardware switches it ON or OFF by sending commands to the port expander chip (PCF8574) via the I2C bus.
I'm assuming there is a typo above?
It is a hardware matter.
The hardware on the backpack is incapable of being told to do anything but turn on/off
a PCF8574 pin that turns on/off a transistor that turns on/off the backlight.
The hardware on the backpack does not have the capability to do PWM on the pin
to dim the backlight.
Any function in the current (or ever) libraries for "setBacklight(dimvalue)" refers only to direct connection of the display to Arduino ports such that the LED is switched by a PWM-capable port.
Remember it isn't just direct Arduino pins that can do dimming,
some backpacks like the ByVac ones can also do dimming.
In fm's library we made the decision to try to do the best we could for setBacklight(dimvalue);
given the available hardware as some hardware can do dimming and some can't.
What confuses things so greatly is that there are still many improper examples
out there that mis use the API functions.
There are several ways setBacklight(dimvalue) could
be handled/supported on non dimming h/w:
1) remove the function if it isn't fully functional - create an error in the sketch
2) leave it in but make it only set backlight on or off to get the attention of the user to change his code
3) "The arduino way", which does 0-127 is off, 128-255 is on
4) any non zero value is on
We opted for #4 as it would offer the most s/w compatibility across all the various hardware.
In other words the goal of the library is ensure that sketch code you write for one set of
LCD hardware will for the most part "just work" if moved to another another LCD hardware without
having to go in and change anything but the constructor. No changes to the
actual sketch code should be needed to change communication interfaces as that should
be handled by the constructor. i..e if you change from 4bit to i2c, just change the constructor.
So the thought was that if dimming isn't supported by the h/w then it should still work to turn
off the display with a value of 0, but then any other value will dim the best it can
and if the h/w can't dim, the best it can dim is obviously full on.
This ensures that code that trying to do dimming simply loses the dimming capability.
In other words, we assume that a request for a dimmer backlight is still wanting the backlight
to be on and does not want the backlight to be off if dimming can't be supported.
This is very different from the "Arduino way" in analogWrite(dimvalue); which sets
the LED off for dim values 0-127 then on for 128-255.
This method turns off the display for half the dim values.
Their thinking was to "round" the value so below half way is off, above half way is on.
It was our opinion that this is wrong and that is why we use 0 for off and any non zero value for on.
This same behavior is used on all the interfaces in fm's library not just i2c.
Remember that fm's library is for multiple interfaces not just i2c using a PCF8574 and it is trying
to provide a common API across all of them.
So for example, if you used the direct Arduino pin mode in 4bit mode, and if you picked
an Arduino pin that doesn't support pwm you end up with the same behavior as
you see the i2c PCF8574 backpacks, (0 off, any non zero is full on)
but if you picked a pwm Arduino pin, then full dimming would work.
And THAT is why I keep harping on users not to use setBacklight(HIGH); to turn on
the backlight, because if the hardware is changed to h/w that supports dimming,
then all your code using setBacklight(HIGH) would create a very dim
backlight and on reverse displays (dark with white pixels), it will usually appear
to be off.
For those that insist on using setBacklight(dimvalue) to turn the backlight on/off
rather than dimming the API must be used correctly to ensure it works properly
across all h/w interfaces:
setBacklight(BACKLIGHT_ON); // turn on backlight at full brightness
setBacklight(BACKLIGHT_OFF); // turn off backlight