Could you send the arm_ucos_1.14.zip to me? ( I could not download from
there).
I am using LPC2210. I
Thanks.
Michael Anburaj <> wrote:
Chris,
Try the uCOS-II port & example codes for LPC... It has
startup & basic infrastructure code (which build with
GCC or ARM tools (SDT or ADS)) & supports ARM,
ARM-THUMB & THUMB mode images.
>
> > The UT040803A.zip in the File section has a
> wonderful example for
> > startup with GCC.
>
> FINALLY! Thank you very much. This is exactly what
> I was looking
> for. Even has a decent makefile. I wish you guys
> would rename this
> something obvious like "Full Featured GNU ARM
> Example". That would
> have saved me a lot of searching, downloading, and
> hunting work.
>
> Thanks, Chris.
>
>
__________________________________
---------------------------------
Yahoo! Groups Links
Reply by Michael Anburaj●December 29, 20042004-12-29
Chris,
Try the uCOS-II port & example codes for LPC... It has
startup & basic infrastructure code (which build with
GCC or ARM tools (SDT or ADS)) & supports ARM,
ARM-THUMB & THUMB mode images.
>
> > The UT040803A.zip in the File section has a
> wonderful example for
> > startup with GCC.
>
> FINALLY! Thank you very much. This is exactly what
> I was looking
> for. Even has a decent makefile. I wish you guys
> would rename this
> something obvious like "Full Featured GNU ARM
> Example". That would
> have saved me a lot of searching, downloading, and
> hunting work.
>
> Thanks, Chris.
>
>
__________________________________
Reply by sig5534●December 28, 20042004-12-28
> The UT040803A.zip in the File section has a
wonderful example for
> startup with GCC.
FINALLY! Thank you very much. This is exactly what I was looking
for. Even has a decent makefile. I wish you guys would rename this
something obvious like "Full Featured GNU ARM Example". That would
have saved me a lot of searching, downloading, and hunting work.
Thanks, Chris.
Reply by ggindele●December 28, 20042004-12-28
The UT040803A.zip in the File section has a wonderful example for
startup with GCC.
--- In , "sig5534" <sig5534@h...> wrote: >
> Karl, much thanks for your detailed info.
>
> > Your startup code should also have code to copy the initialization
> > values for .data from flash to RAM.
>
> Ok, how do I do that for GCC? Got any examples? Can you point me
> towards the doc?
>
> > If you write all the code of your program yourself, you may of
> course
> > skip the startup initialization so that all globals/statics are
> > indeterminate at startup. But if you link in other code, such as
> > standard C library functions, you better be absolutely sure that
> the
> > indetermination of their statics/globals won't break anything.
>
> Does GCC spit out its own C init code? If so where is the doc on
> this or the examples so I can see how to link this in?
>
> > If you are concerned with the speed of the startup initialization,
>
> No I'm not. I just want something that works! All of the examples I
> find involve somebody else's syntax like IAR or ARM which will not
> work for GCC. I'm trying to figure out what I need for GCC to work!
>
> There is so much doc to wade through for this GNU stuff, and so few
> examples, this is a slow painful learning curve. Some decent
> examples would be a big help. I expected that there would be some
> with the GNUARM files, but I sure cannot find many.
>
> More info from an expert like yourself would be greatly appreciated!
>
> Thanks, Chris.
Reply by sig5534●December 28, 20042004-12-28
Karl, much thanks for your detailed info.
> Your startup code should also have code to copy
the initialization
> values for .data from flash to RAM.
Ok, how do I do that for GCC? Got any examples? Can you point me
towards the doc?
> If you write all the code of your program
yourself, you may of course > skip the startup initialization so that all
globals/statics are
> indeterminate at startup. But if you link in other code, such as
> standard C library functions, you better be absolutely sure that the > indetermination of their statics/globals
won't break anything.
Does GCC spit out its own C init code? If so where is the doc on
this or the examples so I can see how to link this in?
> If you are concerned with the speed of the startup
initialization,
No I'm not. I just want something that works! All of the examples I
find involve somebody else's syntax like IAR or ARM which will not
work for GCC. I'm trying to figure out what I need for GCC to work!
There is so much doc to wade through for this GNU stuff, and so few
examples, this is a slow painful learning curve. Some decent
examples would be a big help. I expected that there would be some
with the GNUARM files, but I sure cannot find many.
More info from an expert like yourself would be greatly appreciated!
Thanks, Chris.
Reply by Robert Adsett●December 28, 20042004-12-28
At 10:26 PM 12/28/04 +1100, you wrote: > > What is this last statement doing, and what
would be the correct
> > equiv to use in GNU?
>
>I'm doing a few quick tests on EWARM kickstart to see how the
code/s[eed
>generation
>really compares to GCC.
>When I'm done shortly I'll have a look, I had changed the startup
code anyway.
>
>But I'd say off-the-cuff that SFE is an intrinsic (macro) to do
something
>with the lookup address of SVC_STACK.
>Have a look around in your IAR docs under "intrinsics" or
somesuch.
I suspect Kris is right, but I don't know the IAR syntax either. There are
startup examples in the files section. Also the newlib-lpc has startup and
ld examples ( http://www.aeolusdevelopment.com/ Just follow the download
link).
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
Reply by Karl Olsen●December 28, 20042004-12-28
--- In , "sig5534" <sig5534@h...> wrote:
> I assume that "r13" is the same as
"sp" ?
Yes.
> They also have some RAM init code after stack
setups. I guess they
> are zeroing memory. Do I need to zero RAM? Does it really matter to > anything?
It zeroes the .bss section and copies initialization values for
the .data section. GCC assumes that the startup code does this for
code like this:
int a;
int *pa;
which must be zero initialized according to the C standard. GCC also
places explicitly zero initialized variables in .bss:
int b = 0;
int *pb = NULL;
Variables explicitly initialized to other than zero are placed
in .data:
int c = 1234;
int *pc = &c;
Your startup code should also have code to copy the initialization
values for .data from flash to RAM.
If you write all the code of your program yourself, you may of course
skip the startup initialization so that all globals/statics are
indeterminate at startup. But if you link in other code, such as
standard C library functions, you better be absolutely sure that the
indetermination of their statics/globals won't break anything.
If you are concerned with the speed of the startup initialization,
you can speed it up by using LDM/STM to load/store e.g. 8 words at a
time instead of the normal LDR/STR loop which only does 1 word at a
time. In the .ld file, you should then make the start and end of the
sections 32-byte aligned instead of just 4-byte aligned.
If you have large arrays that you don't need or have time to zero
initialize at startup, you can invent a special section name and put
the variables into that section:
and process the section appropriately in the .ld file. In any case,
prepare for a deep dive into the .ld file syntax...
And before deciding all this, first examine the linker map file to
see the actual size of the sections.
Karl Olsen
Reply by sig5534●December 28, 20042004-12-28
Thanks, I figured as much. I found a couple of examples to download
from ARM and they did it like this:
/* Setup the IRQ stack */
mov r0,#IRQ_MODE | I_Bit | F_Bit /* IRQ_MODE, No Ints */
msr cpsr_c,r0 /* Change the mode */
ldr r13,=IRQ_STACK /* End of IRQ_STACK */
I assume that "r13" is the same as "sp" ?
They also have some RAM init code after stack setups. I guess they
are zeroing memory. Do I need to zero RAM? Does it really matter to
anything?
Regarding IAR, I started out with that system and also MakeApp.
After running into several bugs I am giving up and trying the GNU
world. It would spit out bad ELF files at times that my JTAG
debugger could not load. I ran into another bug where the compiler
went into the weeds on a simple loop and then dropped every function
call thereafter. Bugs in MakeApp too.
They have a few nice extensions, such as the record structure into
the bits of the regs. But all the bells, whistles, and optimizations
in the world matter little when it keeps throwing bugs. I could not
trust it anymore.
Chris.
Reply by microbit●December 28, 20042004-12-28
Hi,
> In IAR they gave an example like this:
>
> mrs r0,cpsr /* Original PSR value */
> bic r0,r0,#MODE_BITS /* Clear the mode bits */
> orr r0,r0,#SVC_MODE /* Set SVC mode bits */
> msr cpsr_c,r0 /* Change the mode */
> ldr sp,=SFE(SVC_STACK) & 0xFFFFFFF8 /* End of SVC_STACK */
> What is this last statement doing, and what would
be the correct
> equiv to use in GNU?
Can't seem to find a reference to it, but I seem to recall that standard
IAR syntax
is that SFE is something like :
Segment (Flash ?) End.
So, bascially ldr sp, =SFE(SVC_STACK) & ....
loads the SP with the ABSOLUTE address of the END of SEGMENT SVC_STACK,
which is in RAM of course.
This would make sense, as you'd normally use a descending stack.
The & with 0xFFFFFFF8 is to align the stack address to an 8-byte
boundary. GNU has its own defines for that like .code x etc.
Else just ldr sp with the Start address of your (SVC Stack + The SVC Stack
size).
(You'd want it to sit on top of RAM)
-- Kris
Reply by microbit●December 28, 20042004-12-28
Hi Chris,
> Perhaps I am asking a real simple question, but
for the life of me I
> cannot find much information or example code on stack setup. I'm
> trying to move my IAR code over to GNU, and of course the GNU syntax
> does not handle all of the ARM Asm coding.
>
> In IAR they gave an example like this:
>
> mrs r0,cpsr /* Original PSR value */
> bic r0,r0,#MODE_BITS /* Clear the mode bits */
> orr r0,r0,#SVC_MODE /* Set SVC mode bits */
> msr cpsr_c,r0 /* Change the mode */
> ldr sp,=SFE(SVC_STACK) & 0xFFFFFFF8 /* End of SVC_STACK */
>
> The GNU compiler will take all of this - except for that last
> statement. I have no idea what that "SFE" command is doing and
> neither does GNU apparently. I can't even find anything on this in
> the ARM7 Instruction set manual.
>
> What is this last statement doing, and what would be the correct
> equiv to use in GNU?
I'm doing a few quick tests on EWARM kickstart to see how the code/s[eed
generation
really compares to GCC.
When I'm done shortly I'll have a look, I had changed the startup code
anyway.
But I'd say off-the-cuff that SFE is an intrinsic (macro) to do
something
with the lookup address of SVC_STACK.
Have a look around in your IAR docs under "intrinsics" or somesuch.
When I'm done with the tests, I'll have a look if you haven't
figured it in the meantime.
