I'm not sure what you mean by that.I need to know what is visually showing up on the display.

1) So just to be clear, when the diag sketch is running it never indicates a failure after multiple passesbut at some point in one of the test passes the left side of the display turns off?

2) This is a 128x64 display correct?

3) Do you have a part number and datasheet for the glcd?(maybe a photo of the back of the module)

4) Have you made any changes to the library code or the configuration files from the stock distribution?

5) where are the 2 green wires from the power and ground rails going to? Are they powering anything?

6) Is anything connected to the glcd reset line?If it isn't connected to anything, try connecting it to VCC using a resistor.

7) does it get better if you disconnect all the non glcd wires?- disconnect the wires to A5, D2, D3, D12, D13- remove the two green wires from the lower power rails.- remove the wires from lower power rails to the upper rails.- hook the ground connection on the POT directly to the lower rail ground.If you have a .1uf cap can you add that to the bread board up by the glcd header pins for power and ground(usually glcd module pins 1 & 2)All this is to try to eliminate any noise or ground loop issues.

kryptopro

Update, NUM6 fixed the problem! Adding a 1kohm resistor seemed to fix all the problems. But I will still post a more detailed answer to the problem. Hopefully it will help others.

1) Yes. That is what happens. Here is a video of this occurring.

http://www.youtube.com/watch?v=4EbHU4AgEs0&feature=youtu.be

2) This is a 128x64 display3) The part num is GDM12864HLCM from SparkFun4) The library has not been altered for the Uno. However manual pins were set for the Mega as one of the ports on that controller was found to be bad.5) The two green wires go to a 10k potentiometer. Which is read by A5.6) There was nothing previously. CONNECTING THE RESET PIN TO VCC WITH A RESISTOR SOLVES THE ISSUES7) The number of wires attached does not effect the display performance. The test in 1) was done using the setup from 7).

But with respect to #1 is the diag sketch still reporting that all the tests passed onthe serial port even though the displayed turned off?

The reset line on these ks0108 glcds varies between modules.Some modules have pullups on them, some don't.Many seem to self reset when powered up. But some don't and requirean actual pulse on them to function properly.Ideally, it should be driven and it should be pulsed low to ensure the glcdis put into a consistent sane state prior to initialization.But that takes another AVR pin. On many glcds you can get away leaving the reset pin unconnected,but it is best to tie it high.

On some you have to actually pulse the reset.

I wrote about the different ways of hooking up the reset lineon the ks0108 playground page. So see the playground page for more informationabout how to handle the reset line and potential issues and work arounds.

My guess is that module you have is experiencing a spurious resetwhile the test is running because the reset signal input is not driven high.Many ks0108s don't enable the pixels after a reset so what you are seeingis probably a spurious reset because the reset input to glcd is floating.I'm guessing that the diags would report a failure when this happens and that is whyI'm curious to know if you see a reported failure on the serial port when the screen pixels turn off.

The reason the pixels turn back on with the diags is because each test iteration re-initializes the glcdand part of the initialization (it is actually the first thing done) is to turn on the pixels.

phreeky

I hope I'm not out of place putting this here, I did already post it in the Exhibition forum but figured it's much more likely to be spotted here.

I've created an online GLCD font generator. Technically it doesn't do the whole process, you have to submit a GIF with the text in it, however it's a ~6 step process in GIMP to create such a file and I've included basic instructions. Importantly, unlike the other tools I could find like the FontCreator on the google code site, this creates fixed width fonts.

FYI a friend first getting into Arduino and using GLCD was in need of some fixed width fonts so I threw this together. There is no ads or anything on the site. http://www.microintegrate.com/?/fontgen

Jance

Hi Bill. An engineer at my work gave me this 160X160 display that I'd like to play around with at home with my AVR chips. I'd like to get your feedback on whether its worth pursuing using the glcd-v3 library on this display for basic text and graphics. i.e. "Yeah, it's easy- just create a new glcd\device, but don't worry about that single CS pin.." or "..better to roll your own here...". XD

I'm reading up on gLCD info at the moment, but there are clues to me to indicate that the glcd-v3 lib may not work for this display. Digging in a little further after looking at the datasheets (comparing SED1520 vs SED1330F)...1) only 1 CS pin, where as the library suggests requiring 2 or even 3 CS pins. Not sure how this is used- perhaps memory banks? Maybe the SED1330F has enough memory so that it can reference the entire 160X160 space?2) Extensive graphic layers and memory descriptions on the 1330F i.e. 3 layered graphics on the SED1330F. Again, I'll be happy if I can just do basic functionality on it (initialize, clear, display text, draw some lines and such), but I'm unsure if the commands, memory, etc are compatible between the two.3) Inverted A0 levels between data and command. Not sure if this is "auto detected", or specified, or hard-coded in the glcd-v3 library.4) Different duty cycles (1/160 vs 1/16 or 1/32) [I'm unsure what this characteristic defines, or even how it relates to the library]5) The SED1330F pdf has 150 pages (granted, a few pages account for the TV version) where as the SED1520 only has 50 pages, suggesting the display was designed for different purposes (i.e. perhaps for involved graphics for the SED1330F vs perhaps a simplified\industrial standard\KS0108 compatibility for the SED 1520)

Again, I'd like to get your feedback on whether its worth pursuing using the glcd-v3 library on this display for basic text and graphics as I continue to read up on the specs for this display.

Andy,Had a quick look at the data sheet. Still looking at the graphicmemory layout but electrically it can easily be made to work with the glcd library.The module would be strapped for 6800 mode.This changes the /RD signal to be EThen strap CS to ground - shouldn't need to be disabled for this application.AO is the DI which is used by glcdDIAll the timing can be configured/adjusted in a glcd config file for the module.Specific device initialization can be handled by a glcd device specific file.

When using glcd on a more advanced module like this you will lose out on the more advancedcapabilities, because glcd treats the module as a dumb bitmapped display. However, all the glcdlibraries api capabilities should be available.

I'll need to confirm how the memory is addressed and the graphic layout to seeif it is compatible with the library.

Just had a closer look at the datasheet for the module.Looks like the SEL1 and SEL2 pins are not available on the 20 pin connector.(SEL1 being the important one)The question is what mode is it strapped for?Looking at the figure on page 12, it appears be set for 8080 mode.This complicates things as currently the glcd code and macros are not set upto allow configuring separate read & write pins.

I've been wanting to change the library to make it easier to integrate in new device supportjust haven't gotten around to it.It costs a bit of performance to do it, but it would make things much simpler particularly forsituations like this. It can be done with the existing methodology it just requires a high level ofunderstanding of the existing code to coexist with the other devices.

If you don't care about supporting the other display types it wouldn't be that difficult modify the glcd_Device.cppcode to support the module. I believe that it would be much simpler to do that vs rolling your own.

Also, before you step out too far, you may want to talk to Oliver and see if his u8glib library could be wiggledinto supporting this module: http://code.google.com/p/u8glib/u8glib has support for more displays than glcd.

I'll continue to look at it an try to get a feel for the amount of effort involved for the glcd library.

The controller has a very complicated setup sequence (section 3.2). I assume some of the settings depend on the connected hardware (LCD Panel, SRAM, Driver, etc), so without a proper init sequence from "Sunlike Display", it is difficult to setup the display module. Also "Sunlike Display" mentions the RA8835, which is also confusing to me.

Oliver

louis89

Hi, I am in a project of using glcd version 3 using sort of Sanguino board, however, using ATMEGA 16 and trying to fit the library according to Sanguino board ( ATMEGA 644 )and manual configuration of the pin assignment. The problem is when I try the Hello World thing it completely doesn't work and found out the #error 'ATMEGA 644 has not been tested' on arduino_io.h, is this chip really not available for the library or just my stupid mistake?

And also I've made changes to the font libraries line, the static uint8_t System5x7[] PROGMEM = {const uint8_t System5x7[] PROGMEM = {how does this affect?

Hi, I am in a project of using glcd version 3 using sort of Sanguino board, however, using ATMEGA 16 and trying to fit the library according to Sanguino board ( ATMEGA 644 )and manual configuration of the pin assignment. The problem is when I try the Hello World thing it completely doesn't work and found out the #error 'ATMEGA 644 has not been tested' on arduino_io.h, is this chip really not available for the library or just my stupid mistake?

And also I've made changes to the font libraries line, the static uint8_t System5x7[] PROGMEM = {const uint8_t System5x7[] PROGMEM = {how does this affect?

Many Thanks, Ivan

The error should be commented out. What that meant is that neither Michael or myself had tested that configurationon real hardware.Complicating things is that there are 4 different pin mappings for the 644/1284 processors."standard", "bobduino", "avr-developers", and "mighty-1284p"

I have a "todo" item to support all of them but right now only one is supported.(I can't remember which).

The key to getting it to work is to have the proper pin mapping macros in arduino_io.hand that depends on which core/variant you are using.

In file included from /home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/allFonts.h:11:0, from HelloWorld.cpp:18:/home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/SystemFont5x7.h:48:28: error: variable 'System5x7' must be const in order to be put into read-only section by means of '__attribute__((progmem))'In file included from /home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/allFonts.h:12:0, from HelloWorld.cpp:18:

Maybe related to the previos post, because i assume i have to add some "const" keywords.

Appears with Arduino 1.0 and 1.0.1, ubuntu, latest release. I have also avr-gcc on my system, i am not sure which gcc is used by Arduino IDE.

In file included from /home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/allFonts.h:11:0, from HelloWorld.cpp:18:/home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/SystemFont5x7.h:48:28: error: variable 'System5x7' must be const in order to be put into read-only section by means of '__attribute__((progmem))'In file included from /home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/allFonts.h:12:0, from HelloWorld.cpp:18:

Maybe related to the previos post, because i assume i have to add some "const" keywords.

Appears with Arduino 1.0 and 1.0.1, ubuntu, latest release. I have also avr-gcc on my system, i am not sure which gcc is used by Arduino IDE.

Is it sufficient to add the "const" keywords in your code?

Thanks, Oliver

My first and immediate concern is to get the library working for everyone on all the platforms.After that, optimizations and enhancements can be done to make things even better.I guess I missed from Ivan's post that this const/static/progmem stuff was creating a compile error.I'm currently not seeing this so I need to be able to reproduce the issue.

Do you have -Werror turned on?The IDE (at least the linux ones) does not set this option, it sets -WallSo while it generates warnings on linux, it does not crater the compiler with an error.What OS, IDE and gcc toolset are you using?I'm not seeing this as an error but rather a warning - I'll have to go try it on a VM in Windoze.I'm pretty sure I tried it on XP with 1.0 and didn't have any problem. I'll have to check it again on 1.0.1

More background and history on this below--- bill

The warning is actually a bug in the C++ compiler that the avr gcc folks have said that they are not going to fix.It is actually a warning rather than an error.Something about the way they handled the progmem and gcc attributes in C++ for the AVR.

I've wrestled with changing things to not have to deal with these progmem issuesfor several years now. Unfortunately, there isn't a quick fix for thisand any fix has some ripple effects into other tools like FontCreator.Some (most of it at this point) goes back to the way fonts were handled in the ks0108 librarywhich was the basis for the glcd v3 library.All the fonts are currently included as a header file with the data being declared in the header.This is ok until you have multiple source files that use the same font or include the same font header file.If the data is not static you get multiple referencesto the data structure and the link fails. If you declare them as static then the link can work butyou get multiple copies of the data included into the final image.Also, when declared static if there is no reference to it in the module, the data is removed by the compiler.Recent versions of the compiler and linker now have an option that will also remove dead code/data using special sections so this helps eliminate one of the original needs for the static declaration.

With avr-g++ if you try to declare the object static const you are back where you startedand get the warning again.

The real answer is to fix how fonts are declared to avoid the need for static declarations.It would have zero impact on the actual sketch code as it could all be under the covers.However, it does impact all existing font header files which would suddenly become incompatible with thelibrary as the declaration needs to be slightly different.It also affects FontCreator2.While it isn't a large or complicated task to convert over to a new & better way of handling the font data,at the time we created glcd v3 we decided not to do it. (Michael and I did have several long conversations about doing it).

It is still on my list of things to do. Also on my list is to change the fontdata format as well. I believe that Theile made a mistake in the font data format when definingresidual bits. The residual bits are encoded backwards in the byte from all the other fonts data bytes.Another thing I'd like to look at is using bdf font format instead.This would allow access to many fonts with a simple conversion script/tool.

Oliver,I just tried to build glcd library example HelloWorld on XP using the currentWindows Arduino IDE (1.0.1) and glcd v3after doing fresh installs (I hadn't tried 1.0.1 yet on Windows)It does issue warnings just like on linux but it does build fine.