Re: Startup code



Paul Burke wrote:
> Meindert Sprang wrote:
>
> >
> > Again, all startup codes I have seen so far, were written in assembler.
> > Probably because at startup time, there is no environment set up yet to run
> > compiled C code at all. But this only holds true with "my" definition of
> > startup code, where the call to main() is not executed yet.
>
> I'm working on an example of how NOT to do startup code- the Zilog eZ80
> ZDSII development system. It gets worse- more prescriptive- with each
> release of the system, so much so that the latest version won't work at
> all with most of their example code.
>
> It's all done in an attempt to make a system, PIC style, where you use
> vendor- supplied and compile-time configured code fragments rather than
> having to read the data *** and modify (or even write) configuration
> files for yourself. All very laudable- except that to swap the default
> printf console from UART0 to UART1 you have to RECOMPILE THE BLOODY
> LIBRARY in the latest version. OK that's not startup, but you get the
> point about unhelpful nannying.
>
> No, in embedded systems, startup code should be restricted to setting up
> stack pointers etc., initialising or clearing variables, setting up the
> bones of the interrupt system where this needs to be done in RAM, and
> executing main(). Anything else should be explicit, in C, easily
> accessible to the code writer, well documented, and obvious where it is.

Startup code can also copy the program from flash to ram and
jump to an address in ram.

If you use an rtos you need to initialize the rtos structures
before the main task is started.

.

Quantcast