Go Down

Topic: New LiquidCrystal library - LCD library (Read 26 times) previous topic - next topic

fm

If you look in the project's wiki you will see that the 2 wire SR version of the library is about 4,5 times faster than the stock parallel LiquidCrystal an almos 40 times faster than the I2C versio.
   

bperrybap

#121
Jan 07, 2013, 01:09 am Last Edit: Jan 07, 2013, 01:21 am by bperrybap Reason: 1

So, a final change to:-

Code: [Select]
LiquidCrystal_I2C lcd(0x27, 4, 5, 6, 0, 1, 2, 3, 7, NEGATIVE); // addr, EN, RW, RS, D4, D5, D6, D7, BacklightPin, POLARITY

Code: [Select]
 lcd.setBacklightPin(7, NEGATIVE);
 lcd.setBacklight(1);


And.....VOILA! Everything working as it should.

tack,
Cool. Yep on i2c, and the SR interfaces the constructor values are all output bit numbers.
Makes sense if you think about it.
Glad it worked. Your i2c board matches mjkdz i2c board that I have.

When using the newer constructors that specify the backlight pin/bit  and backlight polarity, there is no need for
the setBacklightPin(). The constructor sets up everything.
There really is no need to ever use setBacklightPin() if you use the full constructor that includes backlight information.
This is true for all the interfaces that support backlight control: 4bit, i2c, SR2W, SR3W
(SR does not support backlight control)

i.e for i2c, all you need is the constructor:
Code: [Select]
LiquidCrystal_I2C lcd(0x27, 4, 5, 6, 0, 1, 2, 3, 7, NEGATIVE); // addr, EN, RW, RS, D4, D5, D6, D7, BacklightPin, POLARITY

By default, duiring the initialization in begin(), the backlight will be turned on if you
set up the constructor with backlight information.
After begin() you can use the backlight functions.
To turn on/off the backlight:
Code: [Select]
lcd.backlight(); // turn on backlight with full brightness
lcd.noBacklight(); // turn off backlight


If you wan to use the setBacklight() function which is for dimming, then use:
Code: [Select]

lcd.setBacklight(brightnessvalue);
lcd.setBacklight(BACKLIGHT_ON); // full on
lcd.setBacklight(BACKLIGHT_OFF); // full off

A brighnessvalue of 1 will be full on for devices that don't support dimming or when an Arduino pin
that does not support dimming is used.
The reason to use BACKLIGHT_ON vs 1 to turn on the backlight is that you want to write
your lcd code to be portable across other interfaces that support PWM dimming.
Using a value of 1 will create a very dim backlight when pwm dimming is supported,
whereas BACKLIGHT_ON will be full brightness on all devices/interfaces.

--- bill




bperrybap


If you look in the project's wiki you will see that the 2 wire SR version of the library is about 4,5 times faster than the stock parallel LiquidCrystal an almos 40 times faster than the I2C versio.

Just don't try to convince GrumpyMike.... ;)

Tack,
GrumpyMike argued and argued that the display update rate to the LCD was in no
way impacted by the interface used to talk to it. He flatly didn't believe
our transfer numbers and update rates vs 4bit and i2c.
And then for costs, he said i2c was just as effective and the
same cost as using a shift register.
I showed him how you could build a HC595 based board for $1 USD QTY 1
ordering parts from tayda electronics (20 cent 595s and cheap strip boards) and to show me where I could
find 20 cent PCF8574s. He never replied....

To see the update rate, run the LCDiSpeed sketch I wrote.
It is included in the examples.
You will have to modify the i2c constructor for your i2c board.


--- bill

fm

#123
Jan 07, 2013, 01:29 am Last Edit: Jan 07, 2013, 01:32 am by fm Reason: 1
I still have to fine tune the 4bit version of the library to use fastIOs. Just a few micro seconds gain to reach the limit of the LCD.

Quote
Just don't try to convince GrumpyMike...


Simple facts, numbers are normally fairly objective. You could argue as much as you like but those figures talk for them selfs.
   

tack


tack,
Cool. Yep on i2c, and the SR interfaces the constructor values are all output bit numbers.
Makes sense if you think about it.
Glad it worked. Your i2c board matches mjkdz i2c board that I have.

When using the newer constructors that specify the backlight pin/bit  and backlight polarity, there is no need for
the setBacklightPin(). The constructor sets up everything.

Yes, it does make perfect sense now. It was just frustrating trying to work it out. LOL.

As for the SR vs I2C issue, the cheapest I've managed to find 8674 SMD is about $0.65, wheras a 100 595N cost me $12.00 or $0.12 each. To me, in the UK, that works out about 40p cheaper per board. I also need fewer headers (for my flexible setting address, backlight via I2C/Pin(PWM) and Contrast via Trimmer/Pin(PWM). That all adds up to maybe more than halve the build cost against using 8574 for I2C.


If you look in the project's wiki you will see that the 2 wire SR version of the library is about 4,5 times faster than the stock parallel LiquidCrystal an almos 40 times faster than the I2C versio.

Wow, that's some difference. I actually expected it to be slower for some reason. No real basis for that though, other than I guess some intuition that a cheaper method using generic SR would be slower than a specific implementation like I2C, or a parallel interface using a lot more pins.

I'll definitely give that a try at some point as I have plenty of 595N's coming. I think I'll be off to design a new 2W SR based backpack. ;-)

I guess the only difference is with controlling multiple LCD's. With 2W SR would I need another 2 pins for a an LCD displaying different data?

How does the library handle daisy chained SR? Does it, or would it be possible, to support multiple LCD's by writing 16, 24, 32 bits across multiple SR to display the same or different data on each? I'm thinking of this from the way ShiftPWM works. If you actually have 2 SR connected, but specify only 1 then the data gets repeated on the second.

Maybe the SR constructor could include a NUM_SR data to effectively specify how many LCD's. I suppose you'd need some kind of reference to each one for lcd.write() etc, such as lcd1.write, lcd2.write like you would if declaring multiple constructors normally.

Go Up