Frank,

 First let me say that the choice of 8 bit vs 4 bit is strictly a matter
 of personal taste and/or IO pin limitations. Also, in some cases, there
 are LCD displays out there that are 4 bit only.  I have some of these and
 this is the main reason I use 4 bit interface so much.

 Regarding your explanation, I'm not really sure what you're trying to tell
 me.  When I power up the LCD/uC combination, The uC initializes first.
 Then, when the program starts running, it initializes the LCD.  It does
 this starting in 8 bit first.  I send this 3 times.  After that, I change
 to 4 bit, and away we go.  If for some reason, the uC freezes or loses
 it's place, the watchdog timer will reset the uC and again reinitialize
 the LCD in the same manner as before.

 Lastly, again I'd say that the problem (or scenario) you speak of could
 possibly happen, but I have never experienced it.  And I've been using
 LCD's for many years.  Both professionally, and at home in my own projects.
 As for why it has to be sent 3 time, and not other numbers is beyond me.
 I don't know why that is.  And I guess to me it doesn't really matter.
 As long as I can in itialize the LCD and get it to do what I want, I
 don't really mind a slightly lengthy and somewhat illogical initialization
 sequence.

                                                 Regards,

                                                   Jim




>> This is the problem that I had some time ago. I discussed it
>> at length with
>> a rep from Noritake in Frankfurt (yyoshida@noritake.de). It
>> turned out that
>> the requirement to have at least 3 reset sequences (hex 30) at
>> initialisation is to avoid this particular problem. There are
>> still things I
>> don't understand, for instance, the number of reset sequences
>> could be any
>> odd number, but not even... Don't ask me why!
>
> Jan,
> Thanks for your reply.
> I have not used a LCD in 4bit mode anytime. The problem i've described,
> was theoretically (is it?).
> I have read the data sheet and it seems for me, that there is no chance
> to re-initiate the LCD.
> The command "function set" (0x30) is a regular command, which can be
> send to the LCD at anytime in two 4bit chunks, 0x3 followed by 0x0.
> How can the LCD differentiate between this regular command and the
> command as part of an initialisation sequence ?
> Furthermore the above initialisation sequence (3 times 0x30) are
> described in the data sheet in a context of inproper powerup. In this
> situation nothing can be supposed, every flip-flop can be set to any
> state. A good and reliable initialisation sequence must the be used.
> Again my question, how can the LCD differentiate ... ?
>
> Let me explain this example:
>                   uP
>                   LCD
>     send MSB of 0x8x (set DDRAM address)         LCD receives 0x8 (MSB
>     of
>set DDRAM address)
>     uP resets because of whatever                LCD is still working
>     uP sends 0x3 (1st part of init sequence)     LCD receives 0x3 as
>     LSB of
> DDRAM address
>     uP sends 0x3 (2nd part of init sequence)     LCD receives 0x3 as
>     MSB of
> fucntion set (8bit)
>     uP sends 0x3 (3rd part of init sequence)     LCD receives 0x3 as
>     LSB of
> function set
> --> uP sends 0x2 (set 4bit i/f)                  LCD receives 0x2 as
> MSB of function set (4bit)
>     uP sends MSB of 0x2x                         LCD receives 0x2 as
>     LSB uP sends LSB of 0x2x (N and F)               LCD receives
> 0x0/0x04/0x08/0x0c as ????
>     and so on
>
> The initialisation sequence has not set the LCD into 4bit mode after
> the uP was resetting, the controlling uP and the LCD are still out of
> sync. Have i missed something ?
> It seems for me that all should be ok if the marked line should not be
> executed.
>
> But that's all theory. I've never tested this. What the rep from
> Noritake has said is the same as the datasheet explains, but i can't
> verify this from my experience. Why any odd number of 0x3 ? It makes no
> sense for me.
>
> Because i must build the hardware first and then program (and debug)
> them (and there is no time for experiments), i have gone the best way
> and decided for 8bit mode interface.
>
> Frank
>
> GSP Sprachtechnologie GmbH
> Frank Wollenberg
> HW-Entwicklung
> Tel.:   +49 (0)30 769929-78
> Fax:    +49 (0)30 769929-12
> eMail:  f.wollenberg@gsp-berlin.de
>
>
> --
> GSP Sprachtechnologie GmbH
> Teltowkanalstr.1, D-12247 Berlin
> Tel.:  +49 (0)30 769929-0
> Fax:   +49 (0)30 769929-12
> eMail: Info@gsp-berlin.de
> Web:   http://www.gsp-berlin.de
>
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu