GLCD driver chip for Picaxe project - your input please

W

womai

Senior Member
In the past quite a few people have tried to use GLCDs with Picaxe, with mixed success. One issue I guess is the Picaxe's processing speed (or lack thereof) when driving the low-level GLCD interface. On the other hand there are serially interfaced GLCD but they tend to be pricey - given that you can pick up a decent parallel one for around US$15.

So I thought I'll create an interface driver chip for such a GLCD. I'm about two thirds done and it looks pretty good. Since Rev-Eds LED044 hasn't been available for quite a while I hope they don't mind. I plan to make the HEX file freely available so anybody with a PIC programmer can burn his/her own. If there is enough interest I may also offer pre-programmed chips for those who don't have that option. The chip is a simple PIC16F886 with minimal external components (running on its internal oscillator), i.e. the same as the Picaxe 28X1. It supports 128x64 pixel monochrome GLCDs that are based on Samsung KS017 or KS018 compatible controllers (this is a very common type anyway).

The Picxaxe talks to the driver through standard serial at 9600 baud.

At the moment it supports drawing of dots, lines, circles, rectangles, boxes (filled rectangles), and clearing the screen. Text output still needs a little debug. Here is a video of the current demo program running on a Picaxe 28X1 (needs only around 200 bytes of code space):

http://www.pdamusician.com/electronics/glcd01.avi

Please let me know if you are interested in further development of this, and also if you have any ideas for additional features (only thing to keep in mind, I am not planning to support any other GLCD controllers right now).

Wolfgang

P.S.: Here is the Picaxe demo program that is shown in the video, so you can see how the communication to the controller works:

Code: 
#PICAXE 28X1

symbol GLCD_DOT           = 0
symbol GLCD_LINE          = 1
symbol GLCD_V_LINE        = 2
symbol GLCD_H_LINE        = 3
symbol GLCD_RECTANGLE     = 4
symbol GLCD_BOX           = 5
symbol GLCD_CICRLE        = 6
symbol GLCD_FILL          = 7
symbol GLCD_SET_FONT      = 8
symbol GLCD_WRITE_CHAR    = 9
symbol GLCD_WRITE_TEXT    = 10

symbol FONT_5x8 = 0
symbol FONT_5x7 = 1
symbol FONT_3x6 = 2

symbol GLCD_TX_PIN = 0 ' output pin 0
symbol GLCD_RX_PIN = pin0 ' input pin 0
symbol GLCD_BUSY   = pin1 ' input pin 1

symbol GLCD_BAUDRATE = T9600_16

setfreq em16 ' to get to 9600 baud

for w0 = 1 to 4

    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_FILL, 255)
    pause 2000
    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_FILL, 0)
    pause 2000

next w0

w1 = 0x1234

for w0 = 1 to 1000
    random w1
    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_DOT, b2, b3, 1)
    'gosub wait_for_GLCD

next

pause 6000
gosub clear_screen

for b0 = 1 to 30 step 2

    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_CICRLE, 63, 32, b0, 1)
    gosub wait_for_GLCD
    
next

pause 6000
gosub clear_screen

for b0 = 0 to 63 step 7

    b1 = b0 + 63
    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_LINE, b0, 0, b1, 63, 1)
    gosub wait_for_GLCD
    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_LINE, b1, 0, b0, 63, 1)
    gosub wait_for_GLCD

next

pause 6000
gosub clear_screen

for b0 = 0 to 63 step 5

    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_H_LINE, 0, 127, b0, 1)
    gosub wait_for_GLCD

next

pause 6000
gosub clear_screen

for b0 = 0 to 110 step 10

    b1 = b0 / 2
    b2 = b0 + 15
    b3 = b1 + 7
    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_RECTANGLE, b0, b1, b2, b3, 1)
    gosub wait_for_GLCD

next

pause 6000

for b0 = 0 to 110 step 10

    b1 = b0 / 2
    b2 = b0 + 15
    b3 = b1 + 7
    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_BOX, b0, b1, b2, b3, 1)
    gosub wait_for_GLCD

next

pause 6000
gosub clear_screen

end

wait_for_GLCD:

    do
    loop while GLCD_BUSY > 0
    
    return
    
clear_screen:

    serout GLCD_TX_PIN, GLCD_BAUDRATE, (GLCD_FILL, 0)
    gosub wait_for_GLCD
    pause 100
    
    return
 
Last edited:
W

womai

Senior Member
When I have everything working, I may look into I2C as well. Although that's going to be a bit of work since I haven't used I2C with my C compiler yet (actually I tried once, but wasn't very successful - more debug needed). These are the moments where one comes to appreciate how easy the Picaxe makes one's life :)

As for the serial baud rate, I figured 9600 is a good choice because even the 08M can drive that (using sertxtd and overclocking to 8 MHz). If it should become a bottleneck I will add a jumper option to select faster baud rates, but right now it seems the GLCD is the slow part of the system, not the serial connection.

Wolfgang
 
C

Cosmic Software

Member
This looks absoloutely superb, and I cannot wait to see text. I cannot comment on how hard/easy it would be, but is there any possibility of different sized fonts? This would open up so many more options when working with GLCDs with Picaxe.

So far, I have only used Picaxe with the GLIC-K1 graphics interpretor IC (the one used in LED042). It has a couple of other nice features such as graphs, and images that it reads from EEPROM. These are probably harder than the other features, so would maybe make a late appearence in a version 2?

Anyway, I love it!
 
K

kevrus

New Member
Womai, this is superb work, something that many will find useful...I agree with Cosmic, the facility to download images and text strings straight from the PC and store in eeprom is very useful.
 
W

womai

Senior Member
At the moment fonts are limited to 3x6, 5x7 and 5x8. That's how much I could stuff into the EEPROM (and incidentally all three are standard library fonts that come with my compiler :)

The compiler has the option to store pictures in EEPROM but that would take away font space, and more importantly it has to be done at compile time. So that's no good.

So for both suggestions I'll think about adding an external I2C EEPROM (24LC512 or similar) where you can download this data to. Although that will break the "as simple as possible" concept since it adds another chip, but it will add much more storage than the internal uC has. On the upside, it would force me to get I2C working :)

Right now there is very little space left in the PIC16F886, but I can always move it to an PIC18F2520 if that becomes an issue.

Wolfgang
 
C

Cosmic Software

Member
womai said:
I'll think about adding an external I2C EEPROM (24LC512 or similar) where you can download this data to. Although that will break the "as simple as possible" concept since it adds another chip, but it will add much more storage than the internal uC has. On the upside, it would force me to get I2C working :)
Click to expand...
Although the inclusion of an EEPROM chip would mean that the circuit would not be 'as simple as possible', it would not be an essential component for the propper functioning of the driver. It would be an option for anybody who wanted to include the use of images.
Chances are, for any project using a GLCD, it will also include EEPROM (I know that my two projects with GLCDs have). I appreciate you may want to avoid interfacing the driver to the Picaxe through I2C, however, you could argue that it would simplify the circuit by reducing the pin consumption for the Picaxe if I2C is already being used. The only downside is that chips such as the 08M do not support it.

womai said:
Right now there is very little space left in the PIC16F886, but I can always move it to an PIC18F2520 if that becomes an issue.
Click to expand...
The GLIC-K1 which appears to be a similar driver IC is based on the PIC18F2520, and that is understandable simply because of the increased capacity, however, that PIC is double the price of the PIC16F886. Others may have a different oppinion, however, for me, I begrudge paying more for single devices rather than maybe having a few extra components (even if the overall cost is the same)! Having said that, if there is not enough room on the current PIC for all of these new ideas that I seem to be suggesting, then what else can you do, other than to restrict functionality?
 
W

womai

Senior Member
There are other issue with downloading an image than just storage space in the uC. First, you need a program to convert a bitmap file on the PC into a data array that the GLCD can use (the bitmapping structure is very different in a BMP file compared to the GLCD). My compiler IDE has such a tool and a demo of the compiler is available as free download, but that's a large download for a small tool. To write one would be extra effort. Also, I'd need to figure out how to self-write in program memory and also how to retrieve that data during run time. Can be done of course, but will be quite some learning effort, and I'm pretty busy already with some other projects. So most likely won't get done in the first incarnation of the GLCD driver chip. Right now my goal is to put something together quickly that is useful but does not take a huge effort.

How many people are interested in bargraphs / block diagrams? I was thinking of at least adding rectangles with selectable hatching (rather than just empty and filled rectangles as of now), that way anyone can easily build such graphs.

Wolfgang
 
M

manie

Senior Member
Wolfgang: For me, not pretty pictures but bars/line/scatter graphs that can be anotated at the data point would be great. Text in 3 sizes sounds good because this gives you a LOT more screen real estate than a small 16 x 2 or 20 x 4 LCD. I will be interested...
Manie
 
Last edited:
N

nbw

Senior Member
Sounds like a great idea, good work to date. A basic set of fonts would be a good standard, and users should for themselves be able to add 'extras' such as 'degrees C' or custom symbols - if they can easily plot points, they could probably create a small number of 'add-on's themselves.

I look forward to seeing how you get on! Kind regards, Barney
 
W

womai

Senior Member
Andrew Cowan said:
Is there any chance of it supporting larger LCDs?

Andrew
Click to expand...
Not in the near future. K0107 controlled GLCD normally don't come in anything larger anyway. My compiler does have a library for the Toshiba T6963 controller which allows for different screen sizes (e.g. 128 x 128) but that would be a different controller and thus a different project. Also IMHO many Picaxe users are on a limited budget and thus I doubt there would be too many takers for anything costly - T6963 displays tend to cost a lot more than K017 ones. If I am mistaken let me know.

Wolfgang
 
Last edited:
H

HAZELEB

Member
Hi Wolfgang, The prospect of another GLCD firmware chip sounds great, have you decided on the chip to use? Looking for would to any progress reports,

Ps. Will I be able to program the hex files with pickit2?

Regards

Ted
 
W

womai

Senior Member
If your Pickit2 can handle 28 pin devices the you should be able to use it (I have no experience with it).

Most of the basic functionality is working now on a PIC16F886, including writing text. The reason I haven't posted anything is that I ran into some issues with the serial connection related to the fact that the Picaxe's outputs come up in their low state. I may have to move to a PIC18F2540 where I can invert the receive data to deal with that (otherwise I'd have to add additional hardware, which I don't want to). Right now I am in the middle of two other major development projects, one of them with a tight schedule, so I had to put this on the backburner for now. Also I'll be traveling for a few weeks, so don't expect any great progress for the next month and a half.

If there is interest I can post my source code so other people can work on it until I come back. There really isn't any rocket science involved, it's mostly calling the GLCD routines that come with the compiler. You can compile it with Mikroelektonika's MikroC compiler which is available as a free download (compiled code size limited to 2 KByte but should be good enough to at least work the bugs out). Let me know if anybody wants to do that.

Wolfgang
 
N

nbw

Senior Member
Added: bargraphs etc, would be pretty handy. Like 10-LED DIL arrays, even, except able to make use of the 64 pixel height. Just a thought :)
 
W

womai

Senior Member
My own GLCDs are just as patiently sitting on the bench waiting to be used again for this project :) Unfortunately right now I have my plate more than full with other electronic developments - mostly non-Picaxe related; I also just released my new hobby scope design which will take some more time in order to finish up hardware and software documentation etc. That one may actually be of interest to Picaxe users (see http://www.dpscope.com for details, but note that the webpage is still very much work in progress)

Still hope to get back to the GLCD at some time, but probably not in the next few months.

Wolfgang
 
You must log in or register to reply here.
Top