Re: Startup code

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.

Paul Burke
.

Quantcast