ks0108b/ks0107 controller combo

Status
Not open for further replies.

desaila

New Member
I was googling for some tutorials on how to interface this particular glcd with a PIC18F452, and I came across a few threads in here. I started digging through the forum and came across that Unicorn example from Pommie, and I read through it and realized he was using a ks0108, not a ks0108b. Is the b version that different where if I were to port his code to an 18F452 that it wouldn't work? ..because I tried out of curiosity and wasn't getting _any_ output.

I'm using the same compiler he is.

Cheers!
 
I just did a quick buzz thru the ks0108b datasheet and it sure looks familiar. I just recently **broken link removed** with KS0108B on it. It may possibly help you.
 
Last edited:
I was actually reading your post, and the exchange you and Pommie had futz, thanks for the link I'll scope it out.
 
futz said:
I just did a quick buzz thru the ks0108b datasheet and it sure looks familiar. I just recently **broken link removed** with KS0108B on it. It may possibly help you.


Tried it out, and I have literally _nothing_ showing up on the display. I ported it to MCC18, but that just involved changing some tris statements to match the ones I am using (TRISB for data and TRISA for the modal pins like chip select, etc).

I hooked up an oscilloscope to a few of the data pins, and _tons_ of data is moving over them.

But ya, data is hooked up to PORTB, and the chip select and other modes are wired to PORTA. This is all on a pic18f452. Like i said, code is identical to yours... although I'm not sure what you're setting up in that #pragma at the start and that could be part of the reason.
 
Tried it out, and I have literally _nothing_ showing up on the display. I ported it to MCC18, but that just involved changing some tris statements to match the ones I am using (TRISB for data and TRISA for the modal pins like chip select, etc).

I hooked up an oscilloscope to a few of the data pins, and _tons_ of data is moving over them.

But ya, data is hooked up to PORTB, and the chip select and other modes are wired to PORTA. This is all on a pic18f452. Like i said, code is identical to yours... although I'm not sure what you're setting up in that #pragma at the start and that could be part of the reason.
 
Impossible for me to say without seeing your code and schematic.
 
**broken link removed**

ok, so in that picture PORTB-RB0 -> DB0; PORTB-RB7->DB7 (0 goes to 0, 1 goes to 1, etc) for the data.

for the other pins, D/I -> RA2, R/W -> RA1, E->RA0, CS1->RA3, CS2->RA4, RESET->RA5.

code is attached. I REALLY appreciate the help. I hope the schematic isn't too confusing, I just whipped it up in Visio as fast as I could seeing as you're "around."

Also, all the power sources, VDD, etc are 5 volts. The VEE is hooked up to a potentiometer and is getting ~1-2 V.

I think the problem might lie in the #pragma statement, because I didn't modify it at all, and am not positive what you're doing there. I was just hoping to get _something_ to display so I could study how you were doing it.

Again, thanks for any help you might be able to provide.
 

Attachments

  • glcd.zip
    2 KB · Views: 248
Last edited:
I think you need to change your #defines to use the latch rather than the port.

Code:
#define	DI        LATAbits.LATA2

You will however have to keep portb in your Busy routine as this is a read.

Mike.
 
i have some experience with the pic18f452, but not a whole lot. i've never used the "lat" before and never saw them used until a glcd example in code of your's pommie. what's the motivation for lat's?
 
desaila said:
i have some experience with the pic18f452, but not a whole lot. i've never used the "lat" before and never saw them used until a glcd example in code of your's pommie. what's the motivation for lat's?
My code was written for a 16F877, which has no LAT registers. They were added when the 18F's came along, I believe. Here's my simplified explanation from another thread:

Anyway, I doubt if this code will have any problem writing directly to the ports when running on an 18F, but it would be better to use LATs just in case.

Desaila, I haven't even looked at either the schematic or the code yet. Was having a nap. Now I'll have food. Then I'll look.
 
Fair enough. This is for a big projec that's due in ~2 weeks. I have all the rest of the stuff done, RFID, MMC, but the glcd is really giving me a headache. I definitely appreciate this forum and everything I've seen on it.
 
Desaila,

Futz is probably right and the Latch/Port probably won't matter but safer to change it just in case.

Have you turned off any analogue ports? (ADCON1=0x06 for the 18F452)

Mike.
 
Analogue pins work fine as digital outputs but always read back zero when you access the Port register. This really messes up any bit read/write operations.

Mike.
 
desaila said:
Again, thanks for any help you might be able to provide.
Well, right off the bat I have to say this #pragma
Code:
#pragma DATA _CONFIG, _CP_OFF & _PWRTE_OFF & _WDT_OFF & _HS_OSC & _LVP_OFF
is almost certainly wrong for an 18F. 18Fs have seven config words, whereas the 16Fs I wrote for only have one. Your compiler MUST have been at least warning you. It should have given you major errors.

Here's a set of typical BoostC pragmas for an 18F452
Code:
#pragma DATA    _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H
#pragma DATA    _CONFIG2L, _BOR_ON_2L & _BORV_20_2L & _PWRT_OFF_2L
#pragma DATA    _CONFIG2H, _WDT_OFF_2H & _WDTPS_128_2H
#pragma DATA    _CONFIG3H, _CCP2MX_ON_3H
#pragma DATA    _CONFIG4L, _STVR_ON_4L & _LVP_OFF_4L & _DEBUG_OFF_4L
#pragma DATA    _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L
#pragma DATA    _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H
#pragma DATA    _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L
#pragma DATA    _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H
#pragma DATA    _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L
#pragma DATA    _CONFIG7H, _EBTRB_OFF_7H

And here's a minimum one that I use mostly:
Code:
#pragma	CLOCK_FREQ	32000000
#pragma DATA    _CONFIG1H, _OSC_INTIO67_1H
#pragma DATA    _CONFIG2H, _WDT_OFF_2H
#pragma DATA    _CONFIG3H, _MCLRE_ON_3H
#pragma DATA    _CONFIG4L, _LVP_OFF_4L & _XINST_OFF_4L
That CLOCK_FREQ line is so the delay lib calculates delays correctly.

All the above assumes BoostC. Your compiler may have different syntax.
 
Last edited:
Just to be on the safe side, change these
Code:
#define	DI		PORTAbits.RA2
#define RW		PORTAbits.RA1
#define E		PORTAbits.RA0
#define CS1		PORTAbits.RA3
#define CS2		PORTAbits.RA4
#define RST		PORTAbits.RA5
to this
Code:
#define	DI		LATAbits.RA2
#define RW		LATAbits.RA1
#define E		LATAbits.RA0
#define CS1		LATAbits.RA3
#define CS2		LATAbits.RA4
#define RST		LATAbits.RA5
And, like Pommie says, check that any ports you're using with A/D on them are set for all digital. Default is analog. Weird, bad things will happen (it won't work).
 
desaila said:
So that'll turn all the ports digital or only some?
Look it up in the datasheet. If you're programming PICs, you should always have a datasheet handy. If you don't, you're just guessing and will never get things working.

Sorry if I sound grumpy, but that was a really dumbass question.
 
desaila said:
haha, fair enough.

I'm seeing ADCON1 = 0x07 to configure portA for digital inputs, but there's nothing under the PORTB configuration with regards to digital or analog inputs.

However, it says on a power on reset "these ports are configured as digital inputs." Then, I guess I see that there are no AD's associated with PORTB in the final summary of regs at the bottom of PORTB's section. So, ADCON1 = 0x07 then.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…