ADC on LCD

Go To Last Post
83 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, before I buy a LCD with a HD44780 compatible controller. I want to know I can dispay a ADC value on that display? I think it is possible, but how?

....
lcd_putsf(adcValue);
...

Thanks,
Steffan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An integer value would need to be converted to a string. There are several ways of doing this, including printf() and itoa().

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, then I am going to buy a LCD-screen, so I can read the ADC values.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could send the string out the rs232 port to your pc also.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...or some leds on another port.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is also possible, but I think LCD is more attractive. And I have more then one ADC value.
My ISP can not sent values to my pc?

BTW. I use it for my linefollowing robot with ir-sensors and colorsensor, so I want the ADC values.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using internal ADC of the ATmega

#asm
.equ __lcd_port=0x12
#endasm

char lcd_buffer[33];

unsigned int a;

void main(void)
a = read_adc(0);
sprintf(lcd_buffer,"%+1.2i",a);
lcd_gotoxy(0,0);
lcd_puts(lcd_buffer);

Well, not excatly like the above, but placing this after the while(1); can do the trick.

Sepi banget disini...
Andaikan aku tau ada orang lain...
Dari negeri ini, untuk berbagi...
Hix..
Kasi tau ya, kalo kalian ngerti bahasa ini!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Today I purchased a LCD module.
On the internet I found several websites. Example: http://www.geekland.org/e-dsp.com/wp-content/uploads/2006/02/LCD_schematic.gif
This website only use, the 4-6th and 11-14th pins of the module, I can do that too?
The specs of my LCD-module

Last Edited: Wed. Dec 20, 2006 - 05:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But that's not really a datasheet - it's simply a spec. sheet. It mentions that the module uses the KS0066U controller and the datasheet for that is at:

http://www.asix-tools.com/downlo...

As it appears to be one of the many HDD44780 compatibles then you should be able to connect it as shown in Dean's post here:

https://www.avrfreaks.net/index.p...

Also use the search function on Freaks to search for HDD44780 and "4 bit" as the use of this kind of controller in 4 bit mode has been covered N thousand times.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tried the schema, now I have the following question: Should the backlight etc turn on when I connect a 5v power supply to it? Now it is not doing anything(Yes with power supply connected)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Backlight is a separate two pins from the controller. If the backlight uses leds, you must hook the voltage up correctly!

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ofcourse! 'BKL' means backlight :)
Next question, the contrast is low at 0V? I'm asking this, because I cannot see what I am wrote, or it is not showed at the lcd.

#asm
   .equ __lcd_port=0x12 ;PORTD
