fanghuaqi / glcd-arduino Goto Github PK

Attached to this post is a new font, its 3x5 and full alpha numeric.
It is based in the Wendy font from dafont.com with a lot of changes made to it.
A really small font included in the library, so I thought I would make one and 
share.

Feel free to include it in the library for download.

Thanks for the awesome library.

There have been some requests to add the ability to justify text on the display.
This is actually quite a useful capability.

While it would be possible to do this on the fly on a row as the text comes in,
that method would require buffering all the text on the display and
continually having to re-draw the row of text as it is coming.
When doing the on-the-fly justification, users will also probably expect
word breaks across line wrapping to work, which adds in another layer
of complexity.t  It also gets very messy with variable width fonts.

A simpler/easier solution that provides enough functionality that would
probably satisfy most needs, would be to expand the DrawString() API call.
This would allow the user to specify justification parameters rather than
the absolute x,y location and then let the library calculate the x,y location
based on the desired justification.

Since DrawString operates on text areas, this allows the justification to be 
based
on the text area used to make the DrawString() call.

The API could allow horizontal justification of left, right, and center.
For vertical the possibilities are: 
current row/Y, this exact row, vcenter text area, top text area, bottom text 
area.

The horizontal justification could use a single parameter enum
The vertical could as well when not using exact row by using
"very large"/"out of bounds" row value for the enums.
That way the user can use a row
value or these defines/enums to indicate the preference.

One thing to be cautious of is  that if this is added by overloading the 
existing DrawSting() that function already takes three parameters, and while 
they currently are *ptr, uint8_t x, uint8_t y in the future the x & y values 
may need to be bumped to larger than 8 bits.
So this new function either needs to use signed ints for overloading or use a 
different named function to prevent future function collisions.

The device header needs to do a check to see if the DISPLAY_WIDTH
is larger than what the underlying device code can support.

Currently with 8 bit X values, the maximum supported X value is 254
not 255. So the maximum DISPLAY_WIDTH is 255 not 256.
This is because to provide certain capabilities the code needs to be able
set the X value to be bigger than DISPLAY_WIDTH.
When all you have is 8 bits, then DISPLAY_WIDTH can't be larger than 254 to
allow room for a larger X value.

So.....
The device code will determine the maximum size of the underlying
device code and then if the DISPLAY_WIDTH is greater than that,
issue a warning but then declare DISPLAY_WIDTH to the maximum allowed.


NOTE:
If there is some sort of glcd_coord_t type for the X values then
this check needs to use sizeof(glcd_coord_t) to determine the maximum.
Which for 8 vs 16 bits would be 254 or 65534

glcd needs to support Leonardo board type.
This is not difficult and it is easy to detect the difference between
Teensy 1.x and Leonardo.
The key is to look for defines set by the teensy environment first
before looking at the processor type define.
Teensy defines digitalPinToPortReg, digitalPinToBit, and CORE_TEENSY

Currently, there is some difference between the Arduino icons.
Some have a white pixel as the boarder pixel of the icon and some don't.
I believe all but the default 64x64 icon have this "pad" pixel.

This only comes into play if you do icon animation by redrawing
the icon on top of the old icon 1 pixel at a time.

Not sure how this ended up in glcd vs glcd_device but it really
should be in glcd_device as it is a device level function.

The end user API should see no difference.

The GLCD init code does not poll the RESET signal from the module.
Currently, it cheats and simply waits a few milliseconds
but only if it asserted reset.
Pauls teensy to glcd adapter asserts reset with a long pulse so the
init code tries to talk to the module while reset is still asserted.

So the code should be modified to poll reset.

It would nice if diags could report the library build number and build date.
This would help fully identify the code base used.

Description says:
right edge at x+width-1
bottom edge at y+hight-1
This is wrong. Correct version is:
right edge at x+width
bottom edge at y+hight

In fact, this procedure behaves consistently with DrawRect.

There is an combination "bug" related to the bitmaps/allBitmaps.h
The allBitmaps.h file "as shipped" right now does not contain includes
for all the bitmaps in the bitmaps directory.
Most notably, the file "ArduinoIcon.h" is not included.
This file has a #define in it to map the name ArduinoIcon to ArduinoIcon64x64
This was done for backwards compatibility.
The "combination bug" comes into play as follows:

Once the user runs the Processing/Java bitmap utility, the allBitmaps.h file is 
updated to include all the headers in the bitmaps directory, which includes 
ArduinoIcon.h
This is normally not a problem and is in fact exactly what is desired.

