next topic »

[on:]

Hi everyone,

I have in my toy-box a couple of graphic displays. All those displays have different controllers of course (Murphy ?).
GLCD has a couple of nice features and it would be nice to use only one graphic library.

At the moment i have 2 displays connected to a mega2560:
- 1x 400x64, LC7981/HD61830 graphic or text mode controller
- 1x 240x64, T6963 graphic,text or mixed mode controller
These displays work fine but the drawback is that they use their own drivers and graphic functions.

As i'm not a programming guy, i find it complex to port/create drivers for the GLCD library.
Reading/interpreting the data sheets is no problem and reading basic C code is doable (i got the displays working) 
So far i have read the source and the doc. The trouble is all those #define an chip selects. As my displays only work with 1 CS line and the controllers are 'smarter' then the KS-0108.

So my question is:
- Can someone help me with creating some nice code?
- Is it possible to have more then 1 display connected at the time?
Maybe in the future it's easier for more people to use their 'found' displays easier.

tnx,
Rinus

[Reply #1 on:]

Rinus:

As I understand it you were able to read the data sheets and then write some code.  Now it seems that you want us to help you write better code without using either the data sheet or the code that you would like us to revise.  That's a pretty tall order.

Don

[Reply #2 on:]

Hi Don,

Thanks for your reply.

As I understand it you were able to read the data sheets and then write some code.

In sep/oct. 2010 i ordered an Arduino mega2560 together with an Ethernet shield (v5) and started playing with it. Played with OneWire, rotary encoder, i2c RTC, 20x2 LCD, Ethernet server/client stuff and the 2 graphic displays mentioned. For the 2 graphic displays i found libraries at http://en.radzio.dxp.pl/t6963/ for the T6963 display and https://github.com/vsergeev/embedded-drivers/tree/master/avr-lc7981 for the HD61830 one.
Then i modified both to let them work together in a test project.
There are a couple of problems with those libraries.
1) I cannot print like i could do with Serial.print or LCD.print etc.
2) There are different implementations with different functions to draw lines, circles etc (file: graphic.c/graphics.c).

Now it seems that you want us to help you write better code without using either the data sheet or the code that you would like us to revise. That's a pretty tall order.

I for sure didn't meant to ask for you guys to solve my problems. 
And yes, without giving some information and ask for a total solution is indeed waaay to much to ask for.. 

A lot of people write libraries for graphic displays and use their own graphic functions. It's nice to have a single framework for all type of graphic displays. This is the main reason i'm looking into GLCD.

I'll focus on the T6963 controller for now because it is 240 pixels wide and i am not sure if wider displays can work with GLCD.

What have i done so far (still lots of things to do).
In 'Modlm6270_Manual_Config.h':
What can i do with  #define glcdEN, the T6963 doesn't have an enable line, just leave it out?
The T6963 has separate WR and RD lines. How should i go on with that, are heavy modifications needed in other .cpp files?

config/Modlm6270_Manual_Config.h

Code:

/*
 * lm6270_Manual_Config.h - User specific configuration for Arduino GLCD library
 *
 * Use this file to set io pins and LCD panel parameters
 * This version is for a LM6270SYL display
 * connected using the default Arduino wiring
 *
*/

#ifndef GLCD_PANEL_CONFIG_H
#define GLCD_PANEL_CONFIG_H

/*
 * define name for panel configuration
 */
#define glcd_PanelConfigName "lm6270-Manual"

/*********************************************************/
/*  Configuration for LCD panel specific configuration   */
/*********************************************************/
#define DISPLAY_WIDTH 240
#define DISPLAY_HEIGHT 64

// panel controller chips
#define CHIP_WIDTH     240 // pixels per chip
#define CHIP_HEIGHT    64  // pixels per chip

/*********************************************************/
/*  Configuration for assigning LCD bits to Arduino Pins */
/*********************************************************/

/*
 * define name for pin configuration
 */
#define glcd_PinConfigName "lm6270-Manual"

/*
 * Pins can be assigned using Arduino pin numbers 0-n
 * Pins can also be assigned using PIN_Pb
 *   where P is port A-L and b is bit 0-7
 *   Example: port D pin 3 is PIN_D3
 *
 */


/* Data pin definitions
 */
#define glcdData0Pin        PIN_A0
#define glcdData1Pin        PIN_A1
#define glcdData2Pin        PIN_A2
#define glcdData3Pin        PIN_A3
#define glcdData4Pin        PIN_A4
#define glcdData5Pin        PIN_A5
#define glcdData6Pin        PIN_A6
#define glcdData7Pin        PIN_A7

/* Arduino pins used for Commands
 * default assignment uses the first five analog pins
 */
#define glcdCSEL1           PIN_C2

#define glcdRW              PIN_C0
#define glcdRD              PIN_C1
#define glcdDI              PIN_C3
//#define glcdEN              PIN_C2
// Reset Bit  - uncomment the next line if reset is connected to an output pin
#define glcdRES             PIN_C4    // Reset Bit

/*
 * the following is the calculation of the number of chips - do not change
 */
#define glcd_CHIP_COUNT ((DISPLAY_WIDTH + CHIP_WIDTH - 1)  / CHIP_WIDTH)


/*
 * The following defines are for panel specific low level timing.
 *
 * See your data sheet for the exact timing and waveforms.
 * All defines below are in nanoseconds.
 */

#define GLCD_tDDR   320    /* Data Delay time (E high to valid read data)        */
#define GLCD_tAS    140    /* Address setup time (ctrl line changes to E high)   */
#define GLCD_tDSW   200    /* Data setup time (data lines setup to dropping E)   */
#define GLCD_tWH    450    /* E hi level width (minimum E hi pulse width)        */
#define GLCD_tWL    450    /* E lo level width (minimum E lo pulse width)        */

#include "device/T6963_Device.h"
#endif //GLCD_PANEL_CONFIG_H

device/T6963_Device.h

Code:

/*
  T6963_Device.h - Arduino library support for graphic LCDs

 vi:ts=4

This is a device template file that shows what needs to be
in a device header for a glcd.

The following lcd primitives must be defined

glcd_DevSelectChip(chip)
glcd_DevENstrobeHi(chip)
glcd_DevENstrobeLo(chip)
glcd_DevXval2Chip(x)
glcd_DevXval2ChipCol(x)

For devices that split set column into to 2 commands of hi/lo:

glcd_DevCol2addrlo(x) (x & 0xf) // lo nibble
glcd_DevCol2addrhi(x) (x & 0xf0) // hi nibble
 
*/

#ifndef GLCD_PANEL_DEVICE_H
#define GLCD_PANEL_DEVICE_H

/*
 * define name for Device
 */
#define glcd_DeviceName "T6963"

/*
 * Sanity check XXX config pins
 *
 * Help the user detect lipin configuration errors by
 * detecting when defines are missing or are incorrect.
 *
 * Check for existence/non-existence of:
 * glcdCSEL1
 * glcdCSEL2
 * glcdEN
 * glcdE1
 * glcdE2
 */

#if (CHIP_WIDTH < DISPLAY_WIDTH) && (CHIP_HEIGHT !=  DISPLAY_HEIGHT)
#error "T6963 CHIP_WIDTH < DISPLAY_WITDH but CHIP_HEIGHT != DISPLAY_HEIGHT"
#endif

#if (CHIP_HEIGHT < DISPLAY_HEIGHT) && (CHIP_WIDTH !=  DISPLAY_WIDTH)
#error "T6963 CHIP_HEIGHT < DISPLAY_HEIGHT but CHIP_WIDTH != DISPLAY_WIDTH"
#endif

#ifndef glcdCSEL1
#error "T6963 configuration missing glcdCSEL1"
#endif

#ifdef glcdEN
#error "T6963 configuration missing glcdEN"
#endif

#ifdef glcdE1
#error "T6963 configuration does not use glcdE1"
#endif
#ifdef glcdE2
#error "T6963 configuration does not use glcdE2"
#endif


/*
 * LCD commands -------------------------------------------------------------
 */

#define LCD_ON
#define LCD_OFF
#define LCD_SET_ADD
#define LCD_DISP_START
#define LCD_SET_PAGE


/*
 * Status register bits/flags -----------------------------------------------
 */

#define LCD_BUSY_FLAG
#define LCD_BUSY_BIT



/*
 * Define primitives used by glcd_Device.cpp --------------------------------
 */

#define glcd_DevSelectChip(chip)

/*
 * Define how to strob EN signals
 */
#define glcd_DevENstrobeHi(chip)
#define glcd_DevENstrobeLo(chip)

/*
 * Define how to get low and how addresses
 * (if needed)
 */

 * Convert X & Y coordinates to chip values
 */
#define glcd_DevXYval2Chip(x,y)
#define glcd_DevXval2ChipCol(x)

/*
 * Convert from chip column value to hi/lo address value
 * for LCD commands.
 * (If Needed)
 */

