GLCD Fun

[bperrybap]

Spent the past few days "gluing" a cheap GLCD ($8.95) to a BBB board.
I thought about a text only 44780 but thought why not go all the way with a GLCD instead.
Took quite a bit of effort to straighten out the GLCD low level s/w.
None of the existing ks0107/ks0108 GLCD or even 44780 text LCD s/w examples/libraries
I found were properly written for setting/clearing, and strobing bits without disturbing other
bits in data registers.
This is super critical if you want to use the remaining i/o pins in interrupts.
Its even more important on processors like the m168 and m328p as you can't get the 8 needed data bits
in a single register, like most implementations assume.
Plus GLCDs are so pin intensive that there are only 4 i/o pins are left over.
So my code allows any GLCD line to be configurable for any pin on any port.
In some cases this is even faster than the 4 bit mode that was trying to be "smart" in some libraries.
Anyway, enough of the rant, the picture below demonstrates how easy it is to prototype with
the Modern device boards, which is why I picked them over other alternatives.

All that was needed besides the obvious breadboard, was:

• 20 wires

• 1 resistor

• 1 potentiometer

When using the BBB and BUB board, no additional power or components is needed.
The PC still has full 2 way communication with the BBB as well.
Can you imagine the mess of wires with the other "*duino" type boards?

--- bill

[floresta]

It's too neat. It can't possibly work. It must be a fraud.
Where can I get one?

Don

[bperrybap]

What makes it so neat/simple electrically is that of the 20 connections to the GLCD, 14 of them can
be passed straight through to the BBB board.

The actual GLCD I bought locally here in Dallas at a surplus shop called Tanner Electronics.
http://www.tannerelectronics.com/

But they are also available on line from BG Micro (which is also local to Dallas)
http://www.bgmicro.com/index.asp?PageAc ... odID=10816

One word of caution, this GLCD does not have the same pin-out as many of the other GLCDs
I've seen. In fact I've seen 3 different pinouts so far and unfortunately they are so incompatible
that if you get the wrong one, it is highly likely you blow it up as the power lines are swapped
around between them.

The BG micro GLCD data sheet is available from their web site, and is what I used for this project
so I can vouch for its correctness.


--- bill

[floresta]

bperrybap:

My display arrived today from BGMicro. Can you share some code to get me started or do I have to figure it out by myself? I generally program in AVR assembly (on a BBB) but any other assembly language or even C would help.

Don

[oz]

bperrybap,

This totally rocks. How did I miss this for four days.
I'm ordering my display right now.

You're absolutely correct about ease of use two - your breadboard is amazingly tidy.

Paul

[bperrybap]

I exchanged a few PMs with Don off line and I deciced that to make it easy for anyone
wanting to duplicate this and have a nice GLCD to use for text or graphics,
I'll post all the code which includes a demonstration program, with a schematic,
along with some additional photos of my h/w setup.
I need a day or so to clean it up to make the code "plug-n-play" and easy and obvious
to modify for different configurations.

The majority of the code is based on code from this project:
http://sourceforge.net/projects/avr-glcd-ks0107/

I re-wrote all the low level read/write/command/status routines
to allow any GLCD line to be assigned to any MCU port and pin.
The existing code assumes all data bits are on a single port.
Also there were a few issues around reset and some low level timing issues
that had to be corrected.
But all the high level text character generation and graphics code worked as is.
(Well there was a line wrapping issue in text mode that I corrected)
I've also added an inverse text mode that can be turned on/off on a per character
basis.

Also, since this GLCD is ks0107/0108 compatible, the altered code and
schematic in this project should work with other ks0107/0108 GLCD modules.
Although some GLCD modules have slightly different pinouts, other than
the critical power pins (most notbaly 1&2 and 19&20) everything else an be
swapped around by simply altering the s/w configuration in a header file.

I should get all the information up in a day or so.

Paul, if you want a few better/larger/clearer photos of this for use on your site, PM me.
Or by the time you get your GLCD in, I should have the code posted, so you'll be able to run
the demo program and create the image shown on your own h/w.

The included sample/demo program will show how to do a variety of text and graphics as
well has hook up printf() or fprintf() to use the text mode.

BTW: I found another GLCD (120x32) that can be hooked up to the BBB board with ZERO wires!
It uses a different command/data interface on only 16 pins and
has the contrast pot on the LCD module.
It can be mated directly the BBB pins. However, if you mate it this way, you will lose
serial capability as those pins would be used to control the GLCD.

