Beta version of GLCD library version 3

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

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.

Hi!

Thank you for this library update.

Fixed all my problems with mega and GLCD. I was having problems drawing in glcd in a single screen "sweep". It always showed missing pixels, and after a while on the sketch running without any input, it started to add random dots in screen. I had already checked my wiring, but didn't fix it.

Now, just changed the library to this one, and my sketch worked almost out of the box (probs with drawvertline and drawhorizline).
Now I draw the screen correctly with one single pass and no more annoying dots showing up after a while.

Thank you, great work!

By the way, you have said that colour GLCD will be supported in future.

I've bought this one:
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=190346231315&ssPageName=STRK:MEWNX:IT

It uses SSD2119 controller.

Do you think that this screen can be included in the GLCD library?

Right now I'm building my project on the 128x64, but in the future I want to move into this higher resolution screen.

FEEDBACK:
I wanted to ask that if it's possible to update library to leave i2c ports alone on Arduinos? Analog Port 4 used for glcdEN and blocking i2c communication. Isn't it better to have i2c ports working with GLCD library? Since there is port 12 available for the job?

I think I2C port is still useable if we share it with i2c If only we pull SCL (Analog port 5) low while we don't use I2C port...
i2c bus require START or STOP signals requires SCL is high (which is idle state of i2c port). Git this might be complex. Instead we can put a definition if wire library used, we could drive low SCL port, this automates the sharing port... This is also true for slave devices because they allowed to drive SCL low (clock skew) for make some jobs internally. So Port 4 sharing mechanism or moving Analog Port 4 to DigitalPort 12 is good movement I think.

SPEED PROBLEM:
It's weird thing happening on GLCDDemo code. When I compile this for run 16Mhz CPU, It's run 15.08 fps. but When I change XTAL with 20 MHZ speed gets low! How could it be?
Also if you compile program for 20Mhz CPU speed, it runs faster on same 16Mhz XTAL. It's not comes logic to me... Any ideas about it?
Speed table:

| Code Compiled For | | XTAL Speed | | GLCDDemo FPS |
| - | - | - |
| 16Mhz | | 16Mhz | | 15.08 |
| 16Mhz | | 20Mhz | | 13.46 |
| 20Mhz | | 16Mhz | | 18.56 |
| 20Mhz | | 20Mhz | | 16.87 |

Notice, I also updated 20Mhz delayMicrosecond function hack. So, on 20Mhz compilation, delayMicrosecond function waits same time as 16Mhz variant (off course when you use 20Mhz Xtal )

You can configure the pins to whatever you want without changing the library. The pin assignment used in the configuration files in the download are for backward compatibility with the first version of the library so users don't have to rewire a working system when upgrading software.

But if you want to reconfigure to free up the i2c pins you can make that change – note however that using pin 12 would conflict with SPI. There are no 'free' pins on a standard arduino board.

The glcd library does not use delayMicroseconds. It use the Arduino delay function for millisecond delays and a routine in delay.h for nanosecond delays. Both these functions take the #define for CPU speed into account.

The smaller than expected increase in performance you are seeing when running on 20Mhz is due to the limitation of the GLCD performance. The library checks to see if the controller chip is ready before doing IO to the GLCD controller chip.

I think pin SPI is already blocked since Pin 11 and 10 required for SPI. Anyway, I think you missed the point about weird fps... There is no increase with using 20Mhz xtal that I wanted to say.

With 16mhz Xtal, I got higher FPS, with 20Mhz Xtal, I got lower fps. Independent from compilation of code for CPU speed. Please look the table again. It comes weird to me...

Anyway, I think you missed the point about weird fps... There is no increase with using 20Mhz xtal

With 16mhz Xtal, I got higher FPS, with 20Mhz Xtal, I got lower fps

Code Compiled For | XTAL Speed | GLCDDemo FPS
16Mhz | 16Mhz | 15.08
20Mhz | 20Mhz | 16.87

It looks to me like you are getting a 10% increase in speed when using the 20Mhz crystal. The reason why the increase is not proportional was given in my previous post.

E.U.A,
I assume you meant the middle 2 entries. (#2 and #3 in this list)

Code Compiled For        | XTAL Speed | GLCDDemo FPS
1)            16Mhz       | 16Mhz       | 15.08
2)            16Mhz       | 20Mhz       | 13.46
3)            20Mhz       | 16Mhz       | 18.56
4)            20Mhz       | 20Mhz       | 16.87

