thanks Albert!

mp

On Tue, Apr 16, 2013 at 10:27 PM, al_bin wrote:
> **
> W dniu 2013-04-17 05:53:15 uytkownik Mike Pijl
> napisa:
>
> [...]
> when i replaced __main() with main(), the compiler complained about not
> being able to find __main().
> thank you for your tip about YAGARTO. and also your makefile. i don't know
> anything about crt.s; the example i had did not include that. i'm
> perplexed to hear there's something else i need but don't have or know
> anything about.
> Try Linaro. In my opinion is better.
> As you not include crt.s or standard runtimes main() is not called.
> Then compiler in optimalization proces remove it.
> But linker expected it
> [...]
> as for not using "ld" directly, i suppose you mean i should not pass "-c"
> to gcc?
> Pass it only for compile,
> >Hmm, is /gnude/arm-elf/lib valid WINDOWS path? ;-)
> using unix paths because i'm running it from CygWin.
> OK. I meant if this path is propely resolved to dos path.
> Albert
> __
> ._,

--- In l..., "rtstofer" wrote:

> "Hello World" is always a good place to start. A lot of code has to work properly for even this trivial example.
>
> I'll look around for a complete project and post back later.
>
> Richard
>

I have posted ARM21148CFProgrammer.zip to the files folder. It is a complete project including some string handling and conversion routines.

You can see the correspondence between my crt.s and your combined ivt.s and start.s.

I have some serious doubts about the various stack sizes. I copied crt.s from somewhere and it probably wasn't originally intended to support interrupts. OTOH, allocating 1000 bytes for the FIQ and IRQ stacks as is done in start.s isn't the right answer either. Nevertheless, the code worked fine.

The code reads a file from an SD/MMC card (FAT file system), reformats the sectors and writes an image to a Compact Flash device.

This project builds from the command line under Linux and from within Eclipse. For a long time, I used 'gedit' for the editor and the command line for building. I find it faster to use Eclipse because I now have a button that builds the code and another that programs the device.

I was using serial programming at the time. These days I would be using CrossWorks for the IDE and CrossConnect for JTAG programming. Both work very well.

Richard

--- In l..., Mike Pijl wrote:
>
> thank you all for your comments. i've tried things people have mentioned
> as well as studied the MAKE documentation to better understand that. still
> having similar results.

Makefiles can become a work or art. But not mine, they are pretty straight forward because my projects tend to be small.

I posted a Makefile to the files folder of this forum. Oddly, it is named 'Makefile'. I'll delete it in a couple of days.

This particular file is pretty hacked over. In particular, the auto dependency thing doesn't work on Windows because I don't have 'awk' and because I haven't bothered to make it work.

Down at the bottom, there should be a complete list of dependencies like:

main.o : main.c <some other file>.h, <etc>
<some other file>.o : <some other file>.c <some other file>.h

and so on. For your example, none of this is necessary because you have only main.o depending on main.c.

>
> rtstofer: i think i understand now. by using malloc, free, sprintf,
> strlen, etc, i'm obligating myself to create a heap manager. i'm not at
> all eager to do so. i presume if i define character arrays and generate a
> pointer to the character array, i no longer have this obligation.
>
> char c[100];
> char* pc=&c[0];
>
> i can wean myself off of sprintf, strlen, etc by using a stand-alone
> routine for this from one of the sources you suggest.
>
> it's like i have told people in the past about writing embedded
> software...it's like camping: bring what you need with you or be prepared
> to make it yourself (or not have it at all).

I prefer statically allocated memory. I want everything in its place and I want to check the .map file from time to time just to be certain.

>
> my little test application is only a test for compiling. my real
> application (originally built & debugged using keil) does indeed have an
> while (1) routine. regrettably, the program was too large for the free
> version of keil otherwise that's where it would still be. for my
> application, the keil compiler was entirely out of my price range.
>
> when i replaced __main() with main(), the compiler complained about not
> being able to find __main().

You also have __main in start.s

>
> thank you for your tip about YAGARTO. and also your makefile. i don't know
> anything about crt.s; the example i had did not include that. i'm
> perplexed to hear there's something else i need but don't have or know
> anything about.

Your two files (ivt.s and start.s) combine to make up crt.s. I don't know why NXT did it with two files. One thing I do know is that they didn't do anybody any favors with the brevity of their code.

If I can find a more suitable example on my Linux box, I'll post an entire project using nested interrupts and a more expansive startup file. I can probably find something with multiple source files and a complete dependency list in the makefile.

I'll post back later about that.

>
> as for not using "ld" directly, i suppose you mean i should not pass "-c"
> to gcc?

People have various ways of dealing with compile and link. I do call ld directly when I build the .elf target. But I don't want the .elf file, my final target is a .hex file which depends on the .elf target. You can see the progression where the 'all' target makes the .hex file plus a display of the object size and list. The .hex target depends on the .elf target and simply changes the file format from .elf to .hex. The .elf target depends on the linker script and all of the .o files and links together all of the .o files plus the LIBRARIES. And so on...

