 |
 |
| View previous topic :: View next topic |
| Author |
Message |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
 Posted: Sun Aug 22, 2004 3:19 pm |
 |
|
The following test program works OK on my LCD demo board.
I used PCM vs. 3.207. What version of the compiler are you using ?
| Code: | #include <16F877.H>
#fuses XT, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock = 4000000)
#include <lcd.c>
void main()
{
char a[10]="tststring";
//char a[10]="123456789";
lcd_init();
while(1)
{
lcd_gotoxy(1,1);
printf(lcd_putc,"%s",a);
delay_ms(500);
}
}
|
|
|
 |
alexbilo
Joined: 01 Jun 2004
Posts: 39
Location: Trois-Rivičres
|
|
| Posted: Sun Aug 22, 2004 3:27 pm |
|
|
Actually, 3.187 .
Not the latest, I know... 
_________________
Alex |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Aug 22, 2004 4:13 pm |
|
|
I noticed you're using PCH and the 18F452, so I installed PCH 3.187
and programmed a 18F452, and it still works. But, I'm using a 8x2
LCD, and the lcd.c driver. You're using a 20x4 LCD, and the lcd420.c
driver.
I feel that you need to:
1. Closely check the LCD wiring.
2. Compare the LCD init string used in the LCD420.C driver
to the init values specified in your LCD data sheet.
Also look at the delay times required between characters
during the LCD init (as specified in the LCD data sheet).
3. Verify important details, such as using NOLVP, and
also making sure that you don't use watchdog timer
while doing a test program. You don't want to be
testing the WDT along with the LCD. Etc.
4. Make sure that when you compile a new test program,
that it actually gets programmed into the PIC. You can
see that I use two different strings in the program below.
Whenever I change the program, I change the test string.
That way, I guarantee that I don't make some dumb mistake
such as thinking that I programmed some new code into the PIC,
but didn't really do it.
Also,
A. What LCD are you using ? (Manufacturer and part number)
B. Did you modify the CCS LCD420.C driver in any way ?
| Code: | #include <18F452.H>
#fuses XT, NOPROTECT, PUT, NOBROWNOUT, NOWDT, NOLVP
#use delay(clock=4000000)
#include <lcd.c>
//=================================
void main()
{
char a[10]="tststring";
//char a[10]="123456789";
lcd_init();
while(1)
{
lcd_gotoxy(1,1);
printf(lcd_putc,"%s",a);
delay_ms(500);
}
} |
|
|
|
alexbilo
Joined: 01 Jun 2004
Posts: 39
Location: Trois-Rivičres
|
|
| Posted: Sun Aug 22, 2004 7:47 pm |
|
|
| Quote: |
1. Closely check the LCD wiring.
|
Done. I made sure that everything is wired properly and it is. Proof is that the display is very stable when I use the "correct" code.
| Quote: |
2. Compare the LCD init string used in the LCD420.C driver
to the init values specified in your LCD data sheet.
Also look at the delay times required between characters
during the LCD init (as specified in the LCD data sheet).
|
I need to take a look at that. I checked the timing requirements for the actual read and write operations, though. Moreover, the driver verifies the lcd's status bit before sending new data.
| Quote: |
3. Verify important details, such as using NOLVP, and
also making sure that you don't use watchdog timer
while doing a test program. You don't want to be
testing the WDT along with the LCD. Etc.
|
Got the NOWDT and NOLVP fuses set up. Already been mistaken by such errors. 
| Quote: |
4. Make sure that when you compile a new test program,
that it actually gets programmed into the PIC. You can
see that I use two different strings in the program below.
Whenever I change the program, I change the test string.
That way, I guarantee that I don't make some dumb mistake
such as thinking that I programmed some new code into the PIC,
but didn't really do it.
|
I do, too, but nice thinking  . Experience, huh?
I use a CFAH2004A-TMI-JP from CrystalFontz. I altered the lcd420.c driver only to adapt it to D port on a pic18 (base address and set_tris_X commands). I'll look more closely at the timing and init string, though.
I'll get back to this tomorrow evening, so you'll probly hear from me by then
Thanks again for the help,
_________________
Alex |
|
|
alexbilo
Joined: 01 Jun 2004
Posts: 39
Location: Trois-Rivičres
|
|
| Posted: Mon Aug 23, 2004 6:50 pm |
|
|
Ok, now...
Here's what I found :
Your code actually -does- work. Whenever I try with a longer string, though, characters start to change randomly (but not so randomly since there's always only a few of the displayed characters that aren't correct). I checked the init string - OK. I checked the timing reqs, added 50µs after the send_nibble, OK.
The strange thing is : I looked at the signals on the data pins (D4 to D7) with a scope. I found out that the signals aren't clean (the edges aren't clean and there's random spikes while at low logic level). I tried to toggle the port's pins with a simple loop and then the signals are very clean (although the lcd is powered and connected).
Strange one huh??
HELP!!! 
_________________
Alex |
|
|
alexbilo
Joined: 01 Jun 2004
Posts: 39
Location: Trois-Rivičres
|
|
| Posted: Mon Aug 23, 2004 8:10 pm |
|
|
Next update :
I solved the signals problem by modifying the busy_flag reading subroutine. However, that didn't solve my problem. Whenever I try the printf function with a variable (not in each case, but in most), I get the bug. Whenever I use the printf or lcd_putc routines with constant strings, no problem.
Any1 has a link to functions that converts longs to strings so that I can avoid printf?
Thanks,
_________________
Alex |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Aug 23, 2004 8:36 pm |
|
|
| Quote: | Whenever I try the printf function with a variable (not in each
case, but in most), I get the bug. |
Post a small demo program that demonstrates the printf() problem.
(You don't have to post the LCD driver). |
|
|
alexbilo
Joined: 01 Jun 2004
Posts: 39
Location: Trois-Rivičres
|
|
| Posted: Thu Aug 26, 2004 7:10 am |
|
|
Hi,
Back to this printf problem :
I tested two small programs that prints two lines on the lcd (so that you can test it more easily):
This one doesn't work... Both lines are displayed, but there's a glitch in the display.
| Code: |
#include <18F452.H>
#fuses HS, NOPROTECT, PUT, NOBROWNOUT, NOWDT, NOLVP
#use delay(clock=1000000)
#include <lcd4_v2.c>
//=================================
void main()
{
char a[21]="----Hello_world----";
lcd_init();
while(1)
{
lcd_gotoxy(1,1);
printf(lcd_putc,"----Hello_world----\n%s\n",a);
delay_ms(500);
}
}
|
Finaly, I doubt that the printf function is guilty... Here's another one that doesn't work :
| Code: |
#include <18F452.H>
#fuses HS, NOPROTECT, PUT, NOBROWNOUT, NOWDT, NOLVP
#use delay(clock=1000000)
#include <lcd4_v2.c>
//=================================
void main()
{
char a[21]="----Hello_world----";
lcd_init();
while(1)
{
lcd_gotoxy(1,1);
lcd_putc("----Hello_world----\n----Hello_world----\n");
delay_ms(500);
}
}
|
Notice the a variable that isn't even used... But if I comment the line, that works perfectly...
Any idea? I'm banging my head into the wall...
_________________
Alex |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Aug 26, 2004 8:24 am |
|
|
Are you really using a 1 MHz crystal ?
| Quote: | | #use delay(clock=1000000) |
I suspect you're really using a 10 MHz crystal. With that incorrect
clock speed, all the software delays created by the compiler will
be 10x faster than they should be. The LCD driver is full of delay
statements. This is probably the reason why your LCD acts in a flakey
manner.
It's also the reason why I ask people to show a complete test program. |
|
|
alexbilo
Joined: 01 Jun 2004
Posts: 39
Location: Trois-Rivičres
|
|
| Posted: Thu Aug 26, 2004 8:50 am |
|
|
I must admit that I had some hope that it would have been the error, but unfortunately not.
It was an error and I corrected it, but it didn't solve the problem.
Here's an example of what is displayed :
| Quote: | ----Hello_worldM---
----Hello_world---*
|
where * is a strange character. The glitches change place on the display.
...[/quote]
_________________
Alex |
|
|
alexbilo
Joined: 01 Jun 2004
Posts: 39
Location: Trois-Rivičres
|
|
| Posted: Tue Aug 31, 2004 7:42 am |
|
|
Got it!!!
Finally, after much debugging, I found out that the RAM memory of the PIC that I used is deffective. Data that was being sent to the lcd was getting corrupted in a transfer between two memory cases.
"%?$%? deffective chips! 
Thanks to all anyway...
_________________
Alex |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