However,
GLCDdemo.pde sketch has declaration of
Image_t ArduinoIcon;

Once ArduinoIcon.h is included, the demo code will no longer compile
and once the processing/java bitmap utility is run, the file ArduinoIcon.h is 
included because the allBitmaps.h header is udpated to include it.

I'm not quite sure how you want to handle it.
We have a couple of options.

1) We could "deprecate" ArduinoIcon and eliminate the include file in 
   the bitmaps directory and handle its definition in the
   include/glcd_Deprecated.h
   (This option requires updating some doxygen documentation)

2) Fix the demo code (GLCDdemo & GLCD_BigDemo) not use the variable name 
"ArduinoIcon".
   Simply change the name to something like "Icon" instead.
   Very quick/easy and solves the problem.

NOTE:
  While we are fixing this, we also should fix the allBitmaps.h file to
  include all the bitmap header files being shipped.

an we automate some of the test procedure for creating config 
permutations ?
-mem says: I think that any tool we make now would become obsolete when we 
introduce a wizard so it would be good if there was something simple, 
otherwise we create variations by  hand using the text editor 

Should we drop official (i.e. tested) support for the less likely options 
in the first public release (e.g. the 4 chips options) – we would keep the 
code and possibly the config options, but document that these are not 
supported in this release.
-mem view: we test all permutations once (although the 3 and 4 chip 
options may have to wait until next week), but if the config files need 
iteration we consider dropping official support for the less likely 
permuations

Do we need to document that the config file structure may change in a 
future release (for example, to support a wizard or some future IDE 
library config capability)
- mem says: We add a note in the documentation that the configuration 
mechanism is subject to constant improvement; user changes to customize 
any of the configuration files may required re-editing in a future 
release.  

Should we change the naming of custom config files to prevent confusion 
with users that want to customize an auto-config file.
-mem says: here is one option, change:
  #include "config/ks0108_Custom_Config.h"  // generic ks0108 
configuration 
to:
  #include "config/ks0108_Manual_Config.h"  // Generic user selected  
ks0108 configuration 

The define for the configuration would match the name scheme we adopt,  
assuming the above
 #define glcd_ConfigName "Arduino-ks0108"
 #define glcd_ConfigName "Manual_ks0108"  // config name for ks0108 manual 
config (a comment should advise the user to change the name if he changes 
the file)

Should diags display a #define identifying the name of the autoconfig file 
if one was active

There appears to be some sort of issue with drag and drop
on Ubuntu linux with the glcdMakeBitmap tool.

At this point not sure if it a Nautilus issue.

Tried to use GLCD with serial connected 128x64 LCD, did not work, any help?

Currently functions like Puts() do not support the String class.
It would nice to add this so that users don't get confused by
it not working for Puts() while it works for print() which is really
the Print class.

Currently, in the doxygen/html documentation it isnt very clear
how to modify the pins used to say free up analog pins on 168/328 boards.
There is mention of pin configuration files, the naming convention and
the pin syntax but nothing that really spells out how to do something useful
like change the pins around to free up analog pins on the smaller AVRs. 

Originally Reported by project member memargolis, Jul 21, 2010

- sparkfun LCD-08799
http://www.sparkfun.com/datasheets/LCD/DS-G160128STBWW.pdf
http://www.sparkfun.com/datasheets/LCD/Monochrome/Datasheet-T6963C.pdf
http://www.sparkfun.com/datasheets/LCD/Monochrome/T6963C-AppNote.pdf
http://www.sparkfun.com/datasheets/LCD/Monochrome/AN-029-Toshiba_T6963C.pdf

There are two typing errors with GLCD.Height

In the section "Coordinate system"
GLCD.Height is written as
GLCD.height

In the section "Properties"
GLCD.Height is written as
GLCD.Heigh

This should be corrected in order to avoid confusion

What steps will reproduce the problem?
1. Attempt to compile the GLCD demo example program with the Arduino Micro 
board selected as target

What is the expected output? What do you see instead?
Compilation errors that "Arduino pin mapping not defined for this board"

What version of the product are you using? On what operating system?
GLCD 3 on Arduino 1.0.2 on Ubuntu


Please provide any additional information below.

Please provide a procedure 

void gText::GetFontHeight(void)

{
    if(this->Font == 0)

        return 0; // no font selected


 return (FontRead(this->Font+FONT_HEIGHT)+1);
}

And maybe also a corresponding GetFontWidth() procedure

