Need help creating Arduino library

[mojoe]

I have some 2x20 VFD that I need help with. I have figured out practically all of the control codes, but need someone who can write or modify an Arduino library, patterned after the standard LiquidCrystal library. For your help, I'll send you a couple of the displays. PM me if you are interested in helping.

[linux-works]

I can help, but this is already working, if its hd44780 style.

the trick is the addressing of the char locations.  the 2x16 and 4x20 are standard but other sizes use 'odd' offsets on where to write the chars, to get them to show up on the screen.

found some 40x2 or something large like that displays and they responded to hd44780 just fine; I had to hack a bit to find out where the data would show up on the screen, but it was not a lot of hard work.

[mojoe]

The displays I have are not HD44780 compatible. I had to figure out the commands. Unlike the LCD screens, there is no funny offset between the two lines. What you print on line one continues to line two.

[linux-works]

yes, that was it - long lines.  I had to write 'beyond' the end of one line to have it show up on the other line.  that was the trick.

so, are yours graphic and not char cell, then?

I have not spent any time on the non-hd44780 non-graphic displays.

fwiw, this is my new fave cheap color display, costing about $5 from china:

http://www.amazon.com/HiLetgo-Display-Module-128X160-Socket/dp/B00LSG51MM

how I'm using it right now:



its not super fast, but its got good arduino libr support already and I love having 'easy' color and graphics for simple low-cost projects.  its not oled, so it has no lifetime wear issues and uses simple hardware spi for interfacing, so its actually less pins than many other displays need.

if you really need help on the displays you have, though, I could try to help out if you want.  I have some time on my hands (I'm between jobs right now...) and I'm in the SF bay area.

[macboy]

yes, that was it - long lines.  I had to write 'beyond' the end of one line to have it show up on the other line.  that was the trick.

That is how nearly all HD44780 displays work, and how the controller was designed to work. Line 1 uses the first 40 chars of the 80 byte buffer, and line 2 uses the last 40 chars. The notable exception is the 20x4, where each line uses 20 chars. There are also some 8x2 displays that act like a 16x1 with wrap around... the reason is to avoid the added cost of a helper IC for the 2nd line. Finally there are 40x4 displays which have two HD44780 controllers and act as two 40x2 displays stacked; all pins paralleled except the separate EN (strobe) lines.

mojoe: I can probably help, I like hacking displays and I am an unashamed VFD fanboy. I think what you want is a new library with an API essentially identical to the LiquidCrystal one, so that it can be "dropped in" to existing projects using LiquidCrystal, right? That is very feasible, there is nothing truly HD44780-specific about the LiquidCrystal API, so the API could be used for any character display. PM me some details of what you have discovered.

[mojoe]

Macboy, I sent a few PM, but the forum doesn't show any Sent messages. Did you get them?

[mojoe]

It seems that the forum default is to NOT save your sent PM. Totally opposite what I expected.

[obiwanjacobi]

Why does it have to be the LiquidCrystal API?
The fact that a lot of people rewrote that thing into their own incarnations indicates that that way of doing it is no ideal...

BTW: Did you check out the gfx library (and their display drivers) from AdaFruit?

[macboy]

Why does it have to be the LiquidCrystal API?
The fact that a lot of people rewrote that thing into their own incarnations indicates that that way of doing it is no ideal...

BTW: Did you check out the gfx library (and their display drivers) from AdaFruit?

The code in LiquidCrystal is junk. For example, 100+ microsecond delay between sending two nibbles of a byte in 4-bit mode, this is unnecessary and really slows things down. I could go on and on. It's like they didn't read the datasheet. But the API (the list of callable functions) isn't bad, and there is no reason not to re-use that interface for other character displays, as it would help in portability. Little original code would remain.

mojoe: I did get your PMs.

[obiwanjacobi]

I would say the API is junk too.   

Anyway, whatever works for you...

Again: check out AdaFruit.