Those do look odd. But it is hard to tell exactly what you have done.

You appear to be intentionally compiling code with the F_CPU set incorrectly, which will generate incorrect delays.
Is that what you did? How exactly did you build the images?

That said, I would have expected to see the FPS results for #2 & #3 to be reversed, assuming there was no change in configuration
and the display is still functioning properly showing
a proper looking FPS display.

Are you sure the FPS values for #2 and #3 are not swapped?

In the case of #2, compiling with F_CPU set to 16mz but running the processor at 20mz
will cause delays to be shorter than #1 and all the rest of the
code should be a little bit faster as well. Even if the h/w polling
erases some of the shortened delays I would not expect #2 to be slower
than #1.

For #2 are you saying you used the exact code image from #1
on the same processor using the exact same glcd (not same model, but the very same one) with the exact same pin configuration (no recompile, no new download?) and the only change between #1 and #2 is simply replacing the crystal with a 20mz?

And for #3, same thing as above, with respect to #4
with no recompile and no new download no changes, simply swapping crystals?

If so, then I agree something odd is happening.

But I have seen some odd things in the past. For example,
sometimes if the timing is just right, running a bit slower can
actually yield faster results. This is because when the timing is
just right, the code will test a hardware flag and not have to
spin on it because it is already ready. In that case you save a
loop iteration and save a few clocks. But normally it is very
rare to see this. And in the case of jumping from 16mz to 20mz
I would think that the rest of the code would make up for that.

Looking forward to getting more details on this.

--- bill

Clearly #1 and #2 is same HW, same FW, same GLCD, same configurations, pins, etc... everything. I just remove 16Mhz Xtal and replaced it with 20Mhz one and FPS drops down.

Same applies to #3 and #4... But FW is compiled for 20Mhz.
I am sure that my F_CPU is correct for the configurations. But if even I set it wrong, I use same FW on config #1&2 and #3&4....

E.U.A,

Like Bill said - maybe answer is in display's speed and processor and LCD timing?
2) compiled for 16MHz but run on 20MHz - "slower" version is run faster and when processor is checking if LCD is ready - it's not ready and processor need to wait. More often it check and miss - more clocks it lose.
3) faster version run on slower clock - better hit ratio :wink:

Do you have another LCD?

robin

It may have something to do with the fact that when compiled for 16Mhz and running with a 20Mhz crystal, the timer that drives millis is overflowing 25% faster than the code expects. That means that there is less time to draw the frames, resulting in a lower FPS than if the clock doing the timing was accurate.

Anyway, my reccomendation is to avoid setting it wrong :wink:

Yes, I thought that and come to write here :slight_smile:

If I compile code with 16Mhz, CPU counts 16M for a second...
But If I use 20 Mhz at this setup, its again count to 16M and it takes less than a second, but cpu thinks it's a second. So it's actually it prints frame per %80 of second... So it's lower than expected.

Code 16Mhz | Xtal 20Mhz | fps 13.46
With basic math
13.46 * 20 / 16 = 16.825, It's really close to 20Mhz code with 20Mhz Xtal setup, 16.85 fps. :slight_smile:
Thanks

If I run this library with a Sure Electronics 128 x 64 display I get nothing on the screen,

Diagnostics program gives me :-

------------------------------------------Serial initialized

GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
Panel Configuration:ks0108
Pin Configuration:ks0108-Mega

GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
CSEL1:33(PIN_C4) CSEL2:34(PIN_C3)
RW:35(PIN_C2) DI:36(PIN_C1) EN:37(PIN_C0)
D0:22(PIN_A0) D1:23(PIN_A1) D2:24(PIN_A2) D3:25(PIN_A3)
D4:26(PIN_A4) D5:27(PIN_A5) D6:28(PIN_A6) D7:29(PIN_A7)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(33,0x1, 34,0x0) CHIP1:(33,0x0, 34,0x1)
Data mode: byte

Diag Loop: 1
Initializing GLCD

Any ideas please?

can you change the contrast of the pixels when you adjust the pot?

Have you tripple checked that all the wires are connected correctly?

Weird - rebuilt it 3 times and was getting the same result. did it again and now it works. Something must be loose somewhere I think, maybe on the Mega.

Works fine now. Thanks!!

i have to use the library with pin_J3 to pin_J7
but it doesn't work. maybe is the conversion from pin to number because diag response with:

Serial initialized
--------------------------------------------------------------------
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
Panel Configuration:ks0108-Manual
Pin Configuration:ks0108-Manual
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
 CSEL1:67(PIN_K5) CSEL2:68(PIN_K6)
 RES:69(PIN_K7) RW:65(PIN_K3) DI:64(PIN_K2) EN:66(PIN_K4)
 D0:62(PIN_K0) D1:63(PIN_K1) D2:50(PIN_J2) D3:51(PIN_J3)
 D4:53(PIN_J5) D5:52(PIN_J4) D6:54(PIN_J6) D7:55(PIN_J7)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(67,0x1, 68,0x0) CHIP1:(67,0x0, 68,0x1)
Data mode: 
 d0-d3:bit i/o
 d4-d7:bit i/o
--------------------------------------------------------------------
Diag Loop: 1
Initializing GLCD

where it's visible than the conversion of portJ pin is wrong... :cry: :cry:

how i can correct this error?

i have modified the pins_arduino.c :http://www.seeedstudio.com/forum/viewtopic.php?f=4&t=380&start=10

but i can't see anything...

Serial initialized
--------------------------------------------------------------------
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
Panel Configuration:ks0108-Manual
Pin Configuration:ks0108-Manual
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
 CSEL1:67(PIN_K5) CSEL2:68(PIN_K6)
 RES:69(PIN_K7) RW:65(PIN_K3) DI:64(PIN_K2) EN:66(PIN_K4)
 D0:72(PIN_L7) D1:73(PIN_L7) D2:74(PIN_L7) D3:75(PIN_L7)
 D4:76(PIN_L7) D5:77(PIN_L7) D6:62(PIN_K0) D7:63(PIN_K1)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(67,0x1, 68,0x0) CHIP1:(67,0x0, 68,0x1)
Data mode: 
 d0-d3:bit i/o
 d4-d7:bit i/o
--------------------------------------------------------------------
Diag Loop: 1
Initializing GLCD
Displaying ChipSelect Screens
Walking 1s data test
 Compare error: 0 != 1
 Compare error: 0 != 2
 Compare error: 0 != 4
 Compare error: 0 != 8
 Compare error: 0 != 10
 Compare error: 0 != 20
TEST FAILED

Can you post your config file? I'd like to see exactly which pins you are wanting to use to be able to figure out what is going on.
Also, what version of the IDE are you using?

From the diag output I can't tell what you wanted vs what you got -
i.e. nothing looks out of the ordinary in the first diag output because I
can't tell what is in your config file.
The second one looks odd but it seems to be different from the first.

I'm not exactly sure what you have edited in your arduino pins
file, but the glcd library does not use the standard arduino pin mapping
functions. It does its own mapping, as this is MUCH faster than the
arduino routines since it is all done at compile time vs runtime.

BTW, if you want to remove the Arduino pin # mapping
from the equation,
you can use PIN_Pb notation in the config file
to explicitly specify AVR pins rather than use Arduino pin #s.

So PIN_J3 is port J bit/pin 3

--- bill

Ok, quick note.
The glcd library does its own pin mappings.
It does not use any of the arduino core routines or its
look up tables.
This is done to compile the code down to direct pin i/o
which is dramatically faster than the Arduino routines.

The highest pin # supported by the standard Arduino core
(which is mirrored in the glcd library routines) is 69.
So any attempt to use a pin # higher than this will fail.
Unfortunately, it fails in a non graceful way by generating incorrect code.

For the time being a work around for this, is to use
PIN_Pb notation in your glcd config file to configure your pins
rather than patching your arduino pins file
and using non standard arduino pin #s since the glcd library
will not use the patched arduino pins file.

This should resolve the issue.

NOTE: PIN_Pb notation is implemenated by the glcd library code and
is not supported by the normal arduino core library.

Diags will report incorrect Arduino pin #s for these pins
(it will report internal AVRIO AVRPIN numbers instead)
but the AVR pin reported in PIN_Pb format should be correct.
The low level code will be using the reported PIN_Pb pin
so that is what matters.

Try switching your higher pin #s to PIN_Pb notation
and let me know if it fixes your issue.

In the mean time, I'll go look around and see if there is any
sort of plan or consensus on the arduino pin numbering of these
additional pins.
If so, the glcd library can update its mappings to include these
higher numbered mappings.

--- bill

this is the result of adding pin mapping:

the errors reduce to:

Serial initialized
--------------------------------------------------------------------
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
Panel Configuration:ks0108-Manual
Pin Configuration:ks0108-Manual
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
 CSEL1:67(PIN_K5) CSEL2:68(PIN_K6)
 RES:69(PIN_K7) RW:65(PIN_K3) DI:64(PIN_K2) EN:66(PIN_K4)
 D0:72(PIN_J2) D1:73(PIN_J3) D2:74(PIN_J4) D3:75(PIN_J5)
 D4:76(PIN_J6) D5:77(PIN_J7) D6:62(PIN_K0) D7:63(PIN_K1)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(67,0x1, 68,0x0) CHIP1:(67,0x0, 68,0x1)
Data mode:
 d0-d3:bit i/o
 d4-d7:bit i/o
--------------------------------------------------------------------
Diag Loop: 1
Initializing GLCD
Displaying ChipSelect Screens
Walking 1s data test
 Compare error: 44 != 4
 Compare error: 44 != 40
TEST FAILED

from this stamp the pin mapping is exact

the modified part is: (arduino_io.h)

#elif defined(__AVR_ATmega1280__)
      // Arduino Mega Pins
#define digitalPinToPortReg(P) \
    (((P) >= 22 && (P) <= 29) ? &PORTA : \
      ((((P) >= 10 && (P) <= 13) || ((P) >= 50 && (P) <= 53)) ? &PORTB : \
    (((P) >= 30 && (P) <= 37) ? &PORTC : \
      ((((P) >= 18 && (P) <= 21) || (P) == 38) ? &PORTD : \
      ((((P) >= 0 && (P) <= 3) || (P) == 5) ? &PORTE : \
    (((P) >= 54 && (P) <= 61) ? &PORTF : \
      ((((P) >= 39 && (P) <= 41) || (P) == 4) ? &PORTG : \
      ((((P) >= 6 && (P) <= 9) || (P) == 16 || (P) == 17) ? &PORTH : \
      ((((P) >= 14 && (P) <= 15) || ((P) >= 72 && (P) <= 77)) ? &PORTJ : \
    (((P) >= 62 && (P) <= 69) ? &PORTK : &PORTL))))))))))
#define digitalPinToBit(P) \
      (((P) >=  7 && (P) <=  9) ? (P) - 3 : \
      (((P) >= 10 && (P) <= 13) ? (P) - 6 : \
      (((P) >= 22 && (P) <= 29) ? (P) - 22 : \
      (((P) >= 30 && (P) <= 37) ? 37 - (P) : \
      (((P) >= 39 && (P) <= 41) ? 41 - (P) : \
      (((P) >= 42 && (P) <= 49) ? 49 - (P) : \
      (((P) >= 50 && (P) <= 53) ? 53 - (P) : \
      (((P) >= 54 && (P) <= 61) ? (P) - 54 : \
      (((P) >= 62 && (P) <= 69) ? (P) - 62 : \
      (((P) == 0 || (P) == 15 || (P) == 17 || (P) == 21) ? 0 : \
      (((P) == 1 || (P) == 14 || (P) == 16 || (P) == 20) ? 1 : \
      (((P) == 19 || (P) == 72) ? 2 : \
      (((P) == 5 || (P) == 6 || (P) == 18 || (P) == 73) ? 3 : \
      (((P) == 2|| (P) == 74) ? 4 : \
      (((P) == 76) ? 6 : \
      (((P) == 77) ? 7 : \
      ((((P) == 3 ||(P) == 75) || (P) == 4) ? 5 : 7)))))))))))))))))

the error correspond to errors in pin mapping or other?

my config file:

/* Data pin definitions
 */
#define glcdData0Pin        72
#define glcdData1Pin        73
#define glcdData2Pin        74
#define glcdData3Pin        75
#define glcdData4Pin        76
#define glcdData5Pin        77
#define glcdData6Pin        62
#define glcdData7Pin        63

/* Arduino pins used for Commands
 * default assignment uses the first five analog pins
 */
#define glcdCSEL1        67
#define glcdCSEL2        68
// uncomment the following if more than two chip select pins are needed
//#define glcdCSEL3        3   // third chip select line on pin 3 if needed
//#define glcdCSEL4        2   // fourth chip select if needed

#define glcdRW            65
#define glcdDI            64
#define glcdEN            66
// Reset Bit  - uncomment the next line if reset is connected to an output pin
#define glcdRES           69  // Reset Bit