The current "Sanguino" support is limited to the 644/644P,
The 1284/1284P are pin compatible.
Also there are now multiple Arduino pin # mappings for these chips.
The is a core that defines multiple variants:
"standard", "bobduino", "avr_developers" for the 644 and 1284.
Here is the site for the mighty-1284p core: 
http://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/
https://github.com/maniacbug/mighty-1284p

The board, core, and variant information is not available
but for this situation there is a kludge to determine which variant
is in use:

If analogInputToDigitalPin is not defined then it is 
the old/original/current Sanguino mappings.

If it is defined,
You can look at the result of analogInputToDigitalPin(0)
If it is 31 then you using the "avr_developers" pin mapping.
If it is 24 then you are using the "standard" pin mapping.
If it is 21 then you are using the "bobduino" pin mapping.

So when 1284 support is added all three (really 4) variants will be supported
as well.

What steps will reproduce the problem?
1. Try to compile any example sketch with Arduino 1.0
2.
3.

What is the expected output? What do you see instead?
I expect it to compile and report the size. It doesn't. Tons of errors.

What version of the product are you using? On what operating system?
GLCD 20110423, Arduino 1.0

Please provide any additional information below.
I tried changing the WProgram.h in the example sketch to Arduino.h, still won't 
compile

Since the library was never built on an OS that supports lower case,
some of the doxygen filenames or references have errors in them when trying
to build the documentation on linux.

These are typically references to .jpg vs .JPG 

Currently there is a mix of case.
For consistency it would be best to use all lower case for the filenames.

The files with incorrect case need to be renamed
and the the .dox files need to be gone through to fix all the references
to ensure they match (all lower case).

It would be nice to add support for carriage return <CR> character.
Currently, there is support of newline which implies a carriage return.
Carriage return support would move the text cursor to column 0.
It would not erase to end of line like newline, but simply move the
cursor.
This allows easy over-strike capability without having to use
cursor positioning calls.

I have added support for Philips PCD8544/Nokia 3310/Nokia 5110 Display. It 
works fine on Arduino Nano with Demo-Code. Other platforms as Arduino needs 
shiftOut to be implemented.

Originally entered by mem:

list of potential target controllers:
- HX8218A  (sparkfun LCD-08490)
   http://www.sparkfun.com/datasheets/LCD/LCD-TFT.pdf
   http://lcd-module.de/eng/pdf/zubehoer/hx8218a.pdf

Originally entered by mem:
nokia 6610 128x128 color  (sparkfun lcd-00569, lcd08600)
aka 6100,7210, 7250, and 5100.
http://www.sparkfun.com/commerce/product_info.php?products_id=569
http://www.sparkfun.com/tutorial/Nokia%206100%20LCD%20Display%20Driver.pdf

note that this display is write only and requires SPI

... does not appear in the TOC of the pdf file. It is also not Bold.

The Mega and Sanguino ks0108 Pin configuration files are missing
a reset pin configuation.
They just need a commented out pin for reset like what
is in the Arduino and Teensy pin configuration files.

Originally entered by mem:

 List of possible target controllers:
  - nokia 6610 128x128 color  (sparkfun lcd-00569, lcd08600)
  - kent Display 240x160  (sparkfun lcd-09560)

note prototype device code has been added to the debug directory - see 
glcd_Device_6610.cpp. The only other change required to current GLCD code is 
the addition of the following two public fields in glcdDevice.h 
  uint8_t ForeColor;
  uint8_t BackColor;

GLCDDiags should report which version of Arduino was used to build it.
It is a simple define that can be printed.

Originally Reported by project member bperrybap, Aug 4, 2010

Currently, there are some issues with boundary checking as not all the calls 
check for coordinates being out of bounds.

SetPixels() in particular falls victim of this as it does no checking and can 
attempt to read and write off the end of the display.

The is easily noticed by drawing a circle:
GLCD.DrawCircle(0,0,63, BLACK);
You will see a few trash pixels as the DrawRoundRect() routine attempts
to draw its vertical and horizontal lines.

There is code in GotoXY() to prevent out of range parameters.
ReadData() only checks for X values out of range.
WriteData() checks for both but not in all code paths.
SetDot() does full checking.

Checking in SetPixels() is difficult as it is desirable to allow
part of a region to be set and part to be ignored if is off the screen rather 
than error off the entire request if any of it is off the screen. 

There are few ways to handle this and I will think about it some more
but my thinking at this point is to slightly modify how checking is done so 
that upper level functions like SetPixels() no longer have to check bounds if 
they don't want to.
This primarily affects the use of the Y coordinate. 
I think it will be best to handle it like the X coordinate.

