--- 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 Start a New Thread

--- 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 Start a New Thread

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
> __
> ._, Start a New Thread

got it all working perfectly yesterday. i went to "bare metal" so i had to
write some routines myself but that wasn't as much of a nuisance as i
expected.

thank you all for your help!

mp Start a New Thread