--- 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
GCC/gnude can't use libc.a?
Started by ●April 16, 2013
Reply by ●April 17, 20132013-04-17
Reply by ●April 17, 20132013-04-17
--- 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
> "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
Reply by ●April 21, 20132013-04-21
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
> __
> ._,
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
> __
> ._,
Reply by ●April 22, 20132013-04-22