Lpc2000

Has anyone used a dot-matrix display? I have an LCD (128x64), model
no. HDG12864F-1.

I have previous source code but its so complex, i cannot understand
it. its poorly documented too. If anyone can share the algorithm
behind sending display characters to a dot matrix display.

What i want to do : 
some_function( "Display this" ) -> On the LCD: Display this

What I can do:
I can make a single for loop which has pointers to an array of hex
files mapped out to be characters. Result? each character display
reqiures a for loop. :(

Not too efficient on the big O notation. (Random sense)

Anyways, help? :P

Quoting wickedmonster2002 <karim@...>:
> Has anyone used a dot-matrix display? I have an LCD (128x64), model
> no. HDG12864F-1.
>
> I have previous source code but its so complex, i cannot understand
> it. its poorly documented too. If anyone can share the algorithm
> behind sending display characters to a dot matrix display.
>
> What i want to do :
> some_function( "Display this" ) -> On the LCD: Display this
>
> What I can do:
> I can make a single for loop which has pointers to an array of hex
> files mapped out to be characters. Result? each character display
> reqiures a for loop. :(
>
> Not too efficient on the big O notation. (Random sense)

No matter what happens you have to copy N dots to the display for each
character.  With intelligence on the display that could mean the 
display itself
handles the copying but if all you have is a 'bunch o pixels' then you have to
set each one.  Try looking up bitblt which is a generalized graphics copying
technique.

The only question is whether to store strokes or bits.  And with the low
resolution you have I doubt a stroke based font will be very pretty, at least
w/o a lot of work.

Anyway O(n) is not bad.  With a 8x8 font, n is at most 128.  I rather 
expect the
bandwidth to the diplay will limit you more than the for loop overhead.  It
might even be possible to compress the font definition if space is tight and
not affect your runtime timing.

If you can do a string print routine better than O(n) I'd like to see 
how.  (No
sarcasm meant there, I don't see how it's possible but ....)


Robert

wickedmonster2002 schrieb:
> What i want to do : 
> some_function( "Display this" ) -> On the LCD: Display this

If the display-chip has no character-rom you need to have a font
in the LPC.
In order to display a character you need to send all byte for it
to the LCD.

-- 
42Bastian

--- In lpc2000@yahoogroups.com, "wickedmonster2002" <karim@...> wrote:
>
> Has anyone used a dot-matrix display? I have an LCD (128x64), model
> no. HDG12864F-1.
> 
> Anyways, help? :P
>

http://www.circuitcellar.com/library/details/0400/c0400cd4.htm

Since you said "Its soo complex and poorly documented" I'm going to guess
that your using the glcd package which is nice and fully featured but its
hard to start using without experience or sitting down and following the
code. (If your code has #include <gdisp.h> its likely that you are using
glcd)

If you want the basics of using the Hantronix displays, like the
HDM12864F-1, which has a S6B0724 controller at its heart then search
google for "S6B0724 sample code". This one is the most helpful,
www.8052.com/users/mkaras/GraphLCD.phtml, and in looking at it and the
glcd package as sold by ramtex it looks like it was the starting point for
glcd.

If you have your code working and you just want to display strings (like
printf to your lcd) try:


ginit();  // Initialize the display hardware interface hardware

ghw_dispon(); // Command the display to turn on

gselfont(&mono5_8);  // Select a soft font, look in your include directory
                     // to see what fonts your system has used

gsetcpos(0,0); // 0th line over from the left, 1st line down (no zero)
gputs("Line1");

gsetcpos(0,1); // 0th line over from the left, 1st line down (no zero)
gputs("Line2");


I hope this helps and if you have more questions just post them.

Richard Newman
Pittsburgh PA USA

Hello People,

Thank you for your response and your algorithms and ideas.

Actually, I just came across glcd.c code. And yes, it is complex. But
 I will try to utilize some of its techniques.

I have a font definition file ready in the previous source files. It
goes like this:

_font1def:  ;address 0400
          .DATA.B     H'00, H'7e, H'11, H'11, H'11, H'7e  ; A  Asc 41
          .DATA.B     H'00, H'7f, H'49, H'49, H'49, H'36  ; B  Asc 42
          ....so on and so forth.

This is in an asm file, and i was thinking if i could use this instead
of making my own.

Question is, how do i use it? Is this ARM compatible asm file? Can i
just access the data as an array, or do i change it to C format?

Thanks again,

M.


--- In lpc2000@yahoogroups.com, "wickedmonster2002" <karim@...> wrote:

>
> Has anyone used a dot-matrix display? I have an LCD (128x64), model
> no. HDG12864F-1.
> 
> I have previous source code but its so complex, i cannot understand
> it. its poorly documented too. If anyone can share the algorithm
> behind sending display characters to a dot matrix display.
> 
> What i want to do : 
> some_function( "Display this" ) -> On the LCD: Display this
> 
> What I can do:
> I can make a single for loop which has pointers to an array of hex
> files mapped out to be characters. Result? each character display
> reqiures a for loop. :(
> 
> Not too efficient on the big O notation. (Random sense)
> 
> Anyways, help? :P
>

BTW, I am using Keil Uvision tools.



--- In lpc2000@yahoogroups.com, "wickedmonster2002" <karim@...> wrote:

>
> Has anyone used a dot-matrix display? I have an LCD (128x64), model
> no. HDG12864F-1.
> 
> I have previous source code but its so complex, i cannot understand
> it. its poorly documented too. If anyone can share the algorithm
> behind sending display characters to a dot matrix display.
> 
> What i want to do : 
> some_function( "Display this" ) -> On the LCD: Display this
> 
> What I can do:
> I can make a single for loop which has pointers to an array of hex
> files mapped out to be characters. Result? each character display
> reqiures a for loop. :(
> 
> Not too efficient on the big O notation. (Random sense)
> 
> Anyways, help? :P
>

You have to tell us what you have to work with so that we can help you
with the shortest possible path. Since you did not I'm going to
interrogate you but eventually I'll get tired and abandon this thread. So
here goes:

1) You said you already had code working. Is that the glcd code?  Does
your working code use the header gdisp.h?  If you have gdisp.h then your
working code uses glcd from somewhere other than 8052.com. Tell us if your
code has gdisp.h in it.

2) If your using glcd code (the one with gdisp.h in it)  then it already
has font files and they are available for you to use. I will wait to
demonstrate how to use them based on your answer to question 1.

3) If your NOT using glcd then the shortest path to success is the url
which I previously gave you. Here it is again:
http://www.8052.com/users/mkaras/GraphLCD.phtml
This gLCD code does what you want to do: Write text characters to the
display using a font which is already specified in the headers and he
shows you how to use them. In this scenario there is no reason to use your
existing font files or explain how to get your compiler to point to them
because the examples show you how.

Wait!  Are you telling me the code from MKaras from 8052.com is complex?
Please say no. If you want complex and no documentation then buy  gLCD
from Ramtex and write me back. The code is at least 30 times the size,
with lots of features like windowing, and harder to get started with.
There are at least 60 files in the Ramtex distribution of gLCD.

Finally- Are you telling us that what you really want is a example simpler
than the gLCD code from mkaras off the 8052 site?  In my opinion that
would be what you started with, the example that displays a bitmap. Want
to display simple characters crt style?  The answer, with this display, is
you have to use a font file and stuff it out rows at a time, 5 rows of 8
bytes for each character and then add some for intercharacter spacing. Its
not as simple as writing a character to a serial port or calling printf
but if you get the code working you can encapsulate all the non-trivial
stuff behind printf or debug_printf and your life is easy until you start
using another graphic display. Work like this takes work and the gLCD code
off of 8052.com is the shortest path to plugging and playing.

Again, I hope this helps and if you have more questions just continue
posting them.

Richard Newman
Pittsburgh PA USA

Wow, i feel like i m being grilled for murder.


--- In lpc2000@yahoogroups.com, newmanrf@... wrote:
>
> 
> You have to tell us what you have to work with so that we can help you
> with the shortest possible path. Since you did not I'm going to
> interrogate you but eventually I'll get tired and abandon this
thread. So
> here goes:
> 
> 1) You said you already had code working. Is that the glcd code?  Does
> your working code use the header gdisp.h?  If you have gdisp.h then your
> working code uses glcd from somewhere other than 8052.com. Tell us
if your
> code has gdisp.h in it.


No! It does not have gdisp.h in it.



> 
> 2) If your using glcd code (the one with gdisp.h in it)  then it already
> has font files and they are available for you to use. I will wait to
> demonstrate how to use them based on your answer to question 1.


See question 1.

> 
> 3) If your NOT using glcd then the shortest path to success is the url
> which I previously gave you. Here it is again:
> http://www.8052.com/users/mkaras/GraphLCD.phtml
> This gLCD code does what you want to do: Write text characters to the
> display using a font which is already specified in the headers and he
> shows you how to use them. In this scenario there is no reason to
use your
> existing font files or explain how to get your compiler to point to them
> because the examples show you how.


Yes. I saw that. I will try doing that next.



> 
> Wait!  Are you telling me the code from MKaras from 8052.com is complex?
> Please say no. 


Okay. No. I dont find the code complex. Its a bit easier on the eyes.
I said the glcd.c with the gdisp.h in it was complex. You must have
misunderstood. Sorry about that.



If you want complex and no documentation then buy  gLCD
> from Ramtex and write me back. The code is at least 30 times the size,
> with lots of features like windowing, and harder to get started with.
> There are at least 60 files in the Ramtex distribution of gLCD.
> 
> Finally- Are you telling us that what you really want is a example
simpler
> than the gLCD code from mkaras off the 8052 site? 

I think its simple enough. I have zero experience in graphic displays.
I had no idea we had to use fonts. I even interpreted fonts as
something coming off the Windows operating system, a complete layman
view. Laugh at my intelligence but you know, I gotta start somewhere.

 In my opinion that
> would be what you started with, the example that displays a bitmap. Want
> to display simple characters crt style?  The answer, with this
display, is
> you have to use a font file and stuff it out rows at a time, 5 rows of 8
> bytes for each character and then add some for intercharacter
spacing. Its
> not as simple as writing a character to a serial port or calling printf
> but if you get the code working you can encapsulate all the non-trivial
> stuff behind printf or debug_printf and your life is easy until you
start
> using another graphic display. Work like this takes work and the
gLCD code
> off of 8052.com is the shortest path to plugging and playing.
> 
> Again, I hope this helps and if you have more questions just continue
> posting them.

Thanks a lot. That site really helped.

M.

> 
> Richard Newman
> Pittsburgh PA USA
>

--- In lpc2000@yahoogroups.com, newmanrf@... wrote:

> 3) If your NOT using glcd then the shortest path to success is the url
> which I previously gave you. Here it is again:
> http://www.8052.com/users/mkaras/GraphLCD.phtml

Thanks for the link.  I just started a project using a 640x480 LCD
panel http://tinyurl.com/lmcoh using the frame buffer logic design
from http://www.nyx.net/%7Ejpurbric/lcd  See lcd.gif.

Sure, the panel is only $11.  It's the odd bits to make it work that
add time and money.

Thanks again!
Rchard

wickedmonster2002 wrote:

>Wow, i feel like i m being grilled for murder.
>
>  
>
And, um, you thought that writing embedded code was as easy as Visual Basic?

TomW

>--- In lpc2000@yahoogroups.com, newmanrf@... wrote:
>  
>
>>You have to tell us what you have to work with so that we can help you
>>with the shortest possible path. Since you did not I'm going to
>>interrogate you but eventually I'll get tired and abandon this
>>    
>>
>thread. So
>  
>
>>here goes:
>>
>>1) You said you already had code working. Is that the glcd code?  Does
>>your working code use the header gdisp.h?  If you have gdisp.h then your
>>working code uses glcd from somewhere other than 8052.com. Tell us
>>    
>>
>if your
>  
>
>>code has gdisp.h in it.
>>    
>>
>
>
>No! It does not have gdisp.h in it.
>
>
>
>  
>
>>2) If your using glcd code (the one with gdisp.h in it)  then it already
>>has font files and they are available for you to use. I will wait to
>>demonstrate how to use them based on your answer to question 1.
>>    
>>
>
>
>See question 1.
>
>  
>
>>3) If your NOT using glcd then the shortest path to success is the url
>>which I previously gave you. Here it is again:
>>http://www.8052.com/users/mkaras/GraphLCD.phtml
>>This gLCD code does what you want to do: Write text characters to the
>>display using a font which is already specified in the headers and he
>>shows you how to use them. In this scenario there is no reason to
>>    
>>
>use your
>  
>
>>existing font files or explain how to get your compiler to point to them
>>because the examples show you how.
>>    
>>
>
>
>Yes. I saw that. I will try doing that next.
>
>
>
>  
>
>>Wait!  Are you telling me the code from MKaras from 8052.com is complex?
>>Please say no. 
>>    
>>
>
>
>Okay. No. I dont find the code complex. Its a bit easier on the eyes.
>I said the glcd.c with the gdisp.h in it was complex. You must have
>misunderstood. Sorry about that.
>
>
>
>If you want complex and no documentation then buy  gLCD
>  
>
>>from Ramtex and write me back. The code is at least 30 times the size,
>>with lots of features like windowing, and harder to get started with.
>>There are at least 60 files in the Ramtex distribution of gLCD.
>>
>>Finally- Are you telling us that what you really want is a example
>>    
>>
>simpler
>  
>
>>than the gLCD code from mkaras off the 8052 site? 
>>    
>>
>
>I think its simple enough. I have zero experience in graphic displays.
>I had no idea we had to use fonts. I even interpreted fonts as
>something coming off the Windows operating system, a complete layman
>view. Laugh at my intelligence but you know, I gotta start somewhere.
>
> In my opinion that
>  
>
>>would be what you started with, the example that displays a bitmap. Want
>>to display simple characters crt style?  The answer, with this
>>    
>>
>display, is
>  
>
>>you have to use a font file and stuff it out rows at a time, 5 rows of 8
>>bytes for each character and then add some for intercharacter
>>    
>>
>spacing. Its
>  
>
>>not as simple as writing a character to a serial port or calling printf
>>but if you get the code working you can encapsulate all the non-trivial
>>stuff behind printf or debug_printf and your life is easy until you
>>    
>>
>start
>  
>
>>using another graphic display. Work like this takes work and the
>>    
>>
>gLCD code
>  
>
>>off of 8052.com is the shortest path to plugging and playing.
>>
>>Again, I hope this helps and if you have more questions just continue
>>posting them.
>>    
>>
>
>Thanks a lot. That site really helped.
>
>M.
>
>
>  
>
>>Richard Newman
>>Pittsburgh PA USA
>>
>>    
>>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

If you don't want to have the effort of creating fonts etc, you may use one 
of the intelligent iLCD panels from www.ilcd.info

You can load any Windows font into the flash memory of the board and have 
high level rendering routines (with alignment and word wrap). Besides that 
you can use any graphics (inluding animated GIFs) created on the PC without 
having to write some code. The only thing you have to do is to communicate 
with the panel via a serial port.

Regards
Herbert

At 21:10 24.05.2006 +0000, you wrote:
>Wow, i feel like i m being grilled for murder.
>
>
>--- In lpc2000@yahoogroups.com, newmanrf@... wrote:
> >
> >
> > You have to tell us what you have to work with so that we can help you
> > with the shortest possible path. Since you did not I'm going to
> > interrogate you but eventually I'll get tired and abandon this
>thread. So
> > here goes:
> >
> > 1) You said you already had code working. Is that the glcd code?  Does
> > your working code use the header gdisp.h?  If you have gdisp.h then your
> > working code uses glcd from somewhere other than 8052.com. Tell us
>if your
> > code has gdisp.h in it.
>
>
>No! It does not have gdisp.h in it.
>
>
>
> >
> > 2) If your using glcd code (the one with gdisp.h in it)  then it already
> > has font files and they are available for you to use. I will wait to
> > demonstrate how to use them based on your answer to question 1.
>
>
>See question 1.
>
> >
> > 3) If your NOT using glcd then the shortest path to success is the url
> > which I previously gave you. Here it is again:
> > 
> <http://www.8052.com/users/mkaras/GraphLCD.phtml>http://www.8052.com/users/mkaras/GraphLCD.phtml
> > This gLCD code does what you want to do: Write text characters to the
> > display using a font which is already specified in the headers and he
> > shows you how to use them. In this scenario there is no reason to
>use your
> > existing font files or explain how to get your compiler to point to them
> > because the examples show you how.
>
>
>Yes. I saw that. I will try doing that next.
>
>
>
> >
> > Wait!  Are you telling me the code from MKaras from 8052.com is complex?
> > Please say no.
>
>
>Okay. No. I dont find the code complex. Its a bit easier on the eyes.
>I said the glcd.c with the gdisp.h in it was complex. You must have
>misunderstood. Sorry about that.
>
>
>
>If you want complex and no documentation then buy  gLCD
> > from Ramtex and write me back. The code is at least 30 times the size,
> > with lots of features like windowing, and harder to get started with.
> > There are at least 60 files in the Ramtex distribution of gLCD.
> >
> > Finally- Are you telling us that what you really want is a example
>simpler
> > than the gLCD code from mkaras off the 8052 site?
>
>I think its simple enough. I have zero experience in graphic displays.
>I had no idea we had to use fonts. I even interpreted fonts as
>something coming off the Windows operating system, a complete layman
>view. Laugh at my intelligence but you know, I gotta start somewhere.
>
>In my opinion that
> > would be what you started with, the example that displays a bitmap. Want
> > to display simple characters crt style?  The answer, with this
>display, is
> > you have to use a font file and stuff it out rows at a time, 5 rows of 8
> > bytes for each character and then add some for intercharacter
>spacing. Its
> > not as simple as writing a character to a serial port or calling printf
> > but if you get the code working you can encapsulate all the non-trivial
> > stuff behind printf or debug_printf and your life is easy until you
>start
> > using another graphic display. Work like this takes work and the
>gLCD code
> > off of 8052.com is the shortest path to plugging and playing.
> >
> > Again, I hope this helps and if you have more questions just continue
> > posting them.
>
>Thanks a lot. That site really helped.
>
>M.
>
>
> >
> > Richard Newman
> > Pittsburgh PA USA
> >
>
>
>
>
>
>SPONSORED LINKS
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&c=3&s=69&.sig=c-HXthtbZy4TZbI3ib0PMg>Microcontrollers 
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&c=3&s=69&.sig=ijt0SspWtjogcHCuFD0lUQ>Microprocessor 
><http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&c=3&s=69&.sig=WOZdpklkgHbXR5quAgrl5w>Intel 
>microprocessors
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000" 
> on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    * 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com 
>
>    *
>    *  Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------


[Non-text portions of this message have been removed]

The gLCD from M Karas has storage classes defined as 'code' and
'xdata'. One is ROM and the other is RAM, i believe. How can I
replicate this in ARM standards in Keil? 










--- In lpc2000@yahoogroups.com, newmanrf@... wrote:
>
> 
> You have to tell us what you have to work with so that we can help you
> with the shortest possible path. Since you did not I'm going to
> interrogate you but eventually I'll get tired and abandon this
thread. So
> here goes:
> 
> 1) You said you already had code working. Is that the glcd code?  Does
> your working code use the header gdisp.h?  If you have gdisp.h then your
> working code uses glcd from somewhere other than 8052.com. Tell us
if your
> code has gdisp.h in it.
> 
> 2) If your using glcd code (the one with gdisp.h in it)  then it already
> has font files and they are available for you to use. I will wait to
> demonstrate how to use them based on your answer to question 1.
> 
> 3) If your NOT using glcd then the shortest path to success is the url
> which I previously gave you. Here it is again:
> http://www.8052.com/users/mkaras/GraphLCD.phtml
> This gLCD code does what you want to do: Write text characters to the
> display using a font which is already specified in the headers and he
> shows you how to use them. In this scenario there is no reason to
use your
> existing font files or explain how to get your compiler to point to them
> because the examples show you how.
> 
> Wait!  Are you telling me the code from MKaras from 8052.com is complex?
> Please say no. If you want complex and no documentation then buy  gLCD
> from Ramtex and write me back. The code is at least 30 times the size,
> with lots of features like windowing, and harder to get started with.
> There are at least 60 files in the Ramtex distribution of gLCD.
> 
> Finally- Are you telling us that what you really want is a example
simpler
> than the gLCD code from mkaras off the 8052 site?  In my opinion that
> would be what you started with, the example that displays a bitmap. Want
> to display simple characters crt style?  The answer, with this
display, is
> you have to use a font file and stuff it out rows at a time, 5 rows of 8
> bytes for each character and then add some for intercharacter
spacing. Its
> not as simple as writing a character to a serial port or calling printf
> but if you get the code working you can encapsulate all the non-trivial
> stuff behind printf or debug_printf and your life is easy until you
start
> using another graphic display. Work like this takes work and the
gLCD code

> off of 8052.com is the shortest path to plugging and playing.
> 
> Again, I hope this helps and if you have more questions just continue
> posting them.
> 
> Richard Newman
> Pittsburgh PA USA
>

--- In lpc2000@yahoogroups.com, "wickedmonster2002" <karim@...> wrote:
>
> 
> 
> The gLCD from M Karas has storage classes defined as 'code' and
> 'xdata'. One is ROM and the other is RAM, i believe. How can I
> replicate this in ARM standards in Keil? 
> 

You need to look at the context of things in XDATA to determine
whether it is ROM or RAM.  All XDATA means to the 8051 is that it is
external memory.

See for example http://www.esacademy.com/faq/docs/51memmodel/
BTW, Google is your friend...

If I were writing this type of thing for the LPC2106 (I am actually
working on the project with the ATmega128), I would put the code and
fonts in program memory (flash) as I have 128k bytes to work with.

I don't know how your setup implements the frame buffer so I'll just
stop here.  Unless you have DMA, you probably can't use internal RAM
for the buffer.  You can use internal RAM as a mirror of the frame
buffer and that may be a reasonable way to go.  I haven't thought
about it...

Or maybe your controller has a frame buffer and all you need to do is
read/write it.

Richard

The ARM architecture is, of course, flat with code and data able to be put
anywhere therefore you can run code out of your ram as well as your flash
and you can write to your code space so its easy to program flash. So for
all intents and purposes of this discussion don\ufffdt pay attention to what\ufffds
in code and what\ufffds in data just get the code running and in order to do
that take the following advice:

Get rid of: #pragma CODE

Change: const unsigned char code l_mask_array[8]
to: unsigned char l_mask_array[8]

Change: unsigned char xdata l_display_array[Y_BYTES][X_BYTES];

to: unsigned char l_display_array[Y_BYTES][X_BYTES];

And I think that you should be on your way with that file.

I hope this helps and please ask additional questions as a follow-up.

Richard Newman
Pittsburgh PA USA

Quoting newmanrf@...:
> The ARM architecture is, of course, flat with code and data able to be put
> anywhere therefore you can run code out of your ram as well as your flash
> and you can write to your code space so its easy to program flash. So for
> all intents and purposes of this discussion don’t pay attention to what’s
> in code and what’s in data just get the code running and in order to do
> that take the following advice:
>
> Get rid of: #pragma CODE
>
> Change: const unsigned char code l_mask_array[8]
> to: unsigned char l_mask_array[8]

Question:  Why get rid of const?  I would have thought you would still 
want this
in flash.

Robert

Ok. To clear some things up.

I m using an LPC2210 on a Phytec board. No internal memory except 16kB
of RAM. I am using 2M of external flash and 1M of external RAM.

I have followed your advice, Richard, and removed all code and xdata
instances. I have modified lcd_update, where it says lcd_dat_out so
that i can implement my own SPI serial send because gLCD uses a
primitive 'bit banging' function to do its serial send (i think i m
right on this). 

The declaration of my SPI serial send is a simple function API called
'writedisplay(data, com)' where 'com' is to let the LCD know that what
i m sending is either a command or data and parameter 'data' is simply
hex numerals. 

i use a similar SPI function to the one stated in one of the LPC
application notes. 

I still have nothing on my display after all that and my writedisplay
function works because i have it working perfectly on another project.

Anymore ideas? I cannot really say more on the project. I would have
to kill you all. Hehehe ;)

Feel free to abandon the thread if you guys feel tired of my
inexperience in these matters. :}

Thanks.

M.


--- In lpc2000@yahoogroups.com, newmanrf@... wrote:
>
> 
> The ARM architecture is, of course, flat with code and data able to
be put
> anywhere therefore you can run code out of your ram as well as your
flash
> and you can write to your code space so its easy to program flash.
So for
> all intents and purposes of this discussion don't pay attention to
what's

> in code and what's in data just get the code running and in order to do
> that take the following advice:
> 
> Get rid of: #pragma CODE
> 
> Change: const unsigned char code l_mask_array[8]
> to: unsigned char l_mask_array[8]
> 
> Change: unsigned char xdata l_display_array[Y_BYTES][X_BYTES];
> 
> to: unsigned char l_display_array[Y_BYTES][X_BYTES];
> 
> And I think that you should be on your way with that file.
> 
> I hope this helps and please ask additional questions as a follow-up.
> 
> Richard Newman
> Pittsburgh PA USA
>

I'm assuming you did not change much if anything in Michael Karas's main
that\ufffds included with the gLCD files off of 8052.com. So being that\ufffds the
case now its time for deep troubleshooting. Believe it or not you have
just begun so either get coffee or a beer and snuggle up to your work
bench.

Zip up your modified glcd directory preserving the subdirectory structure
and email it to me at newmanrf@...

I will wire up a display to a LPC this weekend. See if you can document
your lcd wiring and I will wire mine up the same way.

Do you have a scope?
  If Yes-> Do you see activity on your data and clock lines.

One quick idea-> Add large delays between your writes to the display. This
controller is slow and you might be speaking to it too quickly especially
after you command it to reset/initialize. I really wish there was a busy
pin or way to query the display and ask if its ready but there is not so
this is something we just have to live with.

Let us know if the delays work and if not zip up your stuff and send it.

Richard Newman
Pittsburgh PA USA

> Question:  Why get rid of const?  I would have thought you would still
> want this
> in flash.
>

Robert,

    Yes your right. But for now it wont hurt him to remove it as if he is
building for flash its there and if he is building for ram its still
there. The idea is to get the code working first and removing that
gives him a better chance... as long as he does not run out of ram if
he is compiling to run out of ram. So for all of us that knows what it
does and why leave it. If it looks funky to you comment it out. You
will know that you need it eventually.

Richard Newman
Pittsburgh PA USA

At 03:54 PM 5/25/06 -0400, newmanrf@... wrote:

> > Question:  Why get rid of const?  I would have thought you would still
> > want this
> > in flash.
> >
>     Yes your right. But for now it wont hurt him to remove it as if he is
>building for flash its there and if he is building for ram its still
>there. The idea is to get the code working first and removing that
>gives him a better chance... as long as he does not run out of ram if
>he is compiling to run out of ram. So for all of us that knows what it
>does and why leave it. If it looks funky to you comment it out. You
>will know that you need it eventually.

Hmm, I would have left it in to gain the extra type checking. Always valuable.


Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Richard,

Can you explain why you think removing "const" gives the code 
a "better chance"? 

Regardless of whether the code is running from flash or RAM, if you 
leave out const in a declaration, you will be using up RAM, which if 
you have a lot of constant data is probably not a good idea. In 
general:

const int foo = 23; 

will be placed in a read-only section of memory (i.e. flash if built 
for flash), whereas:

int foo = 23;

will be placed in a read/write section (i.e. RAM) even if the code 
is built for flash. The initialiser value is also placed in a read-
only section and is copied in as part of the 'C' run-time 
initialisation.

You can override this behaviour by playing with compiler and/or 
linker options, but why bother when "const" does it for you?

Or am I misreading what you're suggesting?

Brendan

--- In lpc2000@yahoogroups.com, newmanrf@... wrote:
>
> 
> > Question:  Why get rid of const?  I would have thought you would 
still
> > want this
> > in flash.
> >
> 
> Robert,
> 
>     Yes your right. But for now it wont hurt him to remove it as 
if he is
> building for flash its there and if he is building for ram its 
still
> there. The idea is to get the code working first and removing that
> gives him a better chance... as long as he does not run out of ram 
if
> he is compiling to run out of ram. So for all of us that knows 
what it

> does and why leave it. If it looks funky to you comment it out. You
> will know that you need it eventually.
> 
> Richard Newman
> Pittsburgh PA USA
>