Obviously the unit is failing the walking 1's test, my first suspect was wiring - however, i cannot seem to find any obvious shorts w/ my Fluke and my magnifying glass. LCD powers up, draws a single line across the bottom (and contrast does vary appropriately w/ the pot across pin 3). Crawled all over the interweb, data spec for LCD board matches perfectly with the suggested Mega wiring suggestions. GLCDdiags compiles correctly, can do all the other funky things with the Mega that i want (Ping board works fine, IOs good, etc...) I started looking at the GLCDdiags script to find out if-anything, what the oddly incrementing failed comparison msg means. Has anyone seen this before?
Hi there.
I'm the author of the Diags sketch and am the co-author of the glcd v3 library.
From what I see, there is definitely an issue with the library.
There is an issue with the 2560 that I haven't gotten around to fixing yet.
(been away from home for the past month)
The 2560 wasn't available when the beta was started but I saw the issue
showing up while I was gone.
If remember correctly it just takes a minor tweak.
It shouldn't compile for a 2560.
For the background:
From the diag output, the first thing I notice is that the AVR pin numbers calculated from the Arduino pin #s for
the data lines as reported from the diags output are wrong.
Note: the glcd library does not use the normal arduino i/o functions as they
are too slow. It maps the arduino pin numbers to its own internal format and
then does raw AVR port i/o rather than call the much slower digital_write() functions.
The reported format of the ports is PIN_pb where "p" is a raw AVR port (A, B, C, etc...) and "b" is
a bit number on that port. (0 to 7).
From the output you can tell the bit numbers are wrong.
I am curious though. Did you make any changes to the library files to get it to compile?
I would have thought that it wouldn't have compiled for the 2560 environment.
I haven't looked at the more recent Arduino build tools (last I looked at was version 0021)
so maybe they tried to do some raw AVR port i/o macros that have broken the glcd pin mapping macros.
In the mean time, I'll go off and look at the latest arduino IDE and see
what they've done and also look at how they mapped the 2560 pins
to AVR pins and work on a patch to get this fixed.
Something screwy is going on with the build of the library.
Can you tell a few more things:
which Arduino IDE are you running? (0022?)
What board type are running (Mega2560?)
Where did you get your glcd library? and did you modify it?
The "virgin" glcd library that I released for the beta will refuse to compile for the 2560 board
including when using the latest 0022 IDE.
There is a small tweak that must be made before it compiles.
I'm guessing that that the glcd library files you are using have been modified incorrectly.
The real fix is in the files
glcd/include/arduino_io.h
[clairvoyance]Our bits must have been crossed on the internets, as I answered most of these questions prior to seeing your reply![/clairvoyance]
Good afternoon bill,
I'm running IDE 0022 (direct download from arduino.cc) x64 on Debian (testing). The board that i'm running is an Arduino Mega2560, and the LCD i'm trying to drive (via breadboard interface) is an NHD-12864AZ-FSW-GBW-VZ (being controlled by a KS0108b chip).
I did some poking around earlier (yesterday) and found a modification (on this forum) that suggested an addition of (__AVR_ATmega2560__) into the ks0108 library, so as to allow the compilation to find a compatible board (or so it seems to me) and to call the Mega library, as appropriate.
Sounds like the mod is incorrect.
See post above, I think I was updating it as you were posting.
I tried to get this resolved a while back the guy that was testing things vanished before I
could verify the fixes.
I'd like to get this resolved and verified so I can re-release the code.
So I'd like to work with you until this is fully working and then I'll give you access to the
next release so you can verify it. (I don't have a mega2560 board to test this on).
I'm using debian (Ubuntu actaully) so we should be seeing the same thing as we move
forward.
Sorry about the silence.
Yes the issue was resolved.
Chris and I worked offline to get it resolved.
It was a combination of a few things.
One being that some folks have attempted to update the library for 2560 support
on their own and their recommended modifications are quite a bit more complicated vs what is really necessary.
And a few I've seen incorrectly add in mega2560 support to the glcd library which can really break things,
especially if trying to switch between different board types.
The actual changes required are quite minor (as you saw above) but they are in several different files
that are not obvious.
I'm updating the library and will be releasing an update soon.
The other error, was a visual misreading of the silkscreen labels on the board connectors
and accidentally hooking up the wires skewed so that all the pin #s were off by 2.
Once these 2 items were corrected it all worked fine.
I don't anticipate any issues with the updates for the 2560 but
since I don't have a mega2560 board to verify things on,
I'll be getting the updated library out to Chris first so that he can test and verify it.
Also, I'll be doing some minor updates to the documentation
and adding in another sketch to demonstrate text areas and the use of the
library's supported Printf() capabilities.
I may also update the low level initialization code and the diag sketch to report
initialization issues rather than hang in the initialization routine.
I need to get with Michael (other glcd library author) and decide if the
library is ready for full release.
I think with these minor updates
it is ready since the library has now been out there in beta for over 6 months (since July of 2010) and
I have not seen any code related issues reported yet.
The 2560 issue was due to it not being available when the beta was started
and the code simply did not support it.
================
If people are really stuck with this on 2560 boards, I could slam out a quick fix for the 2560
(no changes or updates other than 2560 support)
and then get with Michael on the final release.
just to reiterate what Bill said, the board that I have (mega2560) and the GLCD v3 library (with bill's minor modification) works flawlessly. I've done a variety of work with the GLCD library now, and played with most of the individual display components/methods on it w/o finding anything of note. It's a good deal, and once bill's done, i anticipate no real problems.
I tried the fix above but apparently failed because I get the following errors when loading to my Mega 2560:
avrdude: stk500v2_command(): unknown status 0xc8
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude: stk500v2_command(): unknown status 0x01
avrdude: stk500v2_disable(): failed to leave programming mode
I used AVR CodeVision to modify the header files, am running Windows 7, Arduino 0022, and the beta version of the glcd code.
The fix above is not the entire fix required to get it to work, and that looks more like a connection problem between the Mega and windows XP, not a coding problem.
I'm not sure what is going on with the serial connection but the glcd library code
does not have any code that is involved with the uploading so there is no code
specific to any environment or OS in the glcd library code.
There is something else going on that is causing the upload problems.
I'll be getting a 2560 library update to Chris within a day.
As soon as he blesses it, and Michael and I then have a chance
to verify that the other boards and numerous other GLCDs still work,
an update will be released so the issue of
lack of 2560 support will be put behind us.
Michael and I are still in the process of cleaning some things up
in the library, doing final testing, and updating
the glcd library Google Code and the ks0108 playground pages.
Hi
I am joining the post.
First of all many thanks you, Bill and Michael for the job done so far.
I followed your instructions and it is working fine for me using a Mega2560 and one LCD from SparkFun (http://www.sparkfun.com/products/710)
I still have some minor bugs but I found a working around (see below).
I would like to ask you the following question:
I plan to add a second graphic LCD and I am wondering how it would be possible.
I did it in the past with the LiquidCrystal library using the same Arduino pins for all signals except for EN (enable) and then using 2 instances of the library.
Would it be possible with your library?
What is your recommendation?
Raoul
Note: One strange bug I have is using GLCD.CursorToXY(), the characters displayed following this instruction show a blank horizontal line in their middle. This doesn’t happen when using GLCD.CursorTo().
Raoul,
I'll be happy to answer these questions and am very interested in any bugs you find
in the library so that they can be fixed; however, these items are unrelated to this thread and would
be better dealt with in their own thread.
For the bugs, I am very interesting in resolving anything you have uncovered.
I have re-created a glcd v3 beta thread for that discussion since the v3 beta
thread was locked when the new arduino forum was created.
Please post the bugs/issues you found over in the new v3 beta thread: http://arduino.cc/forum/index.php/topic,56705.0.html