#define glcd_DevCol2addrlo(x)
#define glcd_DevCol2addrhi(x)

#endif //GLCD_PANEL_DEVICE_H

Thanks
Rinus

[Reply #3 on:]

Rinus,
I see now where you are going. I didn't at first catch on that you were wanting to add support
for a new glcd panel to the glcd v3 library. (I am the author of the low level device code and all the crazy ifdefs used).

While there is a basic framework in place to support different types of displays other than the ks0108,
currently the only other display that is fully supported and working is the SED1520/33 (which is very similar
in operation to a ks0108)
There was a start on the ks0713 but the other author involved (Michael) suffered a hardware failure
of his glcd module and we stopped work on it.

Now while there is a framework in place, I will say that as it stands today, it is VERY difficult to add in other
devices - especially without being very familiar with the code.
In fact, Michael and I have talked about changing the underhood low level stuff and how
it glues into the upper layers to make it easier to support to other types of displays.
(we decided not to tackle this for version 3)

The main thing that makes it tough is the some of the library codes assumption of how memory maps
to the physical displaying of pixels. (some of these are even in the higher level graphic functions)
The ks0108 uses 8 bit pages that map to 8 pixels with the lsb at the top.
Also,  the x/column increments from right to left and the y/row/page address increments top to bottom.
This assumption is buried in some of the code, in particular the font rendering code.
This makes the font rendering code quite complex. There was an intentional trade off for this complexity
to ensure that the library used very little RAM regardless of the size of the glcd display involved.
i.e. a 240x128 display will use no more memory than a 32x122.
If the code was simplified by using a frame buffer, this would make many things easier but then
RAM needs would scale to the size of the display and the library would not be able to run on the smaller
AVRs like the mega168. And if the code was changed to use a more generic pixel drawing capability
without the 8 bits/pixel assumption, the code would dramatically slow down.

The other thing that makes it tough as you are seeing is the use of control lines. Currently, there is an
abstraction for the control lines but the only set of control lines that are set up to allow complete reconfiguration
are the chip selects. Those allow you to configure the number of pins and the level of those pins for any combination
of chip selects needed. This level of configuration is currently not available for any other control lines for things like
R/W lines, Enables, cmd/Instr, or reset lines.
What that means is that currently the low level code blindly assumes how these work and the level they need
to be. This often does not match what other glcd modules may need to operate.

Michael did some experiments with porting the code to a Nokia 6610 color display.
We learned alot in the process of what works and doesn't work and things that could make it
easier for other libraries.


Note: How this was done is not a method we would prefer to do going forward as we would like
to modify the library to be easier to port to other glcds but was used for this initial excersize but
is the only method available at this time, without having to make much more substantial changes
to the upper layer code and the configuration files.

The way that was done was to strip away the glcd_cpp.c file and provide a new one.

The low level device code provides a very limited amount of functionality and has very
few functions in it. In order to glue into the existing upper layers, the new low level device.cpp
code must exactly emulate the functionality provided today.
It  means that even though a glcd device might support text modes, or fancy xor/or read/write modes,
they cannot be used because the glcd
library wants to control the display at a pixel level.
The current interface to the low level code is a pixel interface. (actually it is a 8 bit pixel/page interface).
But this is how  the upper layers  can provide user configurable fonts and
can provide things like text areas on any pixel boundary.

This means that the new device low level code must
accept the way pixels are handed to it: as 8 bit pages along with the x/column and y/page addressing
directions of a ks0108 style device and map/convert them to the way the new glcd wants/needs them.

Since I don't know where the next version of the glcd library will go with respect to its internal
interfaces and how things glue together there some risk that anything that is done now may not
work in the future.
Ideally, the library would be updated to make things like this easier but in order to do that,
it is very likely that the interface between the layers will have to change.

For now, I can help out a bit as I have time.
The place to start is to get very familiar with the interface functions in glcd_device.cpp
which are the public functions - There are only 6 of them.
Those 6 functions are all that is needed for all the rest of the high level code to operate.

Anyway, I know its a lot but that should get you started.

--- bill

[Reply #4 on:]

There was a start on the ks0713 but the other author involved (Michael) suffered a hardware failure
of his glcd module and we stopped work on it.

Now while there is a framework in place, I will say that as it stands today, it is VERY difficult to add in other
devices - especially without being very familiar with the code.

Hi Bill - is this still the case?  If so do you need another board or is it possible to get some guidance as to what is needed to add in support?