Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

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!
 
desaila said:
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.
I just did a quick buzz thru the ks0108b datasheet and it sure looks familiar. :D 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. :D 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.
 
desaila said:
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: 266
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:
Normally you should use LATA/B/C/D/E for outputting to ports. It's a "shadow register" or "latch register". Using it avoids a problem that sometimes happens known as the Read/Modify/Write problem that happens if you write directly to one bit of a port like PORTA and immediately write to another different bit of the same port. Sometimes the first bit is still in the process of changing and when you write the second one so quickly the first one gets messed up. Using the latch register fixes that completely.

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. :p
 
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). :p
 
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. :D
 
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.

New Articles From Microcontroller Tips

Back
Top