#endasm
lcd_init(16);
while (1)
      {
// initialize the LCD for

// 2 lines & 16 columns

//lcd_init(20);

// go to the firs line of the LCD (x,y)
lcd_gotoxy(0,0);

// display the message
lcd_putsf("test"); 

// go to the second line of the LCD (x,y)
lcd_gotoxy(0,1);

// display the message
lcd_putsf("Hello World! :-) ");

while (1);
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you turn the contrast up, you get a bunch of 'dark boxes' that have hypnotic powers. They have caused several programmers to freak out after trying to get rid of them for hours.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed, I am one of them, but I confused of the 'letters' that are not on the lcd.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I assume you are using codevision. I think you can assume that their lcd routines work if you hook the lcd up correctly

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The wiring is correct, maybe it is a problem I use the 4bit version?

BTW. Indeed I use the codevision lib.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use the imagecraft compiler.... I assume if the cv compiler has the option to do 4 bit or 8 bit mode, there is something that must be configured by the user to select one or the other. You evidently found out how to tell it what port you are using. (That IS the port it is wired up to right?)

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I use PORTD for the 4bit connection. Thanks for so far, I will look futher.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know it anymore! What I've done:

PD0 -> pin 4(H/L Register select signal)
PD1 -> pin 5(H/L Read/Write signal)
PD2 -> pin 11(DB4)
PD3 -> pin 12(DB5)
PD4 -> pin 13(DB6)
PD5 -> pin 14(DB7)

But there is not showing anything on the lcd-module! I checked all the wirings(all good)

I'm pissed off :( (Sorry)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems like if there are signals named db4,5,6,7 they should be hooked up to port pins 4,5,6,7. You dont need the r/w line if you just write, but you DO need the Enable bit. Where is that??

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Somewhere I saw the enable port had to be grounded, maybe it was the r/w pin and not the enable, so I did that. And about the pins, I think that is true.

I have to do:

PD0 -> pin 4(H/L Register select signal)
PD1 -> pin 5(enable)
PD4 -> pin 11(DB4)
PD5 -> pin 12(DB5)
PD6 -> pin 13(DB6)
PD7 -> pin 14(DB7)
That is correct?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You waiting for me? Just try it. Tell us if it works.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't know it anymore! What I've done:

PD0 -> pin 4(H/L Register select signal)
PD1 -> pin 5(H/L Read/Write signal)
PD2 -> pin 11(DB4)
PD3 -> pin 12(DB5)
PD4 -> pin 13(DB6)
PD5 -> pin 14(DB7)

But there is not showing anything on the lcd-module! I checked all the wirings(all good)

As Bob guessed, that is NOT the way that the CV drivers expect the wiring to be made.

Have you looked under "lcd" in the Help subsystem or manual?
Have you looked at the lcddemo sample program?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am going to try it, indeed. You will hear it, when it works(or not).

PS. Yesterday it was to late for me, it is now 14.40 in the Netherlands, and when I posted my previous post, it was 10:54 PM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a trivial quastion, did you remember to tie DB0-3 on the LCD to ground? Also, did you hook pin3 on the LCD directly to ground? I allways take a potentiometer, one side to ground, other side to supply voltage and the "output pin" (using it as voltage divider) to the LCD pin3, then i can adjust the contrast so that it is perfect!

- Brian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I did that all. And it is not working. I only got yellow/black boxes on the first line. Soldered it again, so it has to be good.
And I use no longer codevision,I downloaded the lcdlibrary of pfleury. Changed the mode to 4 bit and changed PORTC to PORTD:

#if LCD_IO_MODE
/**
 *  @name Definitions for 4-bit IO mode
 *  Change LCD_PORT if you want to use a different port for the LCD pins.
 *
 *  The four LCD data lines and the three control lines RS, RW, E can be on the 
 *  same port or on different ports. 
 *  Change LCD_RS_PORT, LCD_RW_PORT, LCD_E_PORT if you want the control lines on
 *  different ports. 
 *
 *  Normally the four data lines should be mapped to bit 0..3 on one port, but it
 *  is possible to connect these data lines in different order or even on different
 *  ports by adapting the LCD_DATAx_PORT and LCD_DATAx_PIN definitions.
 *  
 */
#define LCD_PORT         PORTD        /**< port for the LCD lines   */
#define LCD_DATA0_PORT   LCD_PORT     /**< port for 4bit data bit 0 */
#define LCD_DATA1_PORT   LCD_PORT     /**< port for 4bit data bit 1 */
#define LCD_DATA2_PORT   LCD_PORT     /**< port for 4bit data bit 2 */
#define LCD_DATA3_PORT   LCD_PORT     /**< port for 4bit data bit 3 */
#define LCD_DATA0_PIN    0            /**< pin for 4bit data bit 0  */
#define LCD_DATA1_PIN    1            /**< pin for 4bit data bit 1  */
#define LCD_DATA2_PIN    2            /**< pin for 4bit data bit 2  */
#define LCD_DATA3_PIN    3            /**< pin for 4bit data bit 3  */
#define LCD_RS_PORT      LCD_PORT     /**< port for RS line         */
#define LCD_RS_PIN       4            /**< pin  for RS line         */
#define LCD_RW_PORT      LCD_PORT     /**< port for RW line         */
#define LCD_RW_PIN       5            /**< pin  for RW line         */
#define LCD_E_PORT       LCD_PORT     /**< port for Enable line     */
#define LCD_E_PIN        6            /**< pin  for Enable line     */

#elif defined(__AVR_AT90S4414__) || defined(__AVR_AT90S8515__) || defined(__AVR_ATmega64__) || \
      defined(__AVR_ATmega8515__)|| defined(__AVR_ATmega103__) || defined(__AVR_ATmega128__) || \
      defined(__AVR_ATmega161__) || defined(__AVR_ATmega162__)
/*
 *  memory mapped mode is only supported when the device has an external data memory interface
 */
#define LCD_IO_DATA      0xC000    /* A15=E=1, A14=RS=1                 */
#define LCD_IO_FUNCTION  0x8000    /* A15=E=1, A14=RS=0                 */
#define LCD_IO_READ      0x0100    /* A8 =R/W=1 (R/W: 1=Read, 0=Write   */
#else
#error "external data memory interface not available for this device, use 4-bit IO port mode"

#endif

This code uses Databit 0 - 4? And One port for RS, enable and RW pins?
The wiring I have:

http://www.geekland.org/e-dsp.com/wp-content/uploads/2006/02/LCD_schematic.gif, I only use portd instead portc.

[edit]Yes I saw this topic: https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes!! I've got 'text' on my lcd module, but only weird characters. I use the code from https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=44876, maybe the code is 8-bit? And I use 4 ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

naffets wrote:
This code uses Databit 0 - 4?.

Incorrect!

naffets wrote:
And One port for RS, enable and RW pins?

These share the same port as the data!

naffets wrote:
[The wiring I have:

http://www.geekland.org/e-dsp.com/wp-content/uploads/2006/02/LCD_schematic.gif, I only use portd instead portc.


But the schematic you linked us to uses:

PC7 = LCD D7, pin 14 = LCD Data D7/D3
PC6 = LCD D6, pin 13 = LCD Data D6/D2
PC5 = LCD D5, pin 12 = LCD Data D5/D1
PC4 = LCD D4, pin 11 = LCD Data D4/D0
PC3 = LCD D3, pin 10 = GND
PC2 = LCD D2, pin 09 = GND
PC1 = LCD D1, pin 08 = GND
PC0 = LCD D0, pin 07 = GND
PC3 = N/A
PC2 = LCD E, pin 6
PC1 = LCD R/W, pin 5
PC0 = LCD RS, pin 4

In 4-bit mode, D0 - D3 (Pin 7 - pin 10) of the get connected to COMON, GND, 0 VDC etc.

You should try to get the thing working the way the author designed it first. Then, after you figure it all out, change things to meet your specific requirements.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don not understand you clear. What I am doing wrong? I only use the D port and not the C port, like the schematic does.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

naffets wrote:
I don not understand you clear. What I am doing wrong? I only use the D port and not the C port, like the schematic does.

The schematic that you linked us to uses PORTC for both, the LCD data and the LCD control lines.

There is something very suspecious about the following:

#define LCD_IO_DATA      0xC000    /* A15=E=1, A14=RS=1                 */ 
#define LCD_IO_FUNCTION  0x8000    /* A15=E=1, A14=RS=0                 */ 
#define LCD_IO_READ      0x0100    /* A8 =R/W=1 (R/W: 1=Read, 0=Write   */ 

In particular:

#define LCD_IO_DATA      0xC000    /* A15=E=1, A14=RS=1

If this is truely the 4 bit data buss, 0xC000 is 0b1100:0000:0000:0000
You only have two bits of the 4 data bits defined as outputs, I presume. In addition, you moved the 4 bit data buss to D3:D0 but, this seems to put the 4 bit data at D7:D6 - and it seems to be two bits short of the required 4 data bits.

As I use the ImageCraft ICCAVR C compiler, I'm not familiar with the proper syntax of many of the other C compilers but, this whole arrangement seems to contradict the other defines that you have shown. And this doesn't even tak into consideration that you've defined 16 bit deffinitions, rather then 8 bit deffinitions.

Attachment(s): 

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is not my code, I used the library of Peter Fleury http://homepage.hispeed.ch/peterfleury/avr-software.html. The code I posted is a part of the .h file. That file you can change to 4-bit mode.
I don't like codevision, so I use AVR-studio(AVR-GCC).

What about the code in https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=277506#277506? How I can modify that to 4 bit mode? When you say 8-bit mode is better for me, I will use the 8-bit mode. And I have to modify it in to a 2 line LCD. When I use that code, changed it to portD (and C, like sinosoidal did) and only use my 4-bit wiring, I only get weird characters on the LCD.

BTW: The schematic came from this website: http://www.e-dsp.com/how-to-use-...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Changed the code of microcarl to:

#define __AVR_ATmega16__ 1
#include 
#define F_CPU 1000000


// Define LCD Register Select as PORTD 1;
#define LCD_RS PD1
// Define LCD Read/Write as PORTD 2;
#define LCD_RW PD2
// Define LCD Enable as PORTD 3;
#define LCD_E PD3  

// TURN ON POWER TO THE DISPLAY, NO CURSOR
#define   PWR_CMD   0x0C
// SET FOUR LINE, 8 DATA BIT MODE     
#define   DL_CMD   0x38
// CLEAR DISPLAY COMMAND     
#define CLR_DSP 0x01


#define LINE1 0x80
#define LINE2 0xC0
#define LINE3 0x94
#define LINE4 0xD4

#define NULL 0x00

const char BANNER_1[] = {"Having Fun"};
const char BANNER_2[] = {"With LCD's"};
const char BANNER_3[] = {"By"};
const char BANNER_4[] = {"Carl W. Livingston"};

void LCD_Delay (unsigned long int d);
void LCD_IO_INIT (void);
void LCD_INIT (void);
void LCD_PutCmd (char);
void LCD_PutChar (char);
void LCD_PutString (const char *);

void main (void)
{
    LCD_IO_INIT ();
   LCD_INIT ();
   
  // DDRD |= (1<<PD6); //PORTD 6 is for backlightcontrolr
  // PORTD |= (1<<PD6); //enable backlight

	DDRA |= (1<<PA0); //PORTA 0 for status led
	PORTA |= (1<<PA0); //turn on statusled

   while(1)
   {
       // Add other LCD related program operations here...
   }         
}

void LCD_Delay (unsigned long int d)
{
    unsigned long int n;
    for (n = 0; n < d; n++);
}

void LCD_IO_INIT (void)
{
    DDRC = 0xFF; // PORTC is the LCD DATA LINES
    PORTC = 0x00;
    DDRD |= (1<<LCD_E) | (1<<LCD_RW) | (1<<LCD_RS); // PORTD is the LCD CONTROL LINES
    PORTD |= (1<<LCD_E) | (1<<LCD_RS); // LCD_E = HIGH, LCD_RW = LOW, LCD_RS = HIGH
    LCD_Delay (500); // Wait for the up LCD to power up   
	
	
	      
}

void LCD_INIT (void)
{
    LCD_PutCmd (PWR_CMD); // Power up the display
    LCD_PutCmd (DL_CMD);  // Set to 4 lines, 8 bit, no cursor
    LCD_PutCmd (CLR_DSP); // Clear the display
    LCD_Delay (500); // Wait for the LCD to boot up   
   
   LCD_PutCmd (LINE1+5);
   LCD_PutString (BANNER_1);
   LCD_PutCmd (LINE2+5);
   LCD_PutString (BANNER_2);
   LCD_PutCmd (LINE3+9);
   LCD_PutString (BANNER_3);
   LCD_PutCmd (LINE4+1);
   LCD_PutString (BANNER_4);   
}
 
void LCD_PutCmd (char c)
{
  PORTD &= ~(1<<LCD_RS);
  LCD_Delay (5); // Wait for the display to respone to the E pulse
  LCD_PutChar(c);
  LCD_Delay (5); // Wait for the display to respone to the E pulse
  PORTD |= (1<<LCD_RS);
}

void LCD_PutChar (char c)
{
    PORTD |= (1<<LCD_E);
    LCD_Delay (5); // Wait for the display to respone to the E pulse   
    PORTC = c;
    LCD_Delay (5); // Wait for the display to respone to the E pulse
    PORTD &= ~(1<<LCD_E);
}
 
void LCD_PutString (const char *p)
{
    char n = NULL; // Pointer position counter.
    while (p[n] != NULL) // Keep sending data until the NULL character is found.
         LCD_PutChar(p[n++]);
} 

I only changed the ports, but it isn't working. I only get some boxes from my high contrast, decrease that contrast, won't help.

UPDATE: Changed the code a bit. Now I have also black boxes on the second line, but less black.

This code I found in this topic: https://www.avrfreaks.net/index.p... . It is the code of microcarl.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You keep saying "second line". An uninitialized display (all 2-liners that I am familiar with)) will show dark boxes on the >>top<< line.

Are you sure you have it right-side up?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes when I, with this code, turn on my whole project, both lines are black, not very black, but gray-black. (When I turn on the lcd, without the atmega16, then the first line only is black).

My idea is, that the lcd is enabled with the enable pin, but don't receive more.

BTW. I have to change the code to, 2 lines. Now it is 4. How I do that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

naffets wrote:
Yes when I with this code turn on my project, both lines are black, not very black, but gray-black. (When I turn on the lcd, without the atmega16, then the first line only is black).

So that tells me that the display is being initialized. The line addresses may not be correct for the display that you are using

naffets wrote:
BTW. I have to change the code to, 2 lines. Now it is 4. How I do that?

Change:

#define LINE1 0x80 
#define LINE2 0xC0 
#define LINE3 0x94 
#define LINE4 0xD4 

to:

#define LINE1 0x80 
#define LINE2 0xC0 

You may have to change 0x80 & 0xC0 to a value that conforms to the starting address of LINE1 & LINE2 for the particular display that you are using.

Change:

const char BANNER_1[] = {"Having Fun"}; 
const char BANNER_2[] = {"With LCD's"}; 
const char BANNER_3[] = {"By"}; 
const char BANNER_4[] = {"Carl W. Livingston"}; 

To:

const char BANNER_1[] = {"Having Fun"}; 
const char BANNER_2[] = {"With LCD's"}; 

And change:

LCD_PutCmd (LINE1+5); 
LCD_PutString (BANNER_1); 
LCD_PutCmd (LINE2+5); 
LCD_PutString (BANNER_2); 
LCD_PutCmd (LINE3+9); 
LCD_PutString (BANNER_3); 
LCD_PutCmd (LINE4+1); 
LCD_PutString (BANNER_4);

To:

LCD_PutCmd (LINE1+5); 
LCD_PutString (BANNER_1); 
LCD_PutCmd (LINE2+5); 
LCD_PutString (BANNER_2); 

Depending on which version of display you are using, you may have to change the LINE1 & LINE2 address.

Oh, by the way, you are using a datasheet for the display that you are using? My program is based on the timing and display addressing for the Optrix line of text based LCD displays but, I have also used this code for several other brands of "compatible" text based LCD manufactures.

But beware <<<Not all clone text based LCD displays are compatible!!!>>>

The Optrix datasheet does explaine everything required to successfully get an LCD display working.

If you need a copy of the full Optrix datasheet for their line of chatacter based LCD displays, I can either post it as an attachment or, I can e-mail it to.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Wed. Dec 27, 2006 - 07:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://www.asix-tools.com/download/pvk40/ks0066u.pdf That's the datasheet of the controller. On page 26 of that datasheet you find some timing data, how I have to modify that into my code?
What delay I need for 39 us ? When I use a clock speed of 1mhz?

Got the warning '../llcdetest.c:108: warning: subscript has type `char'
Is it possible that isn't correct, so my lcd isn't working correct?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have attached the PDF file for the Optrix line of character based displays.

Pay attention to pages 44 & 45 of the datasheet.

Attachment(s): 

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are two photo's
Before turning on the atmega16
http://avr.naffets.nl/IMG_5225.JPG
After turning on the atmega16
http://avr.naffets.nl/IMG_5224.JPG
(The photo's have to be turned 180 degrees)

That is what I see, not less and not more.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

naffets wrote:
On page 26 of that datasheet you find some timing data, how I have to modify that into my code?
What delay I need for 39 us ? When I use a clock speed of 1mhz?

All of the timing and delays were inclusive within the code that I posted! The code that I posted is running on a system that is running at 8.000 MHz so, you don't need to change any delays to run on a 1.000 MHz system.

naffets wrote:
Got the arning '../llcdetest.c:108: warning: subscript has type `char'
Is it possible that isn't correct, so my lcd isn't working correct?

If the compiler is complaining about a "char" and it is related to timing, you probably need an "int". In fact, if you look at the code that I posted, you'll find that I used a "long int" in the LCD_Delay() function.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The line 108 and 109 are

  while (p[n] != NULL) // Keep sending data until the NULL character is found.
         LCD_PutChar(p[n++]);

So that doesn't matter, like you said?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

naffets wrote:
Here are two photo's
Before turning on the atmega16
http://avr.naffets.nl/IMG_5225.JPG
After turning on the atmega16
http://avr.naffets.nl/IMG_5224.JPG
(The photo's have to be turned 180 degrees)

That is what I see, not less and not more.

As I said a post or two ago, the photo with the two active lines indicates that the display has been initialized.

Now you need to figure out the correct address of the first character in each line.

Also, if you aren't using my code any more, are you raising the RS line when sending text to the display? If not, you are only sending commands to the display and not displayable character data. If the RS line isn't brought high after initialization is complete, you think you are sending text to the display but, the display still thinks that text you think you are sending are commands.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

naffets wrote:
The line 108 and 109 are

  while (p[n] != NULL) // Keep sending data until the NULL character is found.
         LCD_PutChar(p[n++]);

So that doesn't matter, like you said?

Not true!

When the end of the character string is found (the NULL character or 0x00) the while loop:

while (p[n] != NULL) // Keep sending data until the NULL character is found.
         LCD_PutChar(p[n++]);

exits.

Are there more characters in the string being sent then there are in the display line? Remember, I'm directly addressing specific positions on a line and, behind the two lines you see, there are the other two lines that you don't see. They are still there - even though you only have a two line display.

At this point, you don't really know the starting address of the two lines that you do see. The text could very well be placed on the lines that you can't see.

As a test, you could create a text string about 40 characters long and see if you see any text at all. If you do see text, you don't have the correct LINE1 & LINE2 addressing. If you don't see any text, you need to study and get a good grasp of the initialization process of the particular display that you are using.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I still use your code, so I only have to figure out the right address of the first character of each line?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW.
When I see your code:

  LCD_PutCmd (PWR_CMD); // Power up the display
    LCD_PutCmd (DL_CMD);  // Set to 4 lines, 8 bit, no cursor

You first power the lcd on, and then set the 4 lines and 8bit.
When I see the datasheet, they alway set it to 8-bit first and then turn it on.(See page 41 of your posted datasheet)

After a test string of many characters, I don't see them :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is interesting. You are compiling Carl's example (that is known to compile and run with the imagecraft compiler) with the gcc compiler? No warnings?

Carl... in the putchar routine, shouldnt we put the char, then raise E, delay 500ns, lower E? Looks like your routine raises E, puts the char, lowers E, so if it latches on the rising edge of E, it aint there yet!

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes/no, I putted this code into the AVR studio editor and then compiled it. I only got 2 warnings on line 108 and 109(I Have posted them before) : '../llcdetest.c:108: warning: subscript has type `char`' Is is right that, that doesn't matter?(I understood that well?)
I looks the 'turn on' of the lcd is good, but futher.... You can see it on my to photos, I posted earlier.

Another question: why many 'experts' use ImageCraft?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Carl... in the putchar routine, shouldnt we put the char, then raise E, delay 500ns, lower E? Looks like your routine raises E, puts the char, lowers E, so if it latches on the rising edge of E, it aint there yet!

If you look at the timing in the datasheet, E rises, Data changes, you wait for data to change and stableize, E falls and latches the new data into the display.

Attachment(s): 

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok,

I've tested the following displays...

Hantronix HDM16216L-5-L30S, 2x16 display, controller - unknown
Optrex DMC16207, 2x16 display, controller - HD44780A00
Optrex DMC20434, 4x20 display, controller - HD44780A00
Hyundai HC20401NG-37, 4x20 display, controller - Samsung - S6A0069X01-80
QY-2004A, 4x20 display... Some Chinese clone, controller - unknown
161-HI-OD, 1x16 display... some Taiwanese clone, controller - HD44780A00

All of these displays worked with the posted code, as is. The exception being that the text was shifted on the 1x16 and 2x16 displays because I did not take the time to re-position them.

If I were you, I think I might be looking really hard at a wiring problem or possibly a deffective display.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

naffets wrote:
Another question: why any 'experts' use ImageCraft?

Its not that I'm an expert - I'm not. Its that you get what you pay for. While GCC is "Free", it doesn't have the support base that gives me a warm fuzzy feeling. With the exception of a few places, GCC isn't supported out side of user bases who are using it in their work. Allen Bradley uses GCC as the core C compiler for programming their Ultra 5000 servo drive series. There is literally no support for GCC - except what Allen Bradley will begrudgingly spoon feed you. Same for the GCC compiler targeted at the Motorola MC68HC11 family of UCs.

I had a problem with my notebook that wasn't even ImageCraft's problem but, they worked with me and solved my problem. Their thought was that, by fixing my problem and, being that this notebook was a new series of notebooks, they might illeviate future problems. Most other compiler (any software/hardware suppliers, for that matter) suppliers won't usually own up to the possibility that the problem could actually be theirs - as was the case with Dell regarding this same issue.

In addition, I get updates to problems and possible work-arounds, almost daily, from ImageCraft through their forum.

Where do you get that kind of support with the "Free-Bee" stuff, let alone companies like IAR, and the like, that require a high price maintenance agreement?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If we hooked the lcd up to the external memory bus, the E would be the ALE, and it would shake after the data was on the bus, so I guess the HW is happy if the data is thre when the E falls.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like I said, I tested six different displays from five different manufacturers - three displays are using the Hitachi HD44780A00 chip set, one display is using the Samsung S6A0069X01-80 chip set and, two displays with unknown controllers because the controller dies are covered with the black Gum-Drop.

All six controllers worked fine with the posted code.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Pages