Pages: 1 ... 15 16 [17] 18 19 ... 21   Go Down
Author Topic: GLCD library version 3  (Read 75125 times)
0 Members and 1 Guest are viewing this topic.
Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 63
Posts: 2639
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Wow, this is a new one. I've never seen an issue like this before.
Quote
... but the display usually crashes ...
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 passes
but 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.

--- bill



Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 3
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 display
3) The part num is GDM12864HLCM from SparkFun
4) 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 ISSUES
7) The number of wires attached does not effect the display performance. The test in 1) was done using the setup from 7).



 --Thanks for helping me figure this out Bill!
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 63
Posts: 2639
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

But with respect to #1 is the diag sketch still reporting that all the tests passed on
the 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 require
an actual pulse on them to function properly.
Ideally, it should be driven and it should be pulsed low to ensure the glcd
is 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 line
on the ks0108 playground page. So see the playground page for more information
about how to handle the reset line and potential issues and work arounds.

My guess is that module you have is experiencing a spurious reset
while 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 seeing
is 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 why
I'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 glcd
and part of the initialization (it is actually the first thing done) is to turn on the pixels.

--- bill
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 11
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 63
Posts: 2639
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Very nice little tool.
I put a link to this on the glcd google project page.

I'll respond further in the exhibition thread:
http://arduino.cc/forum/index.php/topic,118349.0.html


--- bill
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 3
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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...".  smiley-lol

Model: Sunlike SG160160B    http://gecw.co.kr/data/sunlike/sg160160b.pdf
Controller: SED1330F series    http://www.lcd-module.de/eng/pdf/zubehoer/sed1330.pdf

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.

Thanks for your time.
Andy
« Last Edit: August 26, 2012, 11:51:18 am by Jance » Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 63
Posts: 2639
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Andy,
Had a quick look at the data sheet. Still looking at the graphic
memory 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 E
Then strap CS to ground - shouldn't need to be disabled for this application.
AO is the DI which is used by glcdDI
All 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 advanced
capabilities, because glcd treats the module as a dumb bitmapped display. However, all the glcd
libraries api capabilities should be available.

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

--- bill
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 63
Posts: 2639
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 up
to allow configuring separate read & write pins.

I've been wanting to change the library to make it easier to integrate in new device support
just haven't gotten around to it.
It costs a bit of performance to do it, but it would make things much simpler particularly for
situations like this. It can be done with the existing methodology it just requires a high level of
understanding 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.cpp
code 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 wiggled
into 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.

--- bill
Logged

Germany
Offline Offline
Edison Member
*
Karma: 133
Posts: 1443
If you believe something is right, you won't see what's wrong (David Straker).
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 
Logged

Indonesia
Offline Offline
Newbie
*
Karma: 0
Posts: 1
May all beings be happy
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 63
Posts: 2639
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 configuration
on 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.h
and that depends on which core/variant you are using.

Which core and variant are you using?

--- bill
Logged

Germany
Offline Offline
Edison Member
*
Karma: 133
Posts: 1443
If you believe something is right, you won't see what's wrong (David Straker).
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Bill

I tried to compile HelloWorld which produces the following error:
Code:
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
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 63
Posts: 2639
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Bill

I tried to compile HelloWorld which produces the following error:
Code:
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 -Wall
So 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 issues
for several years now.  Unfortunately, there isn't a quick fix for this
and 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 library
which 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 references
to the data structure and the link fails. If you declare them as static then the link can work but
you 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 started
and 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 the
library 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 font
data format as well. I believe that Theile made a mistake in the font data format when defining
residual 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.



Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 63
Posts: 2639
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Oliver,
I just tried to build glcd library example HelloWorld on XP using the current
Windows Arduino IDE (1.0.1) and glcd v3
after 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.

I am unable to reproduce the error.



For the bug log on the progmem stuff:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
It look like after many years, it has finally been resolved in recent versions of avr-gcc.

If it is really an issue for Arduino, then there are some other ways to deal with it by playing games
with the progmem definition in the glcd header files.

i.e. something like this:
Code:
#if defined (__AVR__)
// Workaround for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
// to prevent: warning: only initialized variables can be placed into program memory area
#ifdef PROGMEM
#undef PROGMEM
#define PROGMEM __attribute__((section(".progmem.data")))
#endif
#endif

I looked at this quite a while ago. It didn't make it into glcd v3,  but it was on the list
for consideration in the next version of the library.


--- bill

Logged

Germany
Offline Offline
Edison Member
*
Karma: 133
Posts: 1443
If you believe something is right, you won't see what's wrong (David Straker).
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


I found this statement in here: http://gcc.gnu.org/gcc-4.6/changes.html
Quote
On AVR, variables with the progmem attribute to locate data in flash memory must be qualified as const.

It seems, that PROGMEM requires "const" since gcc 4.6.x.

When I change
Code:
static uint8_t System5x7[] PROGMEM = {
to
Code:
static const uint8_t System5x7[] PROGMEM = {
in GLCD v3 fonts/SystemFont5x7.h, then this font compiles is find.

I think my local gcc was updated from 4.5.x to 4.7.x on my last Ubuntu update to 12.10.

I also assume, that the Windows Arduino version comes with an old gcc version. Arduino IDE for Windows will work as long as an old gcc version is shipped with it.

My suggestion is to update all GLCD v3 font definitions with the "const" keyword.
As example, this also happed to avr-libc: http://lists.nongnu.org/archive/html/avr-libc-commit/2012-01/msg00006.html

Oliver
Logged

Pages: 1 ... 15 16 [17] 18 19 ... 21   Go Up
Jump to: