Go Down

Topic: Beta version of GLCD library version 3 (Read 22 times) previous topic - next topic

bperrybap

#60
Aug 06, 2010, 03:30 am Last Edit: Aug 06, 2010, 06:07 am by bperrybap Reason: 1
Quote
Next I'm going to study the glcd library and hopefully find a way get this T6963 display working with the glcd lib.
So far I think at least the functions readData, writeData, writeCommand, WaitForStatu, goTo, init need to be adapted for this controller.


Correct.
Those are the primary functions that are needed to make all the higher level class functions operate.
But technically it is only readData(), writeData(), Init(), and gotoXY() as the other functions are support functions used by those 4 functions.




For those following along:

While providing the same yet expanded functionality
the glcd library code implementation is very different under the hood compared to the ks0108 library.

The ks0108 library was a single class with all the code
lumped into the ks0108 class.

The glcd library is broken into 3 classes
- glcd (in glcd.cpp)
- gText (in gText.cpp)
- glcd_Device (in glcd_Device.cpp)

The glcd class provides graphic functions as well as access functions into both gText and glcd_Device.
gText is obviously for the text areas but calls into glcd_Device.
glcd_Device handles the low level hardware i/o.

Both glcd and gText currently make some assumptions about the underlying display capabilities and orientation.
The biggest ones being:

- glcd memory is readable as well as writable.
- glcd memory to display pixel mapping consists of 8 pixels per byte
 (glcd page) and pixels in that page are 8 vertical pixels on the display.
- x & y coordinate values will not be larger than 255
- 0,0 origin is upper left corner of the display.
- Font data is stored in the same bit/pixel order as display memory.
- a read from memory does not advance the memory address while
 a write to memory does  advance the memory address.
  This allows fast read/modify/write operations as the upper
  layers simply read a byte, modify it, then do a write and can then
  do the next read without having to worry about setting memory
  addresses.
  It also allows fast write updates for things like bitmaps and font data
  as the code can do back to back writes and the address increment
  is handled by the glcd_Device layer or the hardware itself.

All the functionality currently provided by the glcd library (graphics & text) lives on top of these capabilities/assumptions.
Displays that cannot support these capabilities/assumptions
either directly or with library code will be much more difficult to get working with the glcd library.

Displays that can provide those capabilities and operate within those assumptions shouldn't be that difficult to get working with the glcd library.

Conceptually, glcd_Device's job is pretty simple.
Read & Write glcd memory and provide the ability to alter
the address where memory is read/written based on x & y coordinates.

The glcd_Device code may be a bit painful to get up to speed on.
It uses many macros and conditional ifdefs. Many of these were to make the
code more portable, more easily adapted to other displays, or to increase
the digital i/o performance by avoiding the Arduino digital i/o library functions
(digitalWrite(), digitalRead(), pinMode() etc...) and talking directly to the AVR ports/pins.

While it would be possible to add in a new device by replacing
the readData(), writeData(), GotoXY(), and Init(), it would be
better to take a look at the structure that is already in place for supporting other displays to see if that can be leveraged.
There is a collection of macros and defines which are used by the glcd_Device code that are defined in the device directory and in glcd_io.h
While a structure is in place for alternate displays, sometimes a new display will have a certain need that is unaccounted for in the glcd_Device code.
Should that occur, it can usually be handled with new or additional code that is conditionally compiled in based on  macros or defines in device specific header.
For example, the Init() code already looks for a macro called
glcd_DeviceIinit() which can override the default init code for
a given chip.

The reason that it is best to look at using the device macros, is that this will allow the library to support a new device and still support all the devices already supported through the existing configuration mechanism.

While only a general overview, hopefully it provides some insight as to the inner workings of the glcd library.

--- bill

Mario_H

Thanks for the extensive write up of the glcd library inner workings.
I guess I'll be reading for the coming few days hoping to see the light somewhere at the end ;)

From what I've seen so far is that the T6963 can do what the KS0108  can do and has some additional features like Cursor style setting, and display mode setting (OR,AND,XOR).
The hardware interface is slightly different (no SCEL pins and separate pins for Read and Write and a Font select pin)
For now I will hardwire Fontselect set for 8x8 font and for splitting the RW control into separate R and W lines I'm thinking of using a simple transistor inverter.

bperrybap

@Mario,
The easiest/quickest way to get the T6963 integrated into the glcd
library would be ignore the text capabilities for now.
The glcd library doesn't have any code to take advantage of this
capability as it assumes the display is a simple bitmapped memory
display and handles all the character rendering internally.

Michael and I have both taken a look at a few displays that
have hardware text support, and while it would be possible
to add support for it,
adding in support for hardware text capability won't be a simple drop in.
This is because the gText class currently assumes fonts are rendered
from local font data and that it has total control over any
pixel in the bitmapped display. This control allows gText to do some things that are likely to not be possible with hardware text.

For example the ability to render characters on any pixel boundary.
The displays that Michael and I have looked at so far tend to force the character glyph to land on certain boundaries.

Also, gText allows configuring multiple text areas each with
each allowed to select its own font and
supports line wrapping and scrolling within those user defined
text areas.

Overall, the issue really isn't so much putting in code to support
hardware text capabilities but how to update the API to support it
as some of the text capabilities will be different when using hardware
text support.

--- bill



Mario_H

Ok, Bill. Thanks for the advice.
In this case less is better (for me that is). I'm still in the very early stages of trying to understand what you guys have created.
I always find it difficult to get into someone else's mind to follow their way of thinking. An extensive library as this doesn't make that easier.

Mario

manwolf

Using a Mega and a no name GLCD I am hitting 18.06 fps with no problems.  I am going to use it in my graphing sketch to how it does, I will get back with an update.

Go Up