The X coordinate is allowed to fall off the end of the display.
When off the display, all Reads return 0 and Writes are ignored.
The same should be true for Y values that are off the display.

This allows all the higher functions like SetPixels() to keep working
even when attempting to draw off the end of the display.

The Line Drawing routines already use this same mechanism for plotting.
Since SetDot() drops pixels off the display, lines can start or end off the 
display and still draw a partial line on the screen.


To make this happen, some changes will need to made to

GotoXY() to always track the X & Y coordinates even when they are off
the screen vs just ignoring the request.

ReadData() will need to also check the Y coordinate.

WriteData() will to also check the initial Y coordinate.

Doing this fix/change will prevent any/all higher level functions from ever 
having screen update issues due to out of bounds coordinates.
It also simplifies some of the logic, in some places.

But I still need to think about this, to see the implications on text scrolling 
& rapping and of course performance.

Currently, the glcd device level init code will hang if things
are not working properly or not wired correctly.

Should the init code be modified to support returning an error if
initialization fails (times on reset/busy status) rather than hang?

I have been working on a compatibility sketch to run lcd smartie using the 
matrix orbitall driver. 

The only way of displaying the symbol is to add it to a font and call it 
directly using 

 GLCD.Puts((char)127); //Where 127 is the char number on my font.

Is there a way of exteding the library to support non ASCII characters and/or 
to draw freely any pixel of the display?

Ability to slow down text output for easier reading when using long strings
or multi line output.
There are two possibilities:
- 1 slow down between every text character
- 2 delay before processing newlines.

Originally Reported by project member memargolis, Jul 21, 2010

Sparkfun 128x64 lcd-00257
http://www.sparkfun.com/datasheets/LCD/DS_S6B1713_R42.pdf

It would be nice to be able to control the display on/off function.
It is very simple to do and I would suggest using the same API functions
as the current liquidcrystal library:

display() and noDisplay()

for this functionality.

The GLCDdiags utility needs to be modified to report when
the users picks invalid pins (pins out of range) in the config files.

The function glcdpin2str() will need to know the board/chip in use
and check it. If it is out of range, the report (INVALID) as the
AVR pin number.

Prototype doubled the demo FPS rate. 
Also useful for 128x64 monochrome write only displays

Prototype program grew by 42 bytes (actual code is only about a dozen or so 
lines of code)

It would be nice to add ellipse capability. (Draw & Fill)
It would be better to fold/merge this in with the circle and rounded
rectangle code rather than a single separate routine.
Code for it is below. It does work:

void Plot4EllipsePoints(long CX,long  CY, long X, long Y, uint8_t color){
  GLCD.SetDot(CX+X, CY+Y, color); //{point in quadrant 1}
  GLCD.SetDot(CX-X, CY+Y, color); //{point in quadrant 2}
  GLCD.SetDot(CX-X, CY-Y, color); //{point in quadrant 3}
  GLCD.SetDot(CX+X, CY-Y, color); //{point in quadrant 4}
#ifdef TOFILL
// to fill rather than draw a line, plot between the points
  GLCD.DrawLine(CX+X, CY+Y, CX-X, CY+Y, color);
  GLCD.DrawLine(CX-X, CY-Y, CX+X, CY-Y, color);
#endif
}

void glcd::DrawEllipse(long CX, long  CY, long XRadius,long YRadius, uint8_t 
color) {
// portted the algorithm found at
// http://homepage.smc.edu/kennedy_john/belipse.pdf
// by John Kennedy

  long X, Y;
  long XChange, YChange;
  long EllipseError;
  long TwoASquare,TwoBSquare;
  long StoppingX, StoppingY;
  TwoASquare = 2*XRadius*XRadius;
  TwoBSquare = 2*YRadius*YRadius;
  X = XRadius;
  Y = 0;
  XChange = YRadius*YRadius*(1-2*XRadius);
  YChange = XRadius*XRadius;
  EllipseError = 0;
  StoppingX = TwoBSquare*XRadius;
  StoppingY = 0;

  while ( StoppingX >=StoppingY ) //first set of points,y'>-1
  {
    Plot4EllipsePoints(CX,CY,X,Y,color);
    Y++;
    StoppingY=StoppingY+ TwoASquare;
    EllipseError = EllipseError+ YChange;
    YChange=YChange+TwoASquare;
    if ((2*EllipseError + XChange) > 0 ) {
      X--;
      StoppingX=StoppingX- TwoBSquare;
      EllipseError=EllipseError+ XChange;
      XChange=XChange+TwoBSquare;
    }
  }
  //{ first point set is done; start the 2nd set of points }

  Y = YRadius;
  X = 0;
  YChange = XRadius*XRadius*(1-2*YRadius);
  XChange = YRadius*YRadius;
  EllipseError = 0;
  StoppingY = TwoASquare*YRadius;
  StoppingX = 0;
  while ( StoppingY >=StoppingX ) //{2nd set of points, y'< -1}
  {
    Plot4EllipsePoints(CX,CY,X,Y,color);
    X++;
    StoppingX=StoppingX + TwoBSquare;
    EllipseError=EllipseError+ XChange;
    XChange=XChange+TwoBSquare;
    if ((2*EllipseError + YChange) > 0 ) {
      Y--;
      StoppingY=StoppingY- TwoASquare;
      EllipseError=EllipseError+ YChange;
      YChange=YChange+TwoASquare;
    }
  }
}; //{procedure PlotEllipse}

