CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

LCD Trouble
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Bryan



Joined: 23 Apr 2005
Posts: 73

View user's profile Send private message Send e-mail AIM Address

LCD Trouble
PostPosted: Fri Apr 29, 2005 3:41 pm     Reply with quote

I am attempting to interface an LCD (HD44780 based) 16x2 to my PIC18F1320. I enabled use of port B in the CCS driver lcd.c since the PIC18F1320 only has ports A and B available. Here is the code I am using to test the LCD:

#include <18F1320.h>
#include <lcd.c>
#fuses NOWDT,NOPROTECT,NOLVP,NOMCLR,INTRC_IO// CCPB0
#use delay(clock=8000000)
#byte OSCCON=0b01111111 //8 MHz

void main()
{

set_tris_a(0x00);
output_a(0x00);
output_b(0x00);
lcd_init();
output_high(PIN_A0);
lcd_putc("\fHello World!");
}

I am using pin A0 to test whether the LCD is actually getting through the init sequence as it should be, but something strange happens. I turn on Vdd and nothing happens for about 30 seconds, then all of a sudden the LED comes on momentarily then flickers out (although it isn't burning out) and the power supply voltage drops from 5V (which I set it at) to about 1.5V and I cannot change it (I am using a dual variable power supply). Nothing shows up on the LCD screen either. I also noticed that part of the LCD gets very hot once the voltage drops and I would think this would mean something is shorting (pins connected incorrectly), though I have no clue why it would take 30 seconds for this to happen. There is a contrast adjust pin that I just tied to ground, thinking this would give maximum contrast and I would see something if the LCD was powering up correctly, but I see nothing. Any help would be appreciated if anyone has ever experienced anythign like this before!
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Apr 29, 2005 3:53 pm     Reply with quote

Besides the several problems that I see in your program,
it sounds like you have a serious wiring problem with your LCD.
Post the LCD manufacturer, part number, and if possible, post a
link to the data sheet.
Bryan



Joined: 23 Apr 2005
Posts: 73

View user's profile Send private message Send e-mail AIM Address

PostPosted: Fri Apr 29, 2005 5:28 pm     Reply with quote

The datasheet can be viewed at: http://www.edtc.com/EDT/Products/Specs/75.pdf

Manufacturer: Emerging Display Technologies Corporation
The rest should be in the datasheet

What problems do you see in my code? I am still new to PICs so it doesn't surprise me that there are several.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Apr 29, 2005 6:50 pm     Reply with quote

You might want to tell us how you wired the LCD. Also, how did you determine which is pin 1 and which is pin 18?
Guest








PostPosted: Fri Apr 29, 2005 9:09 pm     Reply with quote

PIN 16
Bryan



Joined: 23 Apr 2005
Posts: 73

View user's profile Send private message Send e-mail AIM Address

PostPosted: Sat Apr 30, 2005 2:25 am     Reply with quote

I took some digital photos of my setup, you can view them here: http://www.ultimatepong.net/lcd1.jpg
http://www.ultimatepong.net/lcd2.jpg
http://www.ultimatepong.net/lcd3.jpg

As you can see from the pictures, pin 1 goes into the top left pin slot of the header and if you trace the ribbon cable to the output side I am assuming that the top left pin (on the same side of the ribbon cable as pin 1 is on the lcd end) is pin 1. Then the bottom left pin would be pin 2 and I follow this pattern to the other end where the bottom right pin is pin 14. Pins 17 and 18 are for the EL backlight and they are connected to the other end of the display so there is no need to worry about them at this point. Pin 15 and 16 as you can see from the specs are no connection. Do any of you happen to know if my assumption about this header layout is correct? (Since I cannot see directly into the output of the ribbon cable to see what holes are connected to what pins from the lcd) With my assumption of pin layout I just connected each lcd pin directly to the proper pins on port b using jumper wires that I read from the driver lcd.c.
Ttelmah
Guest







PostPosted: Sat Apr 30, 2005 3:04 am     Reply with quote

Why assume?. An ohmeter is your friend...
As shown, I think you will find pin 1 of the cable, goes to the top right pin, not the top left. The cable has in fact been assembled into the plug 'reversed' from the standard orientation. Normally with the cable coming into the plug from the left, the 'lug' should be towards you (not away as shown), and on the body of the plug, there will then be a triangular mark at the top right, marking pin1.
The reason the columns are reversed, is that this type of display, assumes the cable is attached with a simple header, onto the _front_ of the display, not the back as you are doing.
You have your wiring reversed.

Best Wishes
Bryan



Joined: 23 Apr 2005
Posts: 73

View user's profile Send private message Send e-mail AIM Address

PostPosted: Sat Apr 30, 2005 4:33 am     Reply with quote

Excellent, thank you for the help! After wiring in this manner (the triangular marking is top right as you thought) the LED comes on after init() completes using this code:

#include <18F1320.h>
#include <lcd.c>
#fuses NOWDT,NOPROTECT,NOLVP,NOMCLR,INTRC_IO// CCPB0
#use delay(clock=8000000)

void main()
{

set_tris_a(0x00);
output_a(0x00);
output_b(0x00);
lcd_init();
output_high(PIN_A0);
lcd_putc("\fHello World!");
delay_ms(1000);
output_low(PIN_A0);
}

Unfortunately, all I get as output to the LCD is the entire first line with each character box completely filled in (all 24 are black) with the second line empty as expected. The LED also never goes low, meaning the code must be getting stuck somewhere in the lcd_putc() function. Any ideas?[/code]
Ttelmah
Guest







PostPosted: Sat Apr 30, 2005 7:52 am     Reply with quote

There are a number of potential problems with the code, that now apply.
First, put a 'trap' at the end of the routine, to stop the code running off the end. Without this, the processor will go to sleep as soon as the code finishes, and results may not be as expected.
Second, initialise portA, to not use it's ADC converter:
SETUP_ADC_PORTS(NO_ANALOGS);
Otherwise your accesses to portA, may not work.
If you are going to control the TRIS register, you need to #use fast_io. However this is uneccessary for what you post, but without it, the set_tris_a command really does nothing (in the standard I/O mode, the compiler automatically controls the TRIS for you).
The display with one line solid, is what you would expect, if the chip has not initialised. I must admit I'd be afraid that the LCD controller itself might have been damaged by the connction reversal.

Best Wishes
Bryan



Joined: 23 Apr 2005
Posts: 73

View user's profile Send private message Send e-mail AIM Address

PostPosted: Sat Apr 30, 2005 2:24 pm     Reply with quote

I am curious if the LCD is supposed to take 7-10 seconds to initialize - once I turn on Vdd is takes about that long for my LED to come on (it is programmed to come on after lcd_init() is finished). It is also strange to note that I only get output when I structure the putc() as: lcd_putc("\fHello World!"). If I add a \n newline character or take off some of the letters or the !, I no longer get anything onscreen at all. Maybe I will just get a new LCD because after all this one has been through it could very well be damaged.

Ttelmah, I tried your suggestions but they didn't make a difference to the LCD output. Thank you for the help though.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sat Apr 30, 2005 5:17 pm     Reply with quote

If your PIC is running very slowly and you're using INTRC mode,
you should always suspect that you're running at 32 KHz, or whatever
the lowest frequency is for your PIC.

See this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=22248
Bryan



Joined: 23 Apr 2005
Posts: 73

View user's profile Send private message Send e-mail AIM Address

PostPosted: Sat Apr 30, 2005 5:27 pm     Reply with quote

Thank you for the insight into oscillators. My clock is working correctly, because I have the #use delay(clock=8000000) set up below the fuses as shown in that thread you posted so I am still confused as to why the LCD is taking so long to initialize. Even at a much slower clock frequency like the 32 kHz default the lcd wouldn't take around 10 seconds to initialize. I was examining the code for the driver and there are not nearly enough delays to make it take that long to initialize even at slow clock speeds, which leads me to believe that this must be due to chip damage. I'll have to try again when I get a new LCD.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sat Apr 30, 2005 5:50 pm     Reply with quote

The problem is that, depending on your compiler version, there's no
guarantee that the method you're using will actually setup OSCCON
correctly.

According to the data sheet, the lowest INTRC speed is 31.25 KHz.

Because you have #use delay() set for 8 MHz, the delay_ms()
function is expecting that one instruction cycle takes 1/2 microsecond.
But if you're really running at 31.25 KHz, one instruction cycle is 128
microseconds. That's 256 times longer.

The lcd_init() function in LCD.C has got cumulative delays in it
of about 30 ms. So take 30ms x 256 = 7.68 seconds.

This is why I suspect that OSCCON is not really being setup correctly.
You are new, so you're sort of assuming that things work if they're
done as described in the manual, but that's not necessarily true.
It all depends on your compiler version.

I suggest that you try some of the other methods described in that
thread, to setup the oscillator. In fact, try this one next:

#byte OSCCON = 0xFD3 // Define the register address of OSCCON

void main()
{
OSCCON = 0x70; // Put this line at the start of main()



while(1);
}
Humberto



Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata

View user's profile Send private message

PostPosted: Sat Apr 30, 2005 6:20 pm     Reply with quote

Quote:

There is a contrast adjust pin that I just tied to ground, thinking this would give maximum contrast and I would see something if the LCD was powering up correctly, but I see nothing.


Quote:

Unfortunately, all I get as output to the LCD is the entire first line with each character box completely filled in (all 24 are black) with the second line empty as expected.


From the LCD Datasheet

VDD : Power Supply for Logic Control
VO: LCD Contrast Adjustment

Page 11:

VDD - VO = LCD Driving Voltage
LCD Driving Voltage must be >= 1.5V

Adjust the contrast biasing accordingly.

Humberto
Bryan



Joined: 23 Apr 2005
Posts: 73

View user's profile Send private message Send e-mail AIM Address

PostPosted: Sun May 01, 2005 8:02 pm     Reply with quote

Right now I have the Vdd pin on the LCD tied directly to my 5V source and the Vss and Vo pins tied directly to ground so the drivign voltage in my case would be 5V which is much greater than their 1.5V threshold. I'm not sure though if this voltage is too high and may be causing some of my problems. Half the time when I power up I get that solid first row and half the time nothing shows up at all which again leads me to believe that my hitachi driver has been burned out by my incorrect wirings in the past (With the same exact code and wiring, the output shouldn't be inconsistent like that).

