Regarding startup file

can i write my own start up codes

Yes and no. Yes because the tools do indeed allow it, and no because if you had to ask, that pretty much proves you don't have what it takes to do it.

and librarys?

Yes. But it might still be rather spectacularly unwise to actually do so, depending on which libraries you're talking about.

Here's the one for the 8051.

http://www.keil.com/support/man/docs/c251/c251_ap_startup.htm

Close, but no cigar. ;-)

the simple answer is yes because of the need to set up stack, heap, vars etc.

That answer is simple --- but wrong. No, it is not (always) necessary to include it. Because some of the various tools in question (note that the OP didn't specify an architecture) can make do without one, and others supply their own if the user didn't include one.

But I didn't guess.

The question itself is also meaningless because it isn't accompanied with a proper definition of what a startup file really is.

If it is the file that contains the first instructions the processor should run, then it obviously has to be there - if not, then the processor would either have zero instructions or would have instructions only at a place it doesn't know how to reach.

If a "startup file" is considered an assembler file that sets up the environment, then the answer is no. A Cortex-M3 can manage with C functions for interrupt handlers, and for initialize the processor. The processor itself sets up an initial stack. So the same source file that contains main() can contain a C function that initializes RAM, sets up a heap, configures the oscillators, etc. The only special about this function is that it is called before main(), and the hardware state does not fulfill the requirements of the C standard regarding global variables or access to runtime library.

In the end, the question can only be answered if the question is expanded to actually tell what is specifically intended with the question.

You want to block all C questions and only allow questions relative to Keil/ARM issues. But while a startup file is outside the scope on a PC, because anything before main() is basically irrelevant, it is not so for embedded prorams.

Keil can't know what requirements the hardware has.
And on the other hand, Keil supports Cortex chips.

So in the end, it is very relevant to know what is the normal requirements from a startup file - the user is likely to have to modify a startup file supplied by Keil.

And on the other hand, you can have C-only startup code.

To Per:

"Some processors (like 8051 and ARM chips) don't contain any logic to locate any main() function on startup."

Could you give an example of a processor containing some kind of logic designed to locate the main() at startup?

Regards,
Nikolay.

A processor can't locate main for the simple reason that the name "main" is stripped away when the binary is created.

Different processors have different rules for what they do on startup, but they normally jump to a fixed address (possibly controlled by external means - sampling processor pins while booting) or loading a jump vector from a fixed address and then jumping to this loaded address.

Some processors can do a bit more before they jump to a startup function - for example prepare an initial stack. Some processors have fixed RAM so they just give the stack pointer a suitable hard-coded value on reset. This is very common for all-in-one microcontrollers. Some processors can look at a specific address in memory to find what value to use for initial stack. Look for example at the boot sequence of a Cortex-M3 chip.

If the compiler/linker just makes sure that main() is placed at a specific address, or creates a vector pointing to main(), then just about any processor can manage to jump to main on reset. It would normally be a jump - not a call - so it would not go well if main() tries to return. But then again - main() is normally expected to contain an infinite loop for embedded projects.

What is important here is that no processor will be able to enter main() directly, and deliver a fully initialized "C program" environment. Somewhere far off in dusty memory I have seen some processor clearing RAM on boot. But that is extremely unusual since it either requires the processor to have loop mechanism to loop through all memory cells - this increases the time until the developer gets a chance to run his first instructions. The other alternative is that the cihp have special RAM with a reset feature connected to the individual memory cells which costs money and chip size.

With or without zeroed memory, the processor itself can not know what global variables that are supposed to have non-zero initial values. Or what function calls the CRTL is expecting to be made before you enter main().

In the end, the majority of processors requires initial assembler code to setup the processor enough that it is even meaningful to reach a main(). But some processors understands enough of the calling models of C etc, that you can have 100% C code.

So in the end, there are lots of alternatives possible.

Having a specific startup file that you need to link with the project. This is the most common, since embedded developers likes full control and want/need to play around with lots of specifics before the "normal" code starts.

Have the tools auto-generate the startup instructions. This is less common because it is a quite strict integration between compiler and processor. So it is normally only done for more minimalistic processors where there aren't so much interesting things to play with in the processor.

Have the processor directly enter a specific C function (that could be named main() or something else) that sets up everything. Very nice, given how more and more developers don't understand assembler programming, but the majority of processors haven't an enough friendly startup logic.

Another thing here is that more and more processors starts to have a primary boot loader, so the initial instructions run aren't our program code or our/compiler vendors startup code. Processors with an initial boot loader can have any number of extra featues affecting the startup of a program. They may look at hw ports for loading potentially encrypted firmware binaries from USB, memory cards, ... They can support multi-boot where it selects one of multiple binaries to boot based on previous performance - allowing redundant programs. With such boot loaders, there can be lots of tabulated data that the boot loader may look at when selecting/starting the program or potentially also vectoring interrupts. But I have never seen such a boot loader that takes named text strings as tokens, so the processor/boot loader would still not know about a specific main() in the end-user program. It would still assume that compiler+linker places the first code at a fixed location or points a vector to teh first code to run. If that code is named main() or not is irrelevant.

Per, again you just waffle on. The newbie is writing in 'C' so the case on whether it is required for assembly programs is not relevant to the question. If you look at my previous posts you will see that I also stated the same as you in that it could be incorporated into main(). All this newbie wants is to get their simple program up and running and wants to know if the startup file is required. He doesn't need a lecture on the pros/cons and the various ways to avoid using one. Just help the guy and tell him "yes" and he can learn about the rest as and when he gets more experience. One day he may be as clever as you think you are!

Can I assume that you have just been assigned as official moderator?

Have you asked the OP if he wants black magic?

And by the way - why unprovoked ad hominem?

girls, girls. please behave with a degree of decorum.

o.k. Thanks to all. mostly understood. rest i will manage.