When less than the full character height of pixels is scrolled,
There can be an issue with the newly created empty line.
This is because only the # of pixels scrolled will be colored.
For example. If the area starts off as white and the text
color is also white, the newly created empty text line after a scroll 
operation will not be colored BLACK for the full height of the character if
the area is scrolled less than the height of the rendered character during
a wrap operation.
The only way to fix this would be alter the code use a "move pixels"
rather than a scroll pixels, and then do a clear to end line immediately
after the move and line wrap.

Currently this only shows up when
there are are less than 2xheight pixels below the current Y coordinate to
the bottom of the text area
and the current background of the pixels below the current text line
matches the text color
and  a wrap was just completed.

After a full row of text is printed, the issue will resolve itself.

Originally Reported by project member memargolis, Jul 21, 2010

All electronics 256x128 (lcd-101)
Datasheet: http://www.warc.org.uk/cdg2000/chip_datasheets/dave's_lcd/sed1330.pdf

Avrio needs to be updated to support atomically updating
nibbles atomically. The code will save the SR mask interrupts.
set the i/o bits, then restore the SR.

Sed1520_Custom_Config.h was deleted in R330. The current documentation still 
refers to that file.

If a suitable generic file sed1520 file does not exist, a new one should be 
created based on the modvk5121 file

The doxygen information for DrawRoundRectangle() is incomplete.
It contains some "FIXME" comments that show up in the final HTML documentation.

In both your HTML and pdf versions of GLCD documentation, the connection 
diagrams or the connection table has a wiring error.  The chip select lines in 
the "KS-108 Pin Connections Table" is opposite what is shown in the Connection 
Diagram for panel B (and C). The chip select lines are reversed in one of 
these.  Which is correct - the table or the diagram? 

When the code was updated for vertically stacked chips in rev r341
a needed update to the panel config files was not done.

The #define for glcd_CHIP_COUNT in all the panel configuration files
needs to be updated to the following:

#define glcd_CHIP_COUNT (((DISPLAY_WIDTH + CHIP_WIDTH - 1)  / CHIP_WIDTH) * 
((DISPLAY_HEIGHT + CHIP_HEIGHT -1) / CHIP_HEIGHT))

It would be nice to have GLCDdiags report if the DISPLAY_WIDTH
has been truncated from 256 pixels down to 255 pixels.

Currently this is a simple drop in update as the define DISPLAY_WIDTH
is redefined and there is no way for GLCDdiags to know its original value.

This will have be handled slightly differently or else a new define
created to be able to tell the difference between the original
DISPLAY_WIDTH and the final value.

The docs: readme.txt and the doxygen ks0108 migration need a few
updates for transitioning.

They need to indicate how to get new glcd library up if old ks0108 release is 
installed.
- Remove old ks0108?

They should describe where to copy custom fonts & bits files to
make sure that they work with the new library

How to get custom fonts & bitmaps to show up in
the allfonts.h and allbitmaps.h header files.

There was a comment relating to the default "atomic" mode
of the library.
It is a good question.
Should the default be atomic or non-atomic nibbles?

It can easily be argued either way.

The "safest" and most "reliable" mode is obviously "atomic".


This issue is a reminder to make a final decision as to
what the default state should be.

Reported by project member bperrybap, Mar 30, 2010

I think it would be really helpful to point people
to some places where they can get free fonts.
We can add some web links to the documentation.

Also I think it would be useful to show people how to use
symbol/dingbat fonts instead of icons.

Here are some places to get free fonts.
http://www.dafont.com/  (lots of really good symbol/dingbat and bitmap fonts)

http://www.1001freefonts.com/bitmap-pixel-fonts.php