[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Initilizing complex const arrays : syntax ?

From: Vincent Trouilliez
Subject: Re: [avr-gcc-list] Initilizing complex const arrays : syntax ?
Date: Tue, 20 Sep 2005 04:51:48 +0200

On Mon, 2005-09-19 at 20:22 -0500, David Kelly wrote:
> OK, 0.2ms max to write one, but how long to write two? Once the data is
> latched into the LCD it has to process and IIRC that is often 1 ms.

No, as I said it takes only 40us for the LCD to process a character.

You send a character to it, wait for 40us, send next character, wait
again 40us, and so on... 
So since we send 4 characters, that's 4 times 40us, 160us or so, no
more... and no less sadly ! ;-)

Maybe you were thinking of writing text to a graphic LCD module ? Maybe
these are slower, could be, ...dunno, never used one, as decent units
are outrageously expensive, way out of my budget... 

> Heck, just pulled that function out of the Doxygen comments in
> pgmspace.h. This may occupy less space and is sure to run faster:
>      buffer[0] = buffer[1] = buffer[2] = '0';

Ah, it compiles now :-) But the time is still the same... 6ms.

Oh wait a minute, I will comment out the 4 lines that send a character
to the LCD, just to prove that David is a bad mouth ;-) OH shocking, the
routine is now lightening fast, under a ms ! 
So I timed my lcd_putc() function, and it takes about 1.3ms to execute !
4 * 1.3 = 5.2, almost 6ms...this might explain that... :-/

The problem is that all lcd_putc() does is put the byte/character code
(in two strokes, high nibble first then low nibble) onto PORTA where the
LCD is attahce, then toggle the "Enable" pin of the LCD module, then
wait 45us (code below), so for the life of me I can't see how 45us wold
have turned into 1,300us !!!  But this is MARVELOUS news ! This means
that my analog "progress bar" (to give a graphical representation of an
engine parameter, along with its accurate numerical value ) routine I
did the other day and timed at 13ms, and was kinda disappointed, should
probably take in fact only a split ms !!! :o))

Wow, superb. But, I must first find the bug in lcd_putc() :-/
when I use _delay_ms(xxx) it is accurate, but in lcd_putc() I use
_delay_us() of course, let's see what it's doing exactly.. :-/


int lcd_putc(char car)

        lcd_send_byte( car, LCD_DATA );
        return 0;


void lcd_send_byte(unsigned char data, unsigned char type)

        LCD_PORT = type;        //select register or data

        //send high nibble
        //send low nibble
        lcd_send_nibble(data << 4);
        _delay_us(45);  //give LCD time to execute the command...

void lcd_send_nibble(unsigned char data)

        LCD_PORT |= LCD_E;      // rising edge on Enable pin
        data &= 0xF0;           //mask out low nibble, not to interfer with the 
control lines
        LCD_PORT &= 0x0F;       //clear data lines
        LCD_PORT |= data;       //copy nibble to port
        LCD_PORT &= ~LCD_E;     // falling edge on Enable pin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]