This
is a great tutorial for someone who is starting to play with ARM uC and it
saved me a lot of time. It was written for an ST chip but I remember that I
needed to change only two or three register names on the start code to port
the whole code to the LPC.
Read it all, from 'Part 1' to 'Part 10', it won't take
long, and in the end
you'll know how to place functions in RAM.
Regards,
Bernardo Marques.
On Mon, Mar 14, 2011 at 2:32 PM, Thales Godoy wrote:
> Hello,
> That tutorial seens like another one that I have, but have some things on
> this tutorial that can't understand very well, like that declarations
and
> .data on startup code. Could explain me, in detail each part of startup
> code...
>
> you ask me why do I want to run code from ram...
> I'll try to explain what I trying to do, I'm writing a code for a
"grafic
> card" with arm controller, so I need to transfer a lot of data, that will
be
> made by a loop. I guess if I run this part of code from ram the program
will
> run faster than if it was running from flash.
> So that tutorial that you send me is intereting, but I guess that it wont
> help me to run just a function from the ram and the rest of code from
> flash....
>
> Thanks
>
> Thales....
>
> ------------------------------
> *De:* rtstofer
> *Para:* l...
> *Enviadas:* Sexta-feira, 11 de Mar de 2011 15:47:15
> *Assunto:* [lpc2000] Re: Load and run code on arm's sram
>
> --- In l..., "Thales" wrote:
> >
> > Hello,
> >
> > I'm new in this group and a I need some help.
> >
> > I'm starting to learning Arm mcu lpc2000 family, i wanna know if can
> anyone explan me how to load and run code in arm's sram
> >
> > Thanks
> > Here is a tutorial that covers getting a program to run in ram. However,
it
> also loads the program to ram, not flash. It is not specifically for the
LPC
> devices although somewhere on the net James Lynch has a tutorial
> specifically for the LPC2106 and LPC2148. It's harder to find.
>
> http://www.sparkfun.com/tutorials/66
>
> You would still need to change the linker script to address the sections to
> ram (already done in the *_ram scripts) but put them in flash. This is a
lot
> like the .data segment for programs that run out of flash. There is a
linker
> script for this as well. You can see how the .data segment is in ram but
> loaded to flash. Then you would need to change the startup code to copy the
> sections from flash to ram and then branch to the ram code. This is shown
in
> the flash linker script where the .data segment (initialized ram) is copied
> from flash to ram.
>
> But why would you want to do all this? Running out of ram isn't much
> faster, if at all, and that's because the flash fetches are much wider
so
> fewer are required. Further, most devices have a LOT of flash and not
nearly
> as much ram. 64k bytes of ram seems like a lot until you realize that it is
> only 16k instructions and the compilers generate a LOT of code.
>
> You really don't want to do this...
>
> Richard
>
>
Reply by "the...@rocketmail.com"●March 15, 20112011-03-15
--- In l..., Venkateswaran R wrote: >
> can any guide me which to know abt lpc xpresso
> Have you looked at the various LPCXpresso websites?
Start with http://ics.nxp.com/lpcxpresso/
Reply by "the...@rocketmail.com"●March 15, 20112011-03-15
Have you looked at the more recent LPC1xxx families from NXP? The LPC13/17/18
use ARMs Cortex-M3 and run at full speed directly from Flash (up to 150MHz).
They are also Harvard architecture, which means the code and data buses are
seperate, further reducing the number of wait states. From what I see, NXP
aren't investing in the LPC2xxx family any more and are putting all their
efforts into the new Cortex-M parts.
--- In l..., Thales Godoy wrote: >
> Hello,
> I'm just starting to learn ARM controller and LPC family, and I read in
some
> manual that the flash's access time LPC controllers is 200ns, so we need
of MAM
> to run the LPC controller at full speed( I don't know if it still working
like
> this, because my reference is outdated), so if it's true, when the
> program branchs the fist instruction after it will take 200ns to be fetched.
how
> it don't happend on ram, run into ram is faster then flash...
>
>
> ________________________________
> De: Wouter van Ooijen
> Para: l...
> Enviadas: Segunda-feira, 14 de Março de 2011 16:30:57
> Assunto: Re: Res: Res: [lpc2000] Re: Load and run code on arm's sram
>
>
> > You're making the ASSUMPTION that code will run faster out of RAM. I
> > believe this has been discredited over the last few years but I'm
not
> > certain. The flash is WIDE - multiple instructions are fetched as a
> > single access. NXP states that flash access can keep up with the core at
> > maximum clock rates - at least on the chips I am using (LPC2106 and
> > LPC2148). There is always the issue of executing just one instruction of
> > the several that were fetched and then having a branch. But that's
the
> > same problem in SRAM. If you have to flush the pipeline, you have to
> > flush the pipeline.
>
> On the LPC2106/2148 code will always run full-speed from RAM, but not
> always so from flash (depending on waits, MAM setting, and - for some
> MAM settings - how well the accelerator works).
>
> --
>
> Wouter van Ooijen
>
> -- -------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: www.voti.nl/hvu
>
Reply by Thales Godoy●March 14, 20112011-03-14
Ok, I know that I'm telling insane things, but I'm just telling what I
read. I'm
trying to understand to try to write my first code....
Anyway...
Thank you all to try to help me. and any doubt I'll ask again.
________________________________
De: Wouter van Ooijen
Para: l...
Enviadas: Segunda-feira, 14 de Março de 2011 17:58:23
Assunto: Re: Res: Res: Res: Res: [lpc2000] Re: Load and run code on arm's
sram
> If the flash isn't fast enough, get a faster
chip! The Analog Devices
> Blackfin comes to mind. It runs at 500 MHz.
If your engineer does not do a reasonable job of getting the maximum
performance from the chip get a better engineer....
--
Wouter van Ooijen
-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
Reply by rtstofer●March 14, 20112011-03-14
--- In l..., Wouter van Ooijen wrote: >
> > If the flash isn't fast enough, get a faster chip! The Analog
Devices
> > Blackfin comes to mind. It runs at 500 MHz.
>
> If your engineer does not do a reasonable job of getting the maximum
> performance from the chip get a better engineer....
>
> --
>
> Wouter van Ooijen
>
> -- -------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: www.voti.nl/hvu
> How true! Until it isn't...
Suppose an engineer costs $150k/yr ($75/hr), the incremental cost for a faster
chip is $2 and you figure to build 100 units. The engineer can't even
spend a day trying to figure it out before there's no benefit. Buy the
bigger/faster chip and move on!
Unfortunately, Purchasing seldom sees it that way. And, of course, in higher
volume, more engineering makes sense.
Richard
Reply by Wouter van Ooijen●March 14, 20112011-03-14
> If the flash isn't fast enough, get a faster
chip! The Analog Devices
> Blackfin comes to mind. It runs at 500 MHz.
If your engineer does not do a reasonable job of getting the maximum
performance from the chip get a better engineer....
--
Wouter van Ooijen
-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
Reply by rtstofer●March 14, 20112011-03-14
--- In l..., Thales Godoy wrote: >
> I make a mistake, I said that the flash's access time is 200ns but
it's 50ns.
From the LPC2148 datasheet:
[QUOTE]
The particular flash implementation in the LPC2141/42/44/46/48 allows for full
speed execution also in ARM mode. It is recommended to program performance
critical and short code sections (such as interrupt service routines and DSP
algorithms) in ARM mode. The impact on the overall code size will be minimal but
the speed can be increased by 30% over Thumb mode.
[ENDQUOTE]
I don't see a similar statement for the LPC2106 and I haven't reviewed
the specs for any other chips.
If the flash isn't fast enough, get a faster chip! The Analog Devices
Blackfin comes to mind. It runs at 500 MHz.
Richard
Reply by Thales Godoy●March 14, 20112011-03-14
I make a mistake, I said that the flash's access time is 200ns but
it's 50ns.
________________________________
De: Thales Godoy
Para: l...
Enviadas: Segunda-feira, 14 de Março de 2011 17:10:01
Assunto: Res: Res: Res: [lpc2000] Re: Load and run code on arm's sram
Hello,
I'm just starting to learn ARM controller and LPC family, and I read in
some
manual that the flash's access time LPC controllers is 200ns, so we need of
MAM
to run the LPC controller at full speed( I don't know if it still working
like
this, because my reference is outdated), so if it's true, when the
program branchs the fist instruction after it will take 200ns to be fetched. how
it don't happend on ram, run into ram is faster then flash...
________________________________
De: Wouter van Ooijen
Para: l...
Enviadas: Segunda-feira, 14 de Março de 2011 16:30:57
Assunto: Re: Res: Res: [lpc2000] Re: Load and run code on arm's sram
> You're making the ASSUMPTION that code will run
faster out of RAM. I
> believe this has been discredited over the last few years but I'm not
> certain. The flash is WIDE - multiple instructions are fetched as a
> single access. NXP states that flash access can keep up with the core at
> maximum clock rates - at least on the chips I am using (LPC2106 and
> LPC2148). There is always the issue of executing just one instruction of
> the several that were fetched and then having a branch. But that's the
> same problem in SRAM. If you have to flush the pipeline, you have to
> flush the pipeline.
On the LPC2106/2148 code will always run full-speed from RAM, but not
always so from flash (depending on waits, MAM setting, and - for some
MAM settings - how well the accelerator works).
--
Wouter van Ooijen
-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
Reply by Thales Godoy●March 14, 20112011-03-14
Hello,
I'm just starting to learn ARM controller and LPC family, and I read in
some
manual that the flash's access time LPC controllers is 200ns, so we need of
MAM
to run the LPC controller at full speed( I don't know if it still working
like
this, because my reference is outdated), so if it's true, when the
program branchs the fist instruction after it will take 200ns to be fetched. how
it don't happend on ram, run into ram is faster then flash...
________________________________
De: Wouter van Ooijen
Para: l...
Enviadas: Segunda-feira, 14 de Março de 2011 16:30:57
Assunto: Re: Res: Res: [lpc2000] Re: Load and run code on arm's sram
> You're making the ASSUMPTION that code will run
faster out of RAM. I
> believe this has been discredited over the last few years but I'm not
> certain. The flash is WIDE - multiple instructions are fetched as a
> single access. NXP states that flash access can keep up with the core at
> maximum clock rates - at least on the chips I am using (LPC2106 and
> LPC2148). There is always the issue of executing just one instruction of
> the several that were fetched and then having a branch. But that's the
> same problem in SRAM. If you have to flush the pipeline, you have to
> flush the pipeline.
On the LPC2106/2148 code will always run full-speed from RAM, but not
always so from flash (depending on waits, MAM setting, and - for some
MAM settings - how well the accelerator works).
--
Wouter van Ooijen
-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
Reply by Wouter van Ooijen●March 14, 20112011-03-14
> You're making the ASSUMPTION that code will run
faster out of RAM. I
> believe this has been discredited over the last few years but I'm not
> certain. The flash is WIDE - multiple instructions are fetched as a
> single access. NXP states that flash access can keep up with the core at
> maximum clock rates - at least on the chips I am using (LPC2106 and
> LPC2148). There is always the issue of executing just one instruction of
> the several that were fetched and then having a branch. But that's the
> same problem in SRAM. If you have to flush the pipeline, you have to
> flush the pipeline.
On the LPC2106/2148 code will always run full-speed from RAM, but not
always so from flash (depending on waits, MAM setting, and - for some
MAM settings - how well the accelerator works).
--
Wouter van Ooijen
-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
