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 l..., 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
>

An Engineer's Guide to the LPC2100 Series

At 03:54 PM 5/25/06 -0400, n...@originarea.com 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/

> 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

I'm assuming you did not change much if anything in Michael Karas's main
thats included with the gLCD files off of 8052.com. So being thats 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 n...@embedworx.com

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

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 l..., 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
>

Quoting n...@originarea.com:
> 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 dont pay attention to whats
> in code and whats 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

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 dont pay attention to whats
in code and whats 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

--- In l..., "wickedmonster2002" 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 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 l..., 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
>

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 l..., 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
> >SPONSORED LINKS
>Microcontrollers
>Microprocessor
>Intel
>microprocessors
>----------
>>Yahoo! Terms of Service.
>----------