Project IOlcd, lcd controled through a IOexpander(in this case a MCP23016)

4 bit is no option for me :slight_smile:

duality:
4 bit is no option for me :slight_smile:

Why not?
For a hd44780 it is 4 less pins to hook up.
Using 4 bit mode allows the lcd to be controlled by a single 8 bit port
and still have 2 bits in the 8 bit port left over for things like backlight control.
(Just add a transistor)
It would allow the lcd to be controlled through 1 of the 8 bit ports on the 23016
(say GP0) and keep the full 8 bits of the other port (GP1) free for other uses.

4 bit mode would also allow using a smaller cheaper 8 bit i/o expander like the 23008 instead
of the dual port 23016.

--- bill

What I meant was,
that 4bit was not an option, since I had some timeing iseus and data getting lost, which I don't have anymore since I use 8Bit
more over yes I could build in a 4 bit option though :),
I'll work that out later, bussy making the library arduino1.0 compatible :slight_smile:

I'll work that out later, bussy making the library arduino1.0 compatible

While you are at it why don't you change the initialization sequence to comply with the steps specified by Hitachi?

Don

...since I had some timeing iseus and data getting lost

Probably because you are not following the requirements of the data sheet. You are using the same delay for all of the commands even though some of them require significantly more time than others. Also, you are not accounting for the fact that some LCDs may run slower than the nominal speed upon which the datasheet times are based. The 4-bit mode seems to be more sensitive to these discrepancies which could be why your 8-bit code appears to work.

Don

yes, i had these issue's before i even made the circuit,
had 4 bit issue's when hooked up to the arduino directly :slight_smile:

hey I thought i had made it like the datasheet lol, nope copied the initialization part from Liquid Crystal,
does that not work?

Beside's I had removed the delay and worked just fine, but didn't save the source,

Greetings,
Duality

hey I thought i had made it like the datasheet lol, nope copied the initialization part from Liquid Crystal,
does that not work?

You didn't copy it from any version of LiquidCrystal that I recall. Their current code isn't correct either, but it is closer to being correct than yours. Why don't you take a few minutes and follow the LCD Initialization link at http://web.alfredstate.edu/weimandn ?

Beside's I had removed the delay and worked just fine, ...

AARRGGHH. So it worked just fine on the particular display(s) that you tested it on and therefore you believe that it will work on all displays. Go back and take a look at the section called "About the Delays" at the end of the link posted above.

Don

No,
I tested it with the Hitachi HD44780,
And works,
don't worry the library is still in early stage's :slight_smile:
There is waay room for improvement,
and I appreciate your tips and help,
And i'll try to make the library more efficient and better.

Greetings,
Duality

I tested it with the Hitachi HD44780,
And works,

You tested it with one HD44780 and it works. How about all the other HD44780s that are out there?

Don

Why does it matter?
isn't it the same hardware?
Or is there something i am not seeing?

duality:
Why does it matter?

yes

isn't it the same hardware?

No

Or is there something i am not seeing?

Yes,

It is kind of like saying all cars in the US have a steering wheel
on the left and a foot pedal on the right of the foot pedals to control speed
and a brake to the left of that pedal to slow down.
You interface to them the same, but
Do they all accelerate and brake the same?
No.

Not all "hd44780" based modules are the same speed at processing commands
as they are not all using the design or the same chips.

--- bill

duality:
Why does it matter?
isn't it the same hardware?
Or is there something i am not seeing?

It matters if you want your software to be reliable.
It is 'similar' hardware. They attempt to make all of them the same but they are not all identical.
You are not accounting for the variations from one device to the next.

Don

Edit: Bill types faster than I do.

Good point, good point.
Thanks for the insight :slight_smile:

Hi all,
Here's a little update:

I've been busy writing stuff, and have recently started working on a 4Bit mode for my library!

Floresta, want to thank you for that link in your first post I believe.

I am currently working on a 4Bit mode, so that'll there soon, for now I am stuck on a blinking Cursor that just blinks.
I've realized that if you use a MCP23008 you still have 2 pins to spare when I am done.
Although I don't have have the MCP23008 right here now, I am fairly confident I can get one easily around here :slight_smile:
Which also means if your's using a 16Bit expander you save up to 10 pins!

I have notice that timing is more of an issue when working with 4Bit mode, and I am trying to follow the proper way to
initialize the lcd.

that's it,
Greetings,
Duality

This 4bit is not gonna happen! the mcp23016 is waay to slow, the mcp23017 however is quite a different story, it can be either controlled by spi or i2c
Just wanted to let you know :slight_smile:

Greetings,
Duality

Huh? Way too slow for what?
The speed of the interface used to get to the hd44780 interface
will not affect being able to control or update the LCD.
A slower interface speed will only lower the speed of the LCD updates.

I suggest you have a look at fm's latest LiquidCrystal replacement library.
https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home

If you scroll down on the wiki you will see the interface timing for each
of the interfaces supported on both AVRs, and pic32 processors.
In the table labeled "Benchark II" which is numbers provided by the LCDiSpeed sketch
that I wrote, you can see that a Shift Register (74HC595) using 3 wires can update a full 16x2 display
close to 500 times/sec, (around 400 times/sec in 2 wire mode)
while a pcf8574 i2c interface in 4 bit mode can update a full 16x2 display about 30 times/sec.

While I2c with a pcf8574 in 4 bit mode is more than 10x slower than using a shift register in 4 bit mode,
it is still very usable.

The library has a framework that allows you to quickly and easily drop in support for a new interface.
All the upper level command initialization is handled by a hd44780 LCD class that sits on top of the
minimal library interface class.
You could use the existing ic2 interface class which is for a pcf8574 as a guide for your mcp23008/mcp23016
to create a new interface class.

The interface classes are quite tiny as all they do is some initialization, push data/cmds to the interface
and handle a small bit of backlight control.
Everything else hd44780 related is handled by the generic LCD class.

--- bill

This 4bit is not gonna happen! the mcp23016 is waay to slow...

There is no interface on earth that is too slow for an LCD interface. You can do it with switches and dispense with the microprocessor altogether.

Don

Ok, didn't know that that is awesome :slight_smile:
than it must be a fault at my side, but what?
At the moment i am trying to get 4bit with a shiftRegister, and i am not using a library for the matter,
Looking if i can get it to work, and see what i did wrong or need to do in my library :slight_smile:

Thanks for the motivation guys!

Greetings,
Duality.

Update,

updated the library to work with 4x20 displays, and now I've tested my library with multiple LCD controllers,
and so far all of them worked :slight_smile:
going to try more displays though, In total I've tested 4 displays with different controllers,
two with the HJ602A controller,
one with the this: pc1602F - Google Search (PC1602F)
and one with this controller: st7063c-qg - Google Search (ST7063C)

I haven't been working on a 4 bit mode for a while, But I am going to give it a try soon though,
still got to look at the initialization it works, but can be approved upon for increased reliability.

Greetings,
Duality

http://tkkrlab.nl/wiki/Lcd_through_IOexpander