PCM Programmer - I see where you are coming from, but I really don't think my oscillator is being set improperly because I have been working with interrupts recently as well and I used the same exact code to set the internal oscillator to 4 MHz #use delay(clock=4000000) for an interrupt test program. I used an LED to watch to make sure that my timer0 was rolling over at the right time that I had calculated based on my clock frequency and it indeed was. Here is my code:

Code:

#include <18F1320.h>
#fuses NOWDT,NOPROTECT,NOLVP,NOMCLR,INTRC_IO// CCPB0
#use delay(clock=4000000)

long count = 0;

#int_rtcc
void timer0_isr()
{
      count++;

      if(count >= 10)
      {
         count = 0;
         output_toggle(PIN_A0);
      }
}



void main()
{
   enable_interrupts(INT_RTCC);
   enable_interrupts(GLOBAL);
   setup_timer_0(RTCC_INTERNAL|RTCC_DIV_16);
   output_a(0x00);
   output_b(0x00);
   set_tris_a (0x00);
   set_tris_b (0xFF);

   while(1);
}


With internal RTCC set at 4 MHz (1 MHz operating frequency since the crystal is always 4x as fast as the actual clockspeed) the period for one tick is 1 microsecond. Since I prescaled by 16, it takes 16us for one tick of the 16 bit timer0. This would lead to overflow and interrupt at every 1.04 seconds (I wanted a 1 second approximate overflow). Then with my counter variable the LED should toggle every 10.4 seconds or so. I used a stopwatch and it indeed does. This is why I am still puzzled by the long delay in LCD initialization. Thank you for the help though with oscillators since I did not realize that there was this difference between compiler types.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
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