• 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.

dsPIC33FJ12GP202 DSC with KS0107/KS0108 GLCD

Status
Not open for further replies.

mongerson

New Member
Has anyone used a dsPIC with the Samsung GLCD (KS0108)?

If so, does anyone have an example in C? Once I get this running I'll also share :)

Thanks,
-Michael
 

mongerson

New Member
As far as the actual differences between C18 and C30, I think I'll be OK. More of what I'm trying to accomplish now is trying to figure out how many I/O pins need connected to the GLCD, and what to do with the ones I don't connect on the GLCD.

Thanks,
-Michael
 

mongerson

New Member
OK so I've uploaded a schematic (PDF format), the dsPIC33FJ12GP202 DSC Datasheet, and the GLCD (KS0107/0108) datasheet. I was curious to see if someone would like to take a look at what I've got so far and tell me if they think this will work. The circuit will be breadboarded as the schematic indicates.

My main concern at this point is that I believe I only have (6) 5V tolerant pins, so in consideration of a status read, I may have to re route those connections so that if it is possible that they're high (5V VDD), the DSC will tolerate the logical high values. Of course it may be possible to not worry about doing any reads if my timing is perfect.

Any input is greatly appreciated! :)

- Michael

Schematic: View attachment i2web.pdf

LCD Datasheet: View attachment CFAG12864ITMITN (6).pdf
 
Last edited:

mongerson

New Member
Hello Mike,

I'm having trouble building the GLCD.H file (found on the previously linked post for the C18 Compiler). Mike, I believe on that post you said it needed updated, but I couldn't find the updated copy. Could you, or anyone tell me what is wrong that version or how to obtain a build able version?

Thanks,
Michael
 

Pommie

Well-Known Member
Most Helpful Member
The problem with that code was that I wrote it rather hastily and referred to some ports directly. I later changed it and that is the version linked to earlier in this thread. As far as I'm aware it should now work correctly.

Mike.
 

mongerson

New Member
I found the problem (c18 works fine), c30 gives build errors.

It looks like in the GLCD.H file lines 37 and 38 are defining and pointing the message and logo parameters to program memory within the PutMessage and PutLogo functions. The problem is that the c18 compiler and the c30 compiler use different storage qualifications for creating variables in program memory. The comparison below can be found on the c30 compiler user guide:

--------------------------------------------
PIC18: rom int gArray[6] = {0,1,2,3,4,5};

16-Bit: __attribute__((space(psv)))
const int gArray[6] = {0,1,2,3,4,5};
--------------------------------------------

Any ideas how to port this to c30 from c18?

Thanks,
- Michael
 

mongerson

New Member
OK, I got it to compile, and it is running now with output to the screen (although it doesn't look like much of anything). For anyone wondering, 'const' is a direct replacement for 'ROM' if you're porting from C18 to C30.

What is the purpose of having the dummy reads? Is it necessary to use reads or can i just use delays? I tied the R/W pin on the GLCD to gnd because not all of my DSC data pins are 5V tolerant. If it is absolutely necessary to use a read, I think i'll have to use different pins, which will mean the fonts and libraries will need to be offset.

Thanks,
Michael
 

Pommie

Well-Known Member
Most Helpful Member
If you need to plot individual pixels then you need to be able to read so you can OR in the new data. If your happy just writing characters on byte boundaries then you can just use a delay.

Mike.
 

mongerson

New Member
Gotcha, but since the C30 compiler limits unsigned CHAR arrays to a maximum size of 255, and since i'm using a 16-bit wide bus, i think i'm pretty much forced into doing reads anyways. The reason is the 2 byte writes to the port will overwrite the entire port each time unless I do a bitwise OR with the 2 bytes. If I do a bitwise OR i'm not sure how i'd temporarily store it as it sequenced through the array. It may be possible to shift the data in. Any suggestions?
 

mongerson

New Member
OK so now i've wired up the circuit to allow reads, but that means the data all has to be shifted over 4-bits. I'm not sure of an efficient way to do this with the code. The data pins will be RB4-RB11.

Any ideas?
 

kchriste

New Member
Forum Supporter
Variable = PORTB >> 4;
Variable &= 255;
 
Last edited:

mongerson

New Member
OK, but i need 0x4xx0 where 'xx' represents the data. Most significant 4 bits are the GLCD's control lines.

Any bitwise operations to make this work?? The least amount of operations the better of course..

Thank you,
Michael
 

kchriste

New Member
Forum Supporter
The way I do bitwise in C is this way:
Code:
#define CS2		LATBbits.LATB12
#define CS1		LATBbits.LATB11
#define	DI		LATBbits.LATB10
#define RW		LATBbits.LATB9
#define E		LATBbits.LATB8
 //Then all you need is:
CS1 = 0; DI = 1; RW = 0; //etc.
Personally, as far as the data pins go, I would simply wire them to bits 0-7 to avoid all the overhead of shifting data all the time. Makes the code way neater.
 

mongerson

New Member
as previously discussed, those are the only contiguous 5v tolerant pins.

LATB instructions overwrite the entire port wiping out the control pins each time, which is the need for the shifting.

A bitmask is what i'm using now, but i'd much rather automate it.
 

Pommie

Well-Known Member
Most Helpful Member
PORTB=(data<<4)|0x400;

Edit, didn't notice the thread had a second page of posts. LATBbits.LATB5=1 will only set the 5th bit of latch B and leave the rest unchanged.

Mike.
 
Last edited:

kchriste

New Member
Forum Supporter
As mentioned by Pommie, LATBbits.LATBx only effects one bit (x).
You could also use unions and structs to work with custom bit fields in C. Try this code in SIM to see how it works:

Code:
union {
 unsigned char byte;
 struct {
  unsigned bits0_2:3;
  unsigned bits3_5:3;
  unsigned bits6_7:2;
 };
} OddBit

	OddBit.byte = 0;
		for( OddBit.bits3_5 = 0x7; OddBit.bits3_5 > 0; OddBit.bits3_5-- )
		{ OddBit.bits0_2++; }
	OddBit.byte = 0x55;
The only "problem" with using bit fields is that it can generate some pretty weird machine code so the code could get a little inefficient; space and/or speed wise.
 
Last edited:

mongerson

New Member
Yes i understand that LATBbits.LATBx only effects one bit (x). Since the control lines are on the same port as the data lines, a port wide LATB or PORTB instruction will overwrite the entire port when the data is sent unless each bit is addressed independently (as mentioned).

I started for example breaking down the bits independently for cleaner code, but regardless of how its done, every bit controlling the LCD is on the same port. Later today I'll post it what I have so anyone curious can look.
 
Status
Not open for further replies.

EE World Online Articles

Loading
Top