--- bill

[floresta]

Well it's not as neat as Bill's and I am still cleaning up the code, but here is what I have so far.

Don

[bperrybap]

Don, That's Very Cool.
One thing I did differently was to skip over the Tx/Rx (D0 & D1) to allow use of the serial port concurrently
with the GLCD.
That's why I had to have 2 wires going over to the analog pins. The analog pins are for DI and RESET.
All the other pins were run straight across.
The unfortunate side effect of freeing up the TX & RX pins is that now the data bits span AVR ports,
which slows down the code by having to do SBI/CBI instructions for every single bit.
The pinout that Atmel picked for the 168/328 sucks in this respect. With all those i/o pins,
it is sad that you can't get 8 bits in a single port *and* use the UART.


I'm wrapping up the C source code package and it should be ready to post soon.
I ran into several graphic and graphic font bugs in the original code from Sami's sourceforge package
that have taken a while to track down and fix.
Things like if you send a graphic character string using a variable width font using
the LCD_gputchar() and LCD_gputstr() routines and a character runs
over the edge of the right of the LCD, the code will accidentally alter the display start line ram address
rather than wrapping, which causes the right hand side of the LCD to have its data skewed.
(I've fixed this so it wraps if the full character won't fit)

--- bill

[floresta]

Bill:
I had a lot of fun tinkering with this display. I'm glad you got me started on it.

That's why I had to have 2 wires going over to the analog pins

Since I'm not using the serial port I used D0 and D1 for data bits. I did initially use two of the analog pins to drive my debugging LEDs which are in the photo. The jumpers that I made to fit on my male analog pins are out of sight to the right.

slows down the code by having to do SBI/CBI instructions for every single bit

For flexibility I have decided not to try to keep the data bits on a single port any more. I just write my code to set the bits individually using SBI/CBI all the time. For the worst case it takes 6 clock cycles to set up a bit, or 48 clock cycles for the entire byte - a whopping 3 microseconds.

the code will accidentally alter the display start line ram address

I ran into this a few times as well but never tracked down exactly how the display start line was being altered.

I've fixed this so it wraps if the full character won't fit

I tinkered with this for a while and decided that it wasn't worth the effort at this time since I don't intend to display long strings of random text such as data coming in on the serial port. To do this right you not only have to deal with characters that don't fit on a line but also with suppressing leading spaces after the line wraps and with not splitting words in the middle of a syllable. Maybe I'll tackle this later when there's no grass to mow but before I have to start plowing snow.

Don

[bperrybap]

slows down the code by having to do SBI/CBI instructions for every single bit

For flexibility I have decided not to try to keep the data bits on a single port any more. I just write my code to set the bits individually using SBI/CBI all the time. For the worst case it takes 6 clock cycles to set up a bit, or 48 clock cycles for the entire byte - a whopping 3 microseconds.

That's what I do as well.
It turns out that in several cases the extra cycles can be used to satisfy the E strobe timing and other setup delays.
So the code can be structured to take advantaged the extra cycles rather than having to insert busy waits so that in
some cases, the extra cycles don't actually cost any additional time.

the code will accidentally alter the display start line ram address

I ran into this a few times as well but never tracked down exactly how the display start line was being altered.

What I saw was that Sami's original code was incrementing a software variable (LCD_currentX) which keeps track of
and "shadows" the LCD's hardware x position.
During writing graphic proportional character glyph strings, there was no check to see if the column was getting too large and because
the software location value was simply OR'd in with the command value for the SET_ADDRESS command to
create the command byte to set the X location during glyph painting.
Once the value gets too large, a SET_ADDRESS command will turn into a SET_DISPLAY_START_LINE command.
A quick and dirty "fix" to prevent accidental sending of SET_DISPLAY_START_LINE is to AND off bits 6 & 7 of the column data.
Deepening on how the other low level code is written, wrapping the text may not be as easy as simply ANDing off the upper bits.
This will keep the display from getting shifted but it may end up wrapping to the left side of the right LCD area rather than all the way to
to the left side of the LCD.


For simplicity, I opted to alter the graphic code to wrap the glyph/character to the left side of the screen and 1 line lower whenever
the full glyph won't fit. And if there is no room for the character to be lower, it wraps to the upper left hand
location of the LCD. (x=0, y=0). It was a pretty simple change.

--- bill

[floresta]

Bill:

a SET_ADDRESS command will turn into a SET_DISPLAY_START_LINE command

That certainly explains it. It appears that these graphical LCDs have inherited much of the instruction set structure from the character LCDs. I wonder why they didn't stick with the old technique for identifying the specific instruction?

Don

[oz]

Great work on this Don & Bill,

I received my display last week - too bad I can't order up some time to try it out. I sure hope a library comes out of this work, as Don mentioned, so others can get up going without the effort this must have taken to get going.

Thanks again for posting the photos here.

Paul

[floresta]

Paul:

too bad I can't order up some time to try it out

That was my problem when I was teaching this stuff. I thought that early retirement would be the solution but it just got worse. It was more than ten years after I retired that I finally was able to find enough time to do some recreational programming.

Don

[bperrybap]

Guys,
I haven't forgotten about this. Much work has been done
and good things are happening.
I am working with Michael Margolis on an arduino glcd library.
He already had one: http://www.arduino.cc/playground/Code/GLCDks0108
I have enhanced it by updating the low level h/w access routines
to make it faster. The big change is some code I wrote that does multi-bit i/o to
make it much easier to configure. The old version had limitations as how pins
had to be hooked up. Using the new multi-bit i/o routines, all those limitations are gone
and any pin can be used for any glcd function.

Today I added support for SED1520 based modules.

Here is discussion forum about the glcd library:
http://www.arduino.cc/cgi-bin/yabb2/YaB ... 427907/0#0

An update to this glcd library should be forthcoming in the near future.

Attached below is an image from earlier today where I was just bringing up
a VK5121 module running Micheal's test sketch using the not-yet available arduino GLCD library.
If you look carefully, you will see my ks0108 GLCD on the left part of the photo.
That single breadboard has 3 projects on it. A ks0108 project, a vk5121 project, and
in the upper right corner a pwm project with a raw ATtiny85.
Again, this is why I love the BBB.

NOTE: the arduino glcd library code is based on a totally different original code base.
The code I had running in a non arduino environment was based on Sami Varjo's glcd code.
The code base that Micheal started with was based on Maximilian Thiele's glcd code.
While the two provide similar functionality, they are very different in certain areas.

At some point in the future I'll be releasing an updated version of Sami's non arduino
code on his SourceForge project.

So good things have been and are still going on.

--- bill

[bperrybap]

Ok, so things drug out way longer than expected.
But a Beta version of a new Arduino GLCD library is available.
See this arduino thread for details: http://www.arduino.cc/cgi-bin/yabb2/YaB ... 279128237/

A tremendous amount of work and effort was put in to add new features, make it easy to configure pins as well
as make the library very fast while still allowing it to run on small memory AVR chips.
A few highlights:
- You can configure any i/o pin to be any GLCD pin function and use either Arduino pin#s or direct AVR chip pin/port designations.
- One very new capability is text areas. You can define any portion (including multiple areas) of the physical display to be a scrollable text area with a user
specified font.
- There is quite a bit of documentation included in the package including a PDF file and extensive HTML documentation.
- A java based tool for creating bitmap header files from your own bitmap artwork files.
- The HTML documentation has pointers to a java based font creation tool that can convert fonts to library header files.
Also in the HTML documentation are links to sites to download literally thousands of fonts
that can be converted for library use with the java based font creation tool.

All these capabilities work on m168 chips as well regardless of the GLCD geometry size as great pains were taken to not
use any sort of frame buffer.

NOTE: while the BBB is not not necessarily supported "out of the box", it will work if the BBB is wired up
as is recommended for the standard Arduino board
That said, in many cases (like what I showed in the initial post), it is easier/better to wire things up differently.
The configuration files in the library make it very easy to modify which pins control which GLCD functions.
See the library documentation for details on which files to modify.

Enjoy.
Please post any feedback over on the Arduino forum thread mentioned above.

--- bill

[bperrybap]

Just a final followup.
Here is the link to the arduino glcd library:
http://code.google.com/p/glcd-arduino/

--- bill

[RomanceOsborn]

I thought that early retirement would be the solution but it just got worse.
ดาวน์โหลด royal1688

[steve smith]

Hello everyone
Thanks for share your informations here.thanks admin and all moderators.
best regards
steve smith