Complete with example code and library
The library is not finished yet,
so report anything you'd like to see added,
and any tips are welcome!
Hope it's useful,
Yes I will take a look at it
I've been in contact with here, but that was just regarding the code,
But i'll have a look that the hardware,
looks nice small and snug
this will do able with the ic's I use, because they also available in smd.
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.
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
...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.
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.
No,
I tested it with the Hitachi HD44780,
And works,
don't worry the library is still in early stage's
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.
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.
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.
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
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.
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
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.
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.