AFAIR HD44780 LCD displays are divided into two lines starting from 0
to 3Fh first and second starting from 40h to 79h. When You have more
than two line display it is possible that first line will continue in
third line, and second line will start in line numer two and continue
directly in line number four. It is possible to address cursor so to
write on second line You should set cursor address to 40h and start
writing - when You fill the line with characters, cursor will
jump/continue on line number four and later in the memory.
After WAY too much time, I finally got my LCD working tonight
gasp of relief here>. I still feel pretty dumb for having to spend a
week to accomplish this, but not as dumb as I would have felt if I
gave up and just accepted my overwhelming incompetence. :-) In any
case, thanks a lot for all the excellent (and patient) help I got on
this forum.
There's just one last question if anyone has time for it. I can
display things on the top two lines of the display, but I can't seem
to get any text displayed on lines 3 or 4 of the display. Does anyone
happen to know why this might be or know of an example of code for 4
line displays? I assume it's just an addressing issue, and I've
noticed that lines 1 and 3 seem to be line '1' and lines 2 and 4
seem
to be line '2'. I'm sure I'll figure it out eventually, but
if
someone knows off the top of their head how to write to each line, it
might save me a bit more head scratching myself.
Kevin.
Reply by ksdoubleshooter●October 6, 20082008-10-06
JC is correct about setting PINSEL2 to 0. This will set those pins
back to GPIO if they were set to the ETM function. However, they do
not default to the ETM function. The state of P1.20 is sampled
coming out of reset and if low, the ETM function is selected,
otherwise GPIO is selected.
I just brought up a new proto where this "bit" me.
Jeff
--- In l..., "J.C. Wren" wrote: >
> You need to set PINSEL2 to 0. The default is for those pins to come up for > the trace port.
>
> --jc
>
> On Mon, Oct 6, 2008 at 12:02 PM, Kevin Townsend wrote: >
> > I spent a bit of time individually checking all of the pins on my > > H2148 board, and noticed something really odd that
I'm sure is the > > cause of the problem.
> >
> > Of the pins between 1.16 and 1.31 on the H2148, 1.26..31 are reserved > > for JTAG, but I expected 1.16..25 (except 1.24) to
be available for > > normal GPIO. When I hooked each pin up to an
oscilloscope, though, it > > seems that only 1.16 and 1.22-25 are actually
working when I set and > > clear the pins. Looking at the schematic, I
can't see any reason pins > > 1.17..21 aren't working, and I passed
'PCB_PINSEL1 0x00000000;' to
> > make sure that GPIO is selected.
> >
> > Does this make sense to anyone? If the board is toasted, wouldn't all > > the pins fail?
> >
> >
> > http://www.olimex.com/dev/images/lpc-h2148-sch.gif
> >
> > Kevin.
> >
> >
> >
>
>
Reply by "J.C. Wren"●October 6, 20082008-10-06
PCB_PINSEL2_P12516_ means PINSEL2, Port 1, pins 25 through 16. Due to a
printing error in the manual, PCB_PINSEL2_P13626_ should REALLY be
PCB_PINSEL2_P12626_ or PCB_PINSEL2_P126_, since it only handles P1.26, not
P1.36 through P1.26. It ain't easy coming with names that aren't
50
characters long :)
For all my curmudgeonishnish and smacking down people that ask stupid
questions, I actually enjoy helping people that are putting effort into
trying to learn. It's very obvious that you're trying to figure out
what's
wrong, and you're asking good questions, not "my proggie doesn't work
why
please help NOW ur answer urgently neaded".
-jc
On Mon, Oct 6, 2008 at 12:38 PM, Kevin Townsend wrote:
> --- In l... , "J.C.
Wren"
> wrote:
> >
> > You need to set PINSEL2 to 0. The default is for those pins to come
> up for
> > the trace port.
> >
> > --jc
>
> Thanks again, and sorry if this is all fairly basic stuff.
>
> Out of curiousity, though, what is the logic behind the numbering on
> the following defines (ex. P13626, P12516). I don't remember seeing
> PINSEL2 in the previous lpc210x.h file.
>
> #define PCB_PINSEL2_P13626_GPIO ((unsigned int) 0x00000000)
> #define PCB_PINSEL2_P13626_DEBUG ((unsigned int) 0x00000004)
> #define PCB_PINSEL2_P13626_MASK ((unsigned int) 0x00000004)
>
> #define PCB_PINSEL2_P12516_GPIO ((unsigned int) 0x00000000)
> #define PCB_PINSEL2_P12516_TRACE ((unsigned int) 0x00000008)
> #define PCB_PINSEL2_P12516_MASK ((unsigned int) 0x00000008)
>
> In any case, thanks again for your help ... I really appreciate you
> taking the time to share your expertise, and hope someone else finds
> it useful as well down the road.
>
> Kevin
>
>
>
Reply by Kevin Townsend●October 6, 20082008-10-06
--- In l..., "J.C. Wren" wrote: >
> You need to set PINSEL2 to 0. The default is for those pins to come up for > the trace port.
>
> --jc
Thanks again, and sorry if this is all fairly basic stuff.
Out of curiousity, though, what is the logic behind the numbering on
the following defines (ex. P13626, P12516). I don't remember seeing
PINSEL2 in the previous lpc210x.h file.
In any case, thanks again for your help ... I really appreciate you
taking the time to share your expertise, and hope someone else finds
it useful as well down the road.
Kevin
Reply by "J.C. Wren"●October 6, 20082008-10-06
You need to set PINSEL2 to 0. The default is for those pins to come up for
the trace port.
--jc
On Mon, Oct 6, 2008 at 12:02 PM, Kevin Townsend wrote:
> I spent a bit of time individually checking all of
the pins on my
> H2148 board, and noticed something really odd that I'm sure is the
> cause of the problem.
>
> Of the pins between 1.16 and 1.31 on the H2148, 1.26..31 are reserved
> for JTAG, but I expected 1.16..25 (except 1.24) to be available for
> normal GPIO. When I hooked each pin up to an oscilloscope, though, it
> seems that only 1.16 and 1.22-25 are actually working when I set and
> clear the pins. Looking at the schematic, I can't see any reason pins
> 1.17..21 aren't working, and I passed 'PCB_PINSEL1 =
0x00000000;' to
> make sure that GPIO is selected.
>
> Does this make sense to anyone? If the board is toasted, wouldn't all
> the pins fail?
> http://www.olimex.com/dev/images/lpc-h2148-sch.gif
>
> Kevin.
>
>
>
Reply by Kevin Townsend●October 6, 20082008-10-06
I spent a bit of time individually checking all of the pins on my
H2148 board, and noticed something really odd that I'm sure is the
cause of the problem.
Of the pins between 1.16 and 1.31 on the H2148, 1.26..31 are reserved
for JTAG, but I expected 1.16..25 (except 1.24) to be available for
normal GPIO. When I hooked each pin up to an oscilloscope, though, it
seems that only 1.16 and 1.22-25 are actually working when I set and
clear the pins. Looking at the schematic, I can't see any reason pins
1.17..21 aren't working, and I passed 'PCB_PINSEL1 = 0x00000000;'
to
make sure that GPIO is selected.
Does this make sense to anyone? If the board is toasted, wouldn't all
the pins fail?
If u had two line display one of the line will be.
in four lines alternate lines would be darker.
Natarajan
--- On Mon, 10/6/08, Kevin Townsend wrote:
From: Kevin Townsend
Subject: [lpc2000] Re: HD44780 Initialisation (20x4 display in 4-bit mode)
To: l...
Date: Monday, October 6, 2008, 3:57 AM
I was wondering if someone could confirm for me if it was normal that
when I add power to my 20x4 display, and connect the third pin to a
10K resistor on pin 1 and 2 (for contrast), that I have two lines of
solid blocks and two empty lines. I've attached a photo for reference
sake:
Also, I hooked up a cheapo ebay oscilloscope that I bought, and
noticed when monitoring the different pins that the 4 data bits seems
to work (I see activity going up and down), but I don't seem to get
any response out of the E pin when it should be bouncing up and down
as I enter the following methods:
Admittedly, I'm completely new to all this, but shouldn't the IOSET
and IOCLR cause the pin to go up and down on the 'scope? I'm sure
it
it connected to the probe properly, and the connection is fine between
the 2148 and the LCD board ... any ideas what might be explain this?
I've attached another image to show what I mean, with the breakpoint
on the left (after I've entered the method a few times):
Reply by Sumit Bhatnagar●October 5, 20082008-10-05
I also plan to use a 16X2 LCD with the LPCH2148. I am at the same stage as
you are. 1 row blanc and other black.
I ran into the same issue with the PIC16F684 while trying to interface that
to the LCD. I did not proceed further to resolve that completely.
I am therefore planning on a differnt approach with the LPCH2148. I have got the
schematic for the IAR LPC 2148 R2T. I will be connecting the LPCH2148 with the
LCD per the schematic and then run the sample code that comes with the IAR. I am
hoping this will work. Later I will modify the code to suit the pinout I
decide.
-sumit
----- Original Message ----
From: J.C. Wren
To: l...
Sent: Sunday, 5 October, 2008 7:32:28 PM
Subject: Re: [lpc2000] Re: HD44780 Initialisation (20x4 display in 4-bit
mode)
I've added LCD functionality to LPC-2148 demo code that I'm getting
ready to
release. In the mean time, I've put the lcd_4bit.c file that I got
working
today up at http://jcwren. com/arm The actual display I tested with is a
CrystalFontz CFAH1602Z-YYH- ET. This is a standard HD44780-based LCD, so it
should work the same as yours.
Until you get your display working, I'd suggest replacing
the lcdWaitWhileBusy( ) routine with a hard 30 millisecond delay. It'll
make
the display look like a teletype when it's writing (which is sorta cool,
if
you don't need to print lots of stuff).
I'm still looking at what you've currently got to see if I can find
where it
went wrong.
I've added LCD functionality to LPC-2148 demo code that I'm getting
ready to
release. In the mean time, I've put the lcd_4bit.c file that I got
working
today up at http://jcwren.com/arm The actual display I tested with is a
CrystalFontz CFAH1602Z-YYH-ET. This is a standard HD44780-based LCD, so it
should work the same as yours.
Until you get your display working, I'd suggest replacing
the lcdWaitWhileBusy() routine with a hard 30 millisecond delay. It'll
make
the display look like a teletype when it's writing (which is sorta cool,
if
you don't need to print lots of stuff).
I'm still looking at what you've currently got to see if I can find
where it
went wrong.
