olikraus:
Isn't "SetDisplayMode" intended for this purpose?
No, that turns on all pixels by default and you write in inverse mode. So you actually turning off pixels by writing.
From that perspective I would say:
GLCD API would become more complicated if you add an additional color mapping method.
At least in my programs BLACK and WHITE are not used, so I would not be affected by that change.
That is true, that is why I suggested two possible ways to solve this.
Yes, but this is library for many users.
However you might be right on the latter as the INVERTED and NON_INVERTED variables could be used for this purpose as well, instead of the BLACK and WHITE.
Bill what do you think? That would be even more straightforward than the ON/OFF.
Bill, as for the TextAlignment() issue I'll think about it. In the early 90s I wrote a complete graphical library for DOS with VESA true color support that used all these functions. It could make texteditors, editboxes, combos, buttons, lists, scrollbars, radiobuttons, etc. I'll think about how I solved the textalignment.
olikraus:
Isn't "SetDisplayMode" intended for this purpose? I have not tested it, but I would have expected from the docs that BLACK and WHITE have opposite meanings in INVERTED mode.
I looked up my m2tk source and surprisingly I have not used WHITE or BLACK at all. Instead I did all function calls without color argument.
From that perspective I would say:
GLCD API would become more complicated if you add an additional color mapping method.
At least in my programs BLACK and WHITE are not used, so I would not be affected by that change.
Greetings, Oliver
Actually same for me. Up until recently I did most of my testing on black/green displays and
while I had a few white on blue I displays I never really specified colors either. The default is to turn pixels
on for most functions which works quite well as it is black pixels on black/green displays and white pixels
on white/blue displays.
It is only when you start to specify pixel color that things get strange.
In fact is was only as I was doing a function for XBM bitmap support when I ran really ran into the issue.
I was looking at supporting foreground and background colors for the bitmaps (including transparent),
and when testing on a white/blue display, it got very confusing.
Inverted mode doesn't really solve the issue. Yes inverted mode does invert the meaning of white & black
but white pixel type displays are "inverted" naturally. So if you use the inverted option in the API, you end up
with a very bright display with black pixels. While black means black/blue and white means white in this case,
from what I've seen the displays are not normally used in that mode. The normal use for white on blue
displays is for white pixels with a dark background.
My initial thought was not to modify the library API at all but rather to have a settable option in the glcd config
file so that this reversal is done at compile time.
But since there is only a single glcd config file it doesn't allow using the same library on different displays
without having to modify the config file for each display type.
It could also be handled runtime with a parameter to init()
but this is not my preference as it increases the size of the code and slows it down.
Right now I'm trying to get some feedback on how big of deal this is to decide if it is something
that I need to worry about right now.
Since no folks seem to be complaining, I'm assuming it isnt' that big of deal yet.
As I said, I have not tested INVERTED mode, but from a short review of the source code, I would say, that the meaning of BLACK and WHITE is swapped (see ReadData and WriteData procedures in the device class).
Inverted mode doesn't really solve the issue. Yes inverted mode does invert the meaning of white & black but white pixel type displays are "inverted" naturally.
But couldn't you than BLACK the screen and use WHITE to draw Text and Graphics?
agentgates:
Bill, as for the TextAlignment() issue I'll think about it. In the early 90s I wrote a complete graphical library for DOS with VESA true color support that used all these functions. It could make texteditors, editboxes, combos, buttons, lists, scrollbars, radiobuttons, etc. I'll think about how I solved the textalignment.
The glcd text isn't handled like text on most GUI text boxes. The biggest difference is that
the text is rendered directly into glcd memory and then it is essentially "forgotten".
There is no local AVR memory allocated for any of the text on the display.
Text essentially turns into a graphic once it is rendered. So you can't do fancy alignment on the fly as
characters show up. It has to be done all at once so you have to have the full string and all alignment parameters up front.
It also makes it impossible to do things like scroll bars.
I think to provide the ability to align simple text strings, extensions to DrawString() are the way to go.
It is a very easy addition and avoids many of the formatting "gotchyas".
The library already has a StingWidth() function to return the width in pixels. So it is just
a matter of providing a small wrapper to do the math of where to position the first character.
I'm aware of these things Bill. It is a simple framebuffer programming, just like directly programming the video card framebuffer in PCs except by using different bitmap layout (depends on the color mode).
Yes, you can make fancy widgets like scrollbars mate, by storing their position values (top, bottom, width, position) in a c++ class and redrawing the changed areas or the whole thing. If I had the demand I could either write a lightweight windowing system with the same technique. Just like old time.
agentgates:
I'm aware of these things Bill. It is a simple framebuffer programming, just like directly programming the video card framebuffer in PCs except by using different bitmap layout (depends on the color mode).
Yes, you can make fancy widgets like scrollbars mate, by storing their position values (top, bottom, width, position) in a c++ class and redrawing the changed areas or the whole thing. If I had the demand I could either write a lightweight windowing system with the same technique. Just like old time.
It isn't always just a matter of programming or techniques.
Believe me, I would much prefer to have used a framebuffer.
A framebuffer would make many things easier. Much easier than what the current library code does.
It would also allow the possibility of many additional new very useful features.
The main issue is RAM. Some of the AVRS only have 1k of RAM.
It is quite difficult to provide high level features without using much RAM so that
the library can function on these limited RAM microcontrollers.
Things get pretty tough when trying to support GLCDs that have larger display memory on them than
the microntroller has RAM. Think of trying to support a 192x64 display
when only having 1k of RAM in the microcontroller.
It is simply not possible to use a framebuffer for that sized display much less have
a framebuffer that is larger than the display memory for things like scroll bar
support.
Even on a m328 which has 2k of RAM consuming 1k for a simple framebuffer for a 128x64 display
might be excessive depending on the users application.
Bump up the display size beyond 128x64 and you rapidly begin to run out of RAM
for a frame buffer.
There are some games you can play if you store the text characters rather than
the full bitmap of the GLCD, but it gets extremely messy and complicated when trying
to intermix graphics and text than can scribble anywhere on the display.
Even the old IBM Monochrome and CGA adapters from back in 1981 had more memory than this. They
also had more memory than the display needed which could be used for additional storage.
My ideal would have been to have enough RAM for two frame buffers.
One for graphics and one for text. Then the two could be combined when drawing
on the physical display so things like text could overlay the graphics and even scroll on top of it.
As I said, I have not tested INVERTED mode, but from a short review of the source code, I would say, that the meaning of BLACK and WHITE is swapped (see ReadData and WriteData procedures in the device class).
Inverted mode doesn't really solve the issue. Yes inverted mode does invert the meaning of white & black but white pixel type displays are "inverted" naturally.
But couldn't you than BLACK the screen and use WHITE to draw Text and Graphics?
Actually, that will work. You have to intialize the display as INVERTED, then always use colors on all calls.
So things like:
GLCD.ClearScreen(BLACK);
GLCD.SelectFont(System5x7, WHITE);
GLCD.DrawLine(x1,y1,x2,y2, WHITE);
etc..
Yes it works, the only limitation is that you can't eliminate the color parameter for any graphic or font calls.
Maybe this technique is something useful that should be added to the documentation?
I'm not seeing the Epson S1D15605 series chips listed as supported, am I missing it or is this one not yet supported? If not, would it be possible to add this to the want list?
I have an OPTREX F-51553 128X64 GLCD that I've been working on and am building a backpack board for and I was wondering if this GLCD is or could be supported in the future.
You are correct in that neither of those glcds is currently supported.
I took a quick look at the S1D15605 it is very similar to the ks0108 interface so it would not be that difficult
to put in. It also looks to be similar to the ks0713 chip interface which was started but never finished as
our test hardware died.
As far as the optrex goes I have no idea as i was unable to get a specification without providing
my email address and I think it is ridiculous that I have to provide that to them just to get a spec
sheet and I refused so Elvis (elvis@graceland.com) now as the spec sheet for this lcd...
Sorry for the confusion, the Optrex F-51553 GLCD uses the S1D15605 chip interface.
I have it working (some what) on an Atmega16 driver board I made and I'm thinking about making an arduino shield for my Duemilenove and would love to use your library if it were made to support this GLCD some time in the future.
Michael and Bill,
I just got to looking at Graphical LCDs for Arduino..
Your work is just amazing.. professional and easy for newbies to read. I did IBM software projects for years and many were not as well documented and thought out as this!
I checked connections
I am using arduino mega 2560 with GLCD v3
contrast pin is -3v and I can see difference between connected -3V and disconnected so I know it works
display is kxm12864j datasheet- http://www.kna-lcd.com/upload/200722120154514999.pdf
The diag output is very helpful. Thank you.
I'm assuming that the diags "hang" right there.
The current library will hang indefinitely in the initialization process
if BUSY does not go away after sending it a command.
This is almost always due to a wiring issue.
What is happening is that the library is trying to send a command
to the LCD and it is not seeing BUSY go away so it is stuck
waiting for the board to be ready to accept a command.
I will say that if you are at all unsure about any of the wiring
don't guess as certain combinations of miswiring
can actually cause damage to the GLCD or the arduino.
Come back here with questions and I'll be happy to walk you through things.
Do you have a datasheet for the glcd or at least a model number?
If not, can you post a clear photograph of the back of the display so
I can see if I can identify the module?
I'm actually in the process of updating the library and diag sketch
to report better information in this situation vs just hang.
display is kxm12864j-4 and it says on the back that it is V2.0 datasheet- vr真人视频不打码,精品国产半推半就在线观看_尤物自拍197_lck的中国外援
during wiring I've looked on the page of the arduino playground
EDIT: I've redone wiring third time, same results, still stucks at "Initializing GLCD"
If you are going by the table on the playground or
in the documentation included with the glcd library (see glcd/doc/GLCDref.htm)
then this module is pinout B
Ignore pinout C for now as the wiki and the library documentation are currently out of sync for this pinout.
If you want I can review you wiring connections if you can
provide a table of which glcd pin # you connected to which arduino pin #.
If you are sure that those are wired correctly, then one other thing you can try is
to disconnect the backlight LED and the all connections to the contrast pot.
The glcd does not need them to function enough to be tested by the diag sketch.
They are only used for the human to be able to see the pixels on the display.
Sometimes a clear closeup photo can help diagnose wiring issues.
I've seen a case on the mega where the pins were accidentally miswired
1 pin off on the mega headers
or occasionally the pins on the glcd are wired backwards
as there was confusion as to which end was pin 1.
I am really ashamed for stupidity of my error as I am in hobby electronics for quite some time
as I put the lcd on breadboard i started connecting pins from left to right as 1-20, but i forgot that when I put it on a breadboard the pins will invert
at the moment I am reconeccting it the right way, and hoping i didn't kill the lcd
