next topic »

[Reply #225 on:]

These are the connections i did:


Pin 1...5V
Pin2...GND
Pin3...cent pot
Pin4...D8
Pin5...D9
Pin6...D10
Pin7...D11
Pin8...D4
Pin9...D5
Pin10..D6
Pin11..D7
Pin12..A0
Pin13..A1
Pin14..5V
Pin15..A2
Pin16..A3
Pin17..A4
Pin18.. pot
Pin19..5V
Pin20..resistor to gnd

[Reply #226 on:]

Unfortunately, i tried to take a photo about the wiring but it is not clear since there are too many wires.

Do you have a macro mode on your camera? (most cameras have it)
You will need to use that to get a clear close up image.
I'd really like to see the solder joints on the glcd the other end of the wires as well.
Take it from the back of the board where the wires are soldered since that is most interesting thing to see.
There shouldn't be any wires in the way on that side.

I'm using a perfboards, so all the wire are soldered.

Wait, earlier you said you were using an Uno Rev 3.
Are you now using an embedded design on a perfboard with your own circuit?

Please show a photo of you full setup. All boards/wires/components involved.
You have not yet shown this.

However, i tried to connect and re-connect the display to my arduino several times and all the time connections are ok but there are strange characters on the display.

Not sure what you mean by this.
Do you mean that you are using different boards or you are disconnecting everything and reconnecting it?

The most important thing is that when I run the diagnostic sketch, I'm able to see the triangle which is under all the strange characters and the black pixel lines.

Note sure what you mean by this.

As you can see in the previous photos, sometimes the correct characters are in background since strange characters and black lines are foreground.

Actually I see the correct characters every time. What I see is that certain pixels within the character are missing and there are some
stray pixels showing up. This kind of effect can be caused by incorrect wiring, broken wires, wires not making proper connections,
or wires shorted to adjacent wires.
It could also be caused by a bad glcd or a burned up or malfunctioning Arduino pin.
But almost always it is due to incorrect/improper wiring.

In looking closer at your images it looks like glcd data bit 2 is not working correctly.
That is glcd module pin 6 which is connected to arduino digital pin 11.
That wire seems to be either broken, not soldered correctly, or perhaps shorted to glcd data bit 1 or data bit 3.
Look very closely at that wire to make sure it is not shorted to a wire next to it and re-solder its connections.

Do you have a logic probe?
This could be used to test the Arduino pins to verify that the arduino pins are working.
In particular arduino digital pin 11.

--- bill

[Reply #227 on:]

I tried searching the forum and didn't quite find anything.

glcd takes up a tonne of pins, and I'd like to move all the data pins onto a demultiplexer. Now there are 4 pins instead of 8.

I can understand that this could incur a bit of a performance penalty, but I'm not trying to make a game here, just an unnecessarily large menu system

So I wanted to see if I could just modify the library and make it work.

I came across this write8bits function in avrio.h, was wondering if that's used specifically for the 8 data ports on the glcd?

If not, perhaps I could get some info of where to look to change the way those data ports are used?

thanks

[Reply #228 on:]

avrio is at the very lowest level. That is not the point that would be modified.
The upper layer routines in gText and glcd call routines in glcd_Device
It is the glcd_Device class that talks across the h/w interface using functions
like ReadData() and WriteData(), SetDot(), SetPixels(), etc...
Even those functions don't call avrio routines directly.
They use wrapper macros defined in glcd_io.h to hide the low level i/o and to deal with
with the control line mappings in the panel configuration files.

To change the h/w interface, you need to slice it at either the glcd_Device layer
or replace the glcd_io macros.

I'd recommend altering the glcd_io macros to match what ever hardware
you are looking at implementing.

From a hardware perspective the biggest challenge if trying to multiplex pins is
how to deal with the bi-directional needs. i.e. the data has to read as well as written.
You can turn on the GLCD_READ_CACHE option which will eliminate the data reads
at the expense of using up SRAM, but that doesn't completely solve the need for reads
in that the code will still need read access to the BUSY status which requires
reading data bit 7.


--- bill

[Reply #229 on:]

avrio is at the very lowest level. That is not the point that would be modified.
The upper layer routines in gText and glcd call routines in glcd_Device
It is the glcd_Device class that talks across the h/w interface using functions
like ReadData() and WriteData(), SetDot(), SetPixels(), etc...
Even those functions don't call avrio routines directly.
They use wrapper macros defined in glcd_io.h to hide the low level i/o and to deal with
with the control line mappings in the panel configuration files.

To change the h/w interface, you need to slice it at either the glcd_Device layer
or replace the glcd_io macros.

I'd recommend altering the glcd_io macros to match what ever hardware
you are looking at implementing.

From a hardware perspective the biggest challenge if trying to multiplex pins is
how to deal with the bi-directional needs. i.e. the data has to read as well as written.
You can turn on the GLCD_READ_CACHE option which will eliminate the data reads
at the expense of using up SRAM, but that doesn't completely solve the need for reads
in that the code will still need read access to the BUSY status which requires
reading data bit 7.

Thanks for the input.

I did not think about reading. Ultimately I need 3 pins for the shift register to arduino I suppose.

Perhaps I can reduce CS1/CS2/RW/RS/E/RST down to 3 and leave the 8 data pins alone? Not as big saving, 6 to 3 as opposed to 8 to 3, but still better than nothing? Means glcd would need 12 pins.

I'm guessing a Uno is not fast enough to do this serially?

[Reply #230 on:]

I need to create a device with a LCD text display where I can highlight in some fashion strings of characters. By highlight I mean either underscore an entire string or invert black/white foreground/background of multiple characters. As best I can tell none of the text only LCDs available about me to do that. The cursor is only a single character so I cannot underline an entire word or sentence. And I've not found any of them that allow me to invert the text foreground/background.

So it looks like I'm going to have to use a graphics display and handle all of that myself (which I'm not looking forward to).

Before I go to the trouble of buying a display, wiring it without an i2c (again not looking forward to that) can someone please verify for me that the GLCD will let me to display text easily with some of the words inverted?

And although this may not be the place to ask, does anyone know of a text display that will do what I want so that I don't have to go the route of a graphics display?

[Reply #231 on:]

So it looks like I'm going to have to use a graphics display and handle all of that myself (which I'm not looking forward to).

It is not difficult to have reverse text with the glcd library.

Before I go to the trouble of buying a display, wiring it without an i2c (again not looking forward to that) can someone please verify for me that the GLCD will let me to display text easily with some of the words inverted?

Yes the glcd library can do this. It is quite easy to invert text. you simply set inverse mode and then start printing to the display again.
Set normal and you are back to normal.
Here are some examples I found on YouTube that use this capability:
Some menu code:

The diags I ship with the library:

(in the diags video look at the display at around 10 seconds)

And although this may not be the place to ask, does anyone know of a text display that will do what I want so that I don't have to go the route of a graphics display?

hd44780 type displays can't do this. They can turn on a cursor. They can set the cursor type, they can move/pan the text left/right
but they can't underline or invert the text.
For menus on text displays you can use brackets to "higlight" the text. ie

Code:

[this is hightlighted]
 this is not

--- bill

[Reply #232 on:]

Thanks for confirming my speculations. And also for the [highlighting] idea. I have created some menus which just used a -> arrow character or a custom bit pattern that looked like a pointer but for multiple word options on a 16x2 display it wasn't very useful. I should've thought of brackets or parentheses or something especially since I'm going to be using a 20x4 which gives me a little more room to play with. I think I'm going to stick with text displays for now, get things running well, and then think about making an upgraded version using graphics. Maybe by that time someone will come up with a really easy to use graphic shield with a build in i2c to cut down on the overhead.

[Reply #233 on:]

I did not think about reading. Ultimately I need 3 pins for the shift register to arduino I suppose.

Perhaps I can reduce CS1/CS2/RW/RS/E/RST down to 3 and leave the 8 data pins alone? Not as big saving, 6 to 3 as opposed to 8 to 3, but still better than nothing? Means glcd would need 12 pins.

I'm guessing a Uno is not fast enough to do this serially?

"fast" is a relative term. There is no minimum speed that things need to happen on a ks0108 type interface.
You could take days to set the pins and latch a byte, the display would not care.
The interface timing is based on a minimum amount of time that must pass before something can change or be done.
i.e. you must not do anything in a period of time shorter than a certain amount.
For example if you want to send a byte you set up the control lines then you are supposed to wait 140ns before you present
the data. That 140ns is a MINIMUM not a maximum. So you can take longer.
All the timing is based on minimum delays.

There are ways to interface the module to the library using less pins. I've thought quite a bit.
I know a few ways of how to do it and have thought about creating a low cost backpack.
There is even a way to control a shift register with only 1 pin vs having to use 3 pins.
I have a LCD backpack design for a hd44780 character lcd that does this as fast as the stock Arduino 4 bit parallel mode.

The real challenge for a glcd backpack from product standpoint is that there are so many different pinouts.
While 2 pinouts are by far the most popular, I've seen over 11 different ones for the ks0108.

Technically, the biggest challenge is how to deal with reading the glcd memory and not gobbling
up so much memory, because memory is so limited on the m168/m328 arduinos.
Its not hard, but having to turn the data bus around costs extra components or is VERY slow in the case
of something like i2c as i2c is quite slow particularly at the standard 100kHz bit rate.

It comes down to 3 things
- time/speed
- AVR memory
- component costs

You can't optimize all 3 at the same time.
(The current model with 13 pins is when all 3 are optimized)

--- bill

[Reply #234 on:]

Having never used a graphics display (only text so far) is it necessary for the normal day-to-day use of a graphics LCD to be able to read back the data? I know many times on text displays in order to simplify things we just tie the RW pin to ground and only write. If I'm not writing some sort of game with sprites and I'm just using it to draw graphs or or display text and bitmaps do I ever need to read from a graphics display?

Thinking about this in terms of simplifying the wiring.

[Reply #235 on:]

Having never used a graphics display (only text so far) is it necessary for the normal day-to-day use of a graphics LCD to be able to read back the data? I know many times on text displays in order to simplify things we just tie the RW pin to ground and only write. If I'm not writing some sort of game with sprites and I'm just using it to draw graphs or or display text and bitmaps do I ever need to read from a graphics display?

Thinking about this in terms of simplifying the wiring.

It is very necessary for the current glcd library.
Two reasons:
- BUSY status
- preserving previous pixel data

In order to know when the glcd is ready to process another command or data operation,
the library monitors the BUSY status. The BUSY status is presented
on bit 7 of the data bus. This requires controlling the r/w line and flipping the data bus connections to the AVR around
from write to read.
The library could have blind delays instead of monitoring BUSY like most of the LiquidCrystal type
type libraries, but currently it monitors BUSY to get maximum speed out of the display.

With respect to the actual data,
the difference with a glcd is that things are at a pixel level, but the interface to the graphic ram is at a byte (sometimes 16 bit word) level.
The displays are very dumb. They only have a "write data" command vs a "or data", "xor data", or "set/clear data"
Because of this if you want to modify a single pixel you have to know the contents of the other pixels in the
glcd's memory byte/word "page" because when your write
to the display you are stomping on all the pixels in the page at once.

Now if you are modifying all 8 pixels in the page, then no read is necessary but often that is not the case.
For example, drawing a line of a single pixel width. In this case only a single pixel in the page is being modified.
The same is true if you are rendering a character that is not exactly the same size as the page size in pixels or
not being rendered on a page boundary.
For example, consider a 5x7 font on a ks0108.
The font uses 8 pixels in height (7 of data plus 1 inter character pixel below)
and the page size on a ks0108 is 8 pixels tall.
As long as the character is on a modulo 8 pixel boundary, then all pixels in the glcd page
can be stomped on with the 8 pixel font data.
However, if the character is not being rendered on a 8 pixel boundary say y pixel coordinate 5, then you must read the glcd data
to preserver the pixels above and below the rendered pixels of the character because the rendered
character is spanning two glcd pages.
In the example above 2 pixels of the font would go
in bits 6 & 7 of the upper page at y pixel coordinate 0 and 6 bits would go in bits 0-5 of the lower page at y pixel coordinate 8.
Bits/pixels 0-5 of the upper page and bits/pixels 6 & 7 of the lower page must be preserved.
In order to do that, the data has to be read from somewhere.
It can either be read from a local cache or from the glcd directly.
By default the glcd library reads the data from the glcd to save ram use.

--- bill

[Reply #236 on:]

Excellent explanation. I didn't realize you had to write chunks of pixels at a time and not individually address pixels. Of course using the library you're insulated from that and it looks like you're writing individual pixels. I just didn't realize that the hardware level you're not. That's what a good library should do. Isolate you from the technical details and just let you do what you want to do seamlessly (pun intended)

[Reply #237 on:]

I have a problem that I haven't seen solved anywhere. I'm using the standard ks0108 GLDC that goes with the library. I have had success in connecting all the wires properly and actively displaying information to 2 different microcontrollers (mega and uno). The problem is that a few seconds to a minute after the display loads, the left half or entire screen crashes/goes blank. As far I can tell, the GLCD is just not displaying data. The controller still functions as the debug works and it can still read and write data to other components, but the display just doesn't want to continue displaying data.

This happens on both controllers and to different degrees on all the example programs. Is this something in which the only solution is to buy another GLCD? As far as I can tell it's the only common thing, but maybe I'm missing something.

[Reply #238 on:]

kryptopro,
Interesting....
So are you saying that you are running the diag sketch included with the glcd v3 library
and after a while it is still running and passing all tests (showing that diags pass on the serial port)
but the glcd display is not showing the proper information?

Sometimes flakiness or intermittent failures can be due to improper connections.
By "improper" I don't mean incorrect. I mean wires/connectors not making full contact.
This can be due to a bad solder joint on one of the 20 pins in the glcd module, or wires that
have been twisted together instead of soldered, or wires that are not quite making full contact inside the Arduino
female header socket.
Wires that are too long can also cause issues. There is no set rule for this. The shorter the wires the better,
but if the wires are over say 18 inches that is getting to be a bit too long.

Another issue could be power. What is powering the Arduino and glcd?

Describe your setup a bit more and if possible post a few clear closeup photos of your solder connections
to the glcd module and maybe a few others of your setup.

--- bill

[Reply #239 on:]

Yes, the diag sketch runs completely through on the serial port, everything passes, but the display usually crashes about at the "Full Vertical Page Test". I don't know if the diag sketch resets the board completely when it repeats, but whenever it does loop back to runs the tests again, the display works for a while again. Symtoms repeat.

The first photo shows what is happening on a partial failure. The sketch that is running is 'BigNums'. The right side is still running, but the left side has just gone blank.

The next two show the setup. Uno R3 is powered by usb and 12v dc through the outlet. Wires are directly from the uno to the breadboard and no data wires are greater than 6". All the power on the breadboard is powered by the 5v out on the uno. The power and ground on the GLCD pins were measured to be 4.99v. Improper connections? Maybe, but the problem persists across different controllers and with different wire combinations.

Last photo is of the headers soldered to the GLCD.