SetBit in GLCD

[Anonymous]

Okay, I feel like a total idiot, but I can't for the life of me set a bit on the right side of the screen in a GLCD. Yes, I know about the CS1 and CS2 dyslexia, but it makes no difference how I assign them. I can set bits on the left (63 and below, x-axis) but from 64 to 127 they always get translated back to the left.

I'm only doing this in PicSim right now, although I just got a real unit a day ago.

What in the heck am I forgetting?

Here's the code. It's supposed to set (127,63) but ends up setting (63,63):

;----- Configuration

#chip 16F88, 8          ;PIC16F88 running at 8 MHz
#config mclr=off        ;reset handled internally
#config osc=int         ;use internal clock

#include <GLCD.h>

;----- Constants

#define GLCD_RW PORTA.0  
#define GLCD_RESET PORTA.1 
#define GLCD_CS1 PORTA.2 
#define GLCD_CS2 PORTA.3 
#define GLCD_RS PORTA.4  
#define GLCD_ENABLE PORTA.6 
#define GLCD_DB0 PORTB.0 
#define GLCD_DB1 PORTB.1 
#define GLCD_DB2 PORTB.2 
#define GLCD_DB3 PORTB.3 
#define GLCD_DB4 PORTB.4 
#define GLCD_DB5 PORTB.5 
#define GLCD_DB6 PORTB.6 
#define GLCD_DB7 PORTB.7 

#define GLCD_TYPE GLCD_TYPE_KS0108
#define GLCD_WIDTH 128
#define GLCD_HEIGHT 64

;----- Program
'
InitGLCD
GLCDCLS

PSet(127, 63, on)

[Chuck Hellebuyck]

Worked for me.
I modified it to draw two lines.
One at Y direction row 25 and a second at row 30.
I then for looped one half the screen (0-63) and then the other half (64-127).
Picture is below.

Everything worked as expected except for switching the CS1, CS2 pins so they were positioned correctly.

;----- Configuration

#chip 16F886, 16         ;PIC16F886 running at 8 MHz
#config mclr=off        ;reset handled internally
#config osc=int         ;use internal clock

#include <GLCD.h>

;----- Constants

#define GLCD_RW PORTA.0
#define GLCD_RESET PORTA.1
#define GLCD_CS1 PORTA.2
#define GLCD_CS2 PORTA.3
#define GLCD_RS PORTA.4
#define GLCD_ENABLE PORTA.6
#define GLCD_DB0 PORTB.0
#define GLCD_DB1 PORTB.1
#define GLCD_DB2 PORTB.2
#define GLCD_DB3 PORTB.3
#define GLCD_DB4 PORTB.4
#define GLCD_DB5 PORTB.5
#define GLCD_DB6 PORTB.6
#define GLCD_DB7 PORTB.7

#define GLCD_TYPE GLCD_TYPE_KS0108
#define GLCD_WIDTH 128
#define GLCD_HEIGHT 64

;----- Program
'
InitGLCD
GLCDCLS
main:
For xdir = 0 to 63
PSet(xdir, 25, on)
next
For xdir = 64 to 127
PSet(xdir, 30, on)
next
goto main

[Anonymous]

Okay, I give up. I had some interesting graphic routines for the GLCD, but have wasted three days just trying to set a single pixel on the right half of the screen. Without that, I can't proceed. It's probably something simple, but I sure don't see it. Time for a different project.

[Chuck Hellebuyck]

You sure your code isn't working?
Your trying to position right at the edge of the LCD.
It shows up in my simulator but almost off screen.
I set two pixels; one pixel on the left in the middle of the screen and then a second per your x,y settings and you can barely see it but its there in the lower right corner. Follow the arrow in my picture below.

[Anobium]

I have been away. Back now. :-) I don't have a KS0108. I am just writing a new driver for an alternative GLCD. Does anyone have one that I can test?

A few questions.
Does GLCDPrint work across the whole screen? I have to ensure the basic connectivity works first.
What version and date of the code do you have?

[Anonymous]

Oh, I can definitely see the pixel. As mentioned, it appears on the left half of the screen. So instead of (127,63) as requested, it appears at (63,63). Again, no matter if I swap CS1 and CS2. What in the heck am I missing?

The curious thing is that if I print one of MBB's circles, then the PSet works as expected.

I feel like an idiot...

[Anonymous]

And this is even more curious. With a single PSet, it screws up and prints on the left side. But thereafter, remaining PSets work as expected. To be specific:

PSet(64,63,on) prints at location (0,63)

but if I follow this with PSet(127,63,on) then that pixel shows up where it's supposed to be, at(127,63).

In other words, the first PSet is always incorrect for me, but everything thereafter seems okay. Remember, I'm using the simulator.

Any ideas?

[Anobium]

You are correct. There is a feature.... If you PSET at Xlocation 63.... you get nothing.

Try this. :-)

I now know there issue in the page select code in PSET. I have tried to sort this morning but I need a real set up to give me more debug capability.

I am working in GLCD on a set routine for another GLCD device.... So, I can have a look over the next few hours.

PSet(127, 63, on)
PSet(126, 63, on)
for xx = 63 to 63

  for yy = 1 to 63
    PSet(xx, yy, on)

  next

next
PSet(0, 63, on)
PSet(1, 63, on)
end

[Anobium]

Thinking about it a little more.

Before I spend any time on this - can someone please verify this issue on a real GLCD with a KS0108/KS0107 controller?

I can see the issue on a simulator but I need verification on a real device.

[kent_twt4]

Not a problem in hardware. This code shows pixels correctly in each corner of the pages.

PSet(0, 0, on)
PSet(63, 0, on)
PSet(64, 0, on)
PSet(127, 0, on)
PSet(0, 63, on)
PSet(63, 63, on)
PSet(64, 63, on)
PSet(127, 63, on)

[Anobium]

Just make me feel happy.....

Try this code at this link. http://sourceforge.net/p/gcbasic/discussion/579126/thread/5019359a/#0e79

[Anobium]

I meant this in a happy way.

[kent_twt4]

Well that was a little funny, I thought when I first programmed the code, that I was missing one of the Pset(1,63,on) or Pset(0,63,on) dots, so I commented the other dot out, it seemed fine then, then back to uncomment, and all was well.

There is the possibility that their is some sort of glitch, not sure. I've seen where multiple solid lines might skip a row, but when I tried previous code with the glitch, it wasn't there. So environmental situations then? like noise (I've got long wires 10-12"), poor connections on the breadboard, or something else coming into play?

[Anonymous]

I think we need to strip this down the barest essentials to gather information. So, let's all run a program that contains just the single PSet(127,63,on). Nothing else to complicate the issue. Then report your results here, and whether you're using a real device or simulated.

When I do it, pixel (63,63) lights. I'm using a simulator.

[kent_twt4]

Here's my take on the problem (Hardware). For no particular reason, other than cut and pasting code willy nilly, the following situation has occured:

InitGLCD
Start:
GLCDCLS
PSet(127, 63, on)
...

GLCDCLS does not reset the GLCD_CS1 and GLCD_CS2 lines to Off. The InitGLCD and Pset subs do reset the CSX lines to Off at the end of their procedures. So every time the "first" Pset command directly follows a GLCDCLS it double hits on both pages, because neither CSX is explicity turned off when it enters the page selection criteria. Of course every succeeding Pset is O.K. because they are turned off at the end of the procedure, at least until it hits another GLCDCLS.

Proposal for glcd.h header file:
1. Clear GLCD_CS1 and GLCD_CS2 lines at the top of the Pset procedure.
2. Clear GLCD_CS1 and GLCD_CS2 lines at the bottom of the GLCDCLS procedure.

[Anonymous]

Brilliant, Kent! In your sample, above, when I manually shut off CS1 and CS2 immediately after the GLCDCLS command, it works. So, I believe your assessment is correct.

It seems to me that the best place to fix the include file is in GLCDCLS. To put it another way, shouldn't it be the duty of each and every command to leave these control lines in the state in which they were originally found?

Thanks so much for finding this. I was feeling very stupid that I seemed to be the only having troubles.

[kent_twt4]

Clearing the CS lines at top of the Pset procedure could be repetitious. Haven't considered all possibilities interacting with other subs.

I commented on the stray, or extra pixel, when trying the circle formulas. Just didn't recognize where it came from.

[Anobium]

Interesting. I have been through the code and I can see no reason why setting the lines would improve the situation.

Currently PSET set the lines to low upon exit. However, something does attract my attention. The line state in PSET is not explicitly set upon page select. Try changing the following, find the sub Pset, then the section that looks like this - currently in your file they are all one line IF statements. Replace with the following code - this uses explicit statements.

    #if GLCD_TYPE = GLCD_TYPE_KS0108
        'Set pixel at X, Y on LCD to State
        'X is 0 to 127
        'Y is 0 to 63
        'Origin in top left

        'Select screen half
        If GLCDX.6 = Off Then
                       Set GLCD_CS2 On
                       Set GLCD_CS1 OFF
                    end if
        If GLCDX.6 = On Then
                       GLCDX = GLCDX - 64
                       Set GLCD_CS1 On
                       Set GLCD_CS2 Off
                    end if

        'Select page
        CurrPage = GLCDY / 8
                ....  .....

This code is in the new GLCD.H I have written for the alternative GLCD device so it would be good to get this tested. :-)

Let me know the results.

[kent_twt4]

I've gravitated to setting the CS lines to off in the GLCDCLS routine only. My mistake in previous post, the last line of InitGLCD is a call to GLCDCLS, so it not initialized properly to begin with. Case in point, maybe I don't start using Pset based routines,but go directly to GLCDWriteByte or some other non-pixel based routine. It's just not good starting off with both CS lines set.

Pset is only effected on first write, so clearing the opposing CS line at the top becomes redundant (could be hundreds of times so with the line command). I'm for leaving it in original form.

[Anobium]

Good point the lines are not set correctly. I will update GLCDCLS to set the lines correctly in the next release of GLCD.H. I am very close to releasing a new version with greater hardware support. A few days and I will post.