> 1. migrate from malloc/free to arrays with pointers as described
> 2. port in a couple of replacements for strlen, sprintf
> 3. try again with most of the rest as it was
>
> part of the reason i'm not being more ambitious is because by now, i'm not
> as "offended" by things that are not satisfying my usual requirements.
> today, my only requirement is that it compiles and actually works...after
> all, it's a project only for me...
>

"Hello World" is always a good place to start. A lot of code has to work properly for even this trivial example.

I'll look around for a complete project and post back later.

Richard

Quote "for my application, the keil compiler was entirely out of my price range."

There are lots of other professional quality tools out there, that are much cheaper than Keil (Crossworks, Code Red) and a lot of free tools too (LPCXpresso, Yagarto).

So how much have you spent on trying to 'roll your own'? I bet you could have better spent your time investigating the market for cheaper tools than Keil...

Hi there,

Take a look at this article
http://www.embedded.com/design/mcus-processors-and-socs/4007119/Building-Bare-Metal-ARM-Systems-with-GNU-Part-1--Getting-Started,
it helped me a lot when I was starting, maybe you'll find it usefull.
As for the heap management you'll find a lot of samples not too hard to
understand, it is no more than a half a dozen functions with little code.

Regards,
Bernardo Marques.

There is a learning curve to using GNU tools, especially when you're doing
cross compiles.

Most people, such as yourself, start out using an IDE and miss out on the
underpinnings.

By convention, crt.s is an assembly language program that runs out of reset.

Here is where you set up the various stack pointers, zero out the .bss
section, initialize the data section, etc.

Toward the end, you call a function to initialize the processor -- set up
the oscillator and/or the PLL to run at the desired frequency. Initial
I/O must also be set up.

Now you're ready to jump to main. You don't really need a main if you
write your own crt.s. I've forgotten at the moment how to tell the linker
that there is no main -- maybe it's the nofiles option.

Makefiles suck! I finally got so sick of them I took a couple of weeks to
write a python program to handle builds. Once you know the options to
pass to gcc it's easy enough to walk lib dirs, determine dependencies and
compile as necessary.

I've always regarded compiler supplied libs as untrusted. In fact, there
is at least one function that assumes memory is writable. It's better to
write you're own.

DaveS

[...]
when i replaced __main() with main(), the compiler complained about not
being able to find __main().
thank you for your tip about YAGARTO. and also your makefile. i don't know
anything about crt.s; the example i had did not include that. i'm
perplexed to hear there's something else i need but don't have or know
anything about.
Try Linaro. In my opinion is better.
As you not include crt.s or standard runtimes main() is not called.
Then compiler in optimalization proces remove it.
But linker expected it
[...]
as for not using "ld" directly, i suppose you mean i should not pass "-c"
to gcc?
Pass it only for compile,
>Hmm, is /gnude/arm-elf/lib valid WINDOWS path? ;-)
using unix paths because i'm running it from CygWin.
OK. I meant if this path is propely resolved to dos path.
Albert
__
._,

thank you all for your comments. i've tried things people have mentioned
as well as studied the MAKE documentation to better understand that. still
having similar results.

i've become so accustomed to knowing how to do things in the world of
creating software that this has been a rude awakening...

rtstofer: i think i understand now. by using malloc, free, sprintf,
strlen, etc, i'm obligating myself to create a heap manager. i'm not at
all eager to do so. i presume if i define character arrays and generate a
pointer to the character array, i no longer have this obligation.

char c[100];
char* pc=&c[0];

i can wean myself off of sprintf, strlen, etc by using a stand-alone
routine for this from one of the sources you suggest.

it's like i have told people in the past about writing embedded
software...it's like camping: bring what you need with you or be prepared
to make it yourself (or not have it at all).

my little test application is only a test for compiling. my real
application (originally built & debugged using keil) does indeed have an
while (1) routine. regrettably, the program was too large for the free
version of keil otherwise that's where it would still be. for my
application, the keil compiler was entirely out of my price range.

when i replaced __main() with main(), the compiler complained about not
being able to find __main().

thank you for your tip about YAGARTO. and also your makefile. i don't know
anything about crt.s; the example i had did not include that. i'm
perplexed to hear there's something else i need but don't have or know
anything about.

as for not using "ld" directly, i suppose you mean i should not pass "-c"
to gcc?

>Hmm, is /gnude/arm-elf/lib valid WINDOWS path? ;-)

using unix paths because i'm running it from CygWin.

my plan is to (unless you disapprove):

1. migrate from malloc/free to arrays with pointers as described
2. port in a couple of replacements for strlen, sprintf
3. try again with most of the rest as it was

part of the reason i'm not being more ambitious is because by now, i'm not
as "offended" by things that are not satisfying my usual requirements.
today, my only requirement is that it compiles and actually works...after
all, it's a project only for me...

i'll come back to it in an evening (maybe tomorrow; maybe the next evening)
and see what i can do.

thank you all!
mp

An Engineer's Guide to the LPC2100 Series