PLEASE HELP.....GLK19264-7T-1U... C CODE

SAURONB · Post by **SAURONB** » Sat Mar 01, 2008 1:05 am

HELLO,
I'VE BEEN TRYING TO FIND EXAMPLES (C CODE) ON HOW TO SEND THE COMMANDS TO THE LCD, IF ANYONE CAN HELP ME OR HAS SOME EXAMPLES OF C CODE FOR THESE LCDS I WOULD REALLY APPRECIATE IT... THANKS...
HERE IS WHAT I'VE DONE SO FAR...

THE CODE COMPILES, IT DOES THE DELAYS BUT THE STRINGS ARE NOT DISPLAYED CORRECTLY... IT SHOWS SOMETHING LIKE: VHU AND OTHER WEIRD CHARACTERS....

#include <18f4520.h>
#fuses HS,NOLVP,NOWDT
#use delay (clock=10000000)
#use rs232(baud=19200, xmit=PIN_C6)

void main(void) {

output_high(PIN_C6);
delay_ms(1000);

putc(0xFE);
putc(0x58);
putc(0xFE); //turn lcd off, cursor on and character blink
putc(0x46);
delay_ms(1000);

putc(0xFE); //turn lcd on, cursor on and character blink
putc(0x42);
delay_ms(1000);
//putc(66); //backlight on
//delay_ms(1);

putc(0xFE); //return to origin and clear, must wait 5ms
putc(0x58);
delay_ms(1000);

printf("LCD Test Program");
delay_ms(1000);

while(TRUE){

putc(0x58); //return to origin and clear, must wait 5ms
delay_ms(1000);
printf("Something");
delay_ms(1000);
printf("Another String");
delay_ms(1000);
}
}

Clark · Post by **Clark** » Mon Mar 03, 2008 10:58 am

Hi SauronB,

Thanks for your post, I see you have been experimenting with your own command code for the GLK19264-7T-1U display. I have a couple questions I'd like to ask, to form a better understanding of what does function, and what doesn't.

First, are your command functions working; it looks like you are doing some display on/off, cursor, back light, and clear screen commands?

Second, can you confirm that you can write to the display, even though mere garbage is produced?

If you can write commands, your display and code are functioning correctly. If you can write text, albeit it garbage, your text functionality is also good. I suspect that the problem may lie with your "printf" functions. The display will expect a string of bytes representing the ascii values of the characters, however, "printf" may not use this convention. You can check out the C documentation for the defaults, and how to change them.

If you are able to write commands, this demonstrates that the display is correctly receiving command characters sent using "putc". You may want to output display characters in the same fashion as a quick test of their functionality.

Let me know how your program turns out, if you have any further trouble along the way, you can always turn here for help.

Thanks,
Troy

SAURONB · Post by **SAURONB** » Mon Mar 03, 2008 10:40 pm

Troy,
Thanks a lot for your response. Here are the answers to your questions:

a)The commands are not working, it does not do any of the commands(turn lcd on, off, clear screen, print text)...
It just prints strange characters, and most of the time are the same...

b) I don't even know if is writing to the LCD because it just shows characters that do not reflect the code.

c) That's why I need some help because I've been trying to figure out in different ways how to turn the lcd on/off, clear screen, send text and other commands with code, but it does not work. It only shows garbage.
I don't know if I'm sending the commands incorrectly, I even tried to find C examples in the forum, and other sites, but there are not examples. and the ones I found(2). I tried them , but it did not work either. Also, the datasheet of the LCD does not provide clear information on how to send the commands, and that makes this really hard to figure it out.

d) Do you have any C examples that can help me solve this problem, or do you know a way to solve it? Please advise.. Thanks again for your help. I really appreciate it.

Clark · Post by **Clark** » Tue Mar 04, 2008 9:48 am

Hi SauronB,

Thanks for taking a look at the results of your code for me, sorry to see that you seem to have no communication to your display. After I posted yesterday. my colleague out here, Ray, pointed out something I hadn't noticed about your code, which I think may solve your problems.

It looks like you are using the 18f4520.h library, which I understand is to be used with an associated PIC. Although these devices may have RS232 communication, it is usually through 5v TTL logic. I believe your display is currently expecting regular RS232 levels.

To enable communication at TTL levels within your display, you will have to change the protocol select jumpers as outlined in your manual. This will entail removing the three 0 ohm resistors currently on the RS232 pads, and moving them to the two TTL pads, or just using solder to make the connection.

Alternatively, you may check out a level translator to put in between the two, but with the TTL built in to your display, I would say the first solution is much better.

I hope that gives you a few ideas for resolving your communication issues, if you have any further questions, please feel free to post them up here.

Thanks,
Troy

SAURONB · Post by **SAURONB** » Tue Mar 04, 2008 11:14 pm

Troy,
Thank you so much for your help... What you told me in your last post solved the problem... Thanks

--------------------------------------------------------------
APRIL/1/2008:

I have a BIG!!! problem with this LCD

Clark · Post by **Clark** » Wed Mar 05, 2008 3:37 pm

Hi SauronB,

That's great to hear, best of luck with your application, and feel free to post anytime you run into trouble.

Thanks,
Troy

SAURONB · Post by **SAURONB** » Tue Apr 01, 2008 8:14 pm

I have a BIG!!! problem with this LCD, it was working fine until I did what you told me to do: This will entail removing the three 0 ohm resistors currently on the RS232 pads, and moving them to the two TTL pads, or just using solder to make the connection.
That solved the problem that I indicated above:to get the LCD working on RS232. But now the LCD does NOT work with the PC.. I can not get it to connect with MOGD#, and putting those tiny resistors back its IMPOSSIBLE, whose great design decision was that? now I am getting behind in my project because I can not upload the images I need to the LCD since there is not way of connecting the lcd back to the pc and upload the images with MOGD# Please advice, Thanks.

Post by **Ray** » Wed Apr 02, 2008 7:16 am

What troy meant with 'using solder to make the connection' was don't try to put back the (0 ohm) resistors just use a small blob of solder to make the bridge between the pins. (do be sure you are not shorting any of the other pins) That should make things easier for you.

SAURONB · Post by **SAURONB** » Wed Apr 02, 2008 12:39 pm

I ALREADY put the small blob of solder to make the bridge between the pins, but now I need to go back to RS232, in other words I need to switch between TTL and RS232 in order to fully test the LCD with the PIC and also to connect the LCD to the computer and upload the images to it by using MODG# . but soldering and desoldering to switch from TTL/RS232/TTL does NOT make any sense, customers should not have to do that, specially that doing it multiple times will damage the board and possibly make the pads come out from it, and leave the LCD working forever in only 1 mode .

Clark · Post by **Clark** » Wed Apr 02, 2008 3:29 pm

Hi SauronB,

I understand that the protocol select jumpers on our boards can be difficult to manipulate for those developing them into their own application. I can assure you, this style of solder pad was chosen to allow for the easiest possible switch between modes. However, I know the easiest possible solution, is really not as easy as a developer would hope.

Please keep in mind that Matrix Orbital sells displays not only as single units, but in large quantities to companies around the world. When I say this, I don't mean to belittle the troubles of our smaller developers, they are tremendously important to the growth of our products. Just keep in mind that in many cases our products are designed in a way to provide the greatest flexibility to the greatest number of customers.

Many users choose a controller that communicates using RS232 levels, or implement a level translator in between their host and our display. I understand this can be expensive and time consuming for many of our developers.

Currently, I am able to switch when needed using a TTL converter that we employ internally. Although these devices are not currently ready for sale, there is some talk of adapting them in the future.

Unfortunately, there is little additional aid I can offer you at this time, just the knowledge that this is an issue we are aware of, and are currently discussing possible solutions.

Thanks,
Troy

Macabra · Post by **Macabra** » Thu Sep 18, 2008 10:00 am

A max3232 should've solved the problem..it takes the TTL inputs from the PIC and ouputs RS232 signals to a DB9 connector..and to LCD.

No need to go through that soldering stuff.

Clark · Post by **Clark** » Thu Sep 18, 2008 11:19 am

That's definitely a good hardware alternative to soldering from Macabra. I've actually got an ST232 on an external board that just sits in the 4 pin header line when I need TTL.

The external board is a nice idea, but we do have things like cost, hardware expertise, and ease of use for the customer in mind when designing our products, even though sometimes it really doesn't seem that way.

~Troy