We describe here the steps performed by eCos upon start-up, mentioning how a programmer can introduce custom start-up routines.
The HAL (Hardware Abstraction Layer, see The eCos Hardware Abstraction Layer (HAL) ) is the eCos package which contains all start-up code. Its start-up procedure is outlined in detail in HAL startup , but the main steps can be summarized here:
cyg_start()
, which has the following prototype:
void cyg_start
( void )
cyg_start()
is the core of the
start-up mechanism. The default definition is in
infra/current/src/startup.cxx
cyg_prestart()
cyg_package_start()
cyg_user_start()
and then starts the eCos scheduler if the system has been configured to have a kernel and scheduler.
You can override the default
cyg_start()
routine by providing your own function by the same name with the following prototype:
void cyg_start
( void )
Overriding
cyg_start()
should rarely, if ever, be done. The functions
cyg_prestart()
and
cyg_user_start()
described just below allow enough flexibility for installing user initialization code safely for almost all applications.
If you are supplying your own definition of this function from a C++ file, make sure it has "C" linkage.
The default
cyg_prestart()
function does not do anything; it is meant to be overwritten if the programmer needs to do any initialization
before
other system level initialization.
You can override the default
cyg_prestart()
routine by providing your own function by the same name with the following prototype:
void cyg_prestart
( void )
If you are supplying your own definition of this function from a C++ file, make sure it has "C" linkage.
The
cyg_package_start()
allows individual packages to do their initialization before the main user program is invoked.
Two of the packages shipped with this release of
eCos
have code in the default
cyg_package_start()
: the
µ
ITRON and the ISO standard C library compatibility packages (see
µITRON API
and
C and math library overview
).
The infrastructure package has configuration options CYGSEM_START_UITRON_COMPATIBILITY and CYGSEM_START_ISO_C_COMPATIBILITY which control specialized initialization.
You can override the default
cyg_package_start()
routine by providing your own function by the same name with the following prototype:
void cyg_package_start
( void )
but you should be careful to initialize the default packages (if you are using them). An example user-supplied function might look like:
void cyg_package_start(void) { #ifdef CYGSEM_START_UITRON_COMPATABILITY cyg_uitron_start(); /* keep the m ITRON initialization */ #endif my_package_start(); /* make sure I initialize my package */ }
If you are supplying your own definition of this function from a C++ file, make sure it has "C" linkage.
This is the normal entry point for your code. Although a default empty version is provided by eCos, this is a good place to set up your threads (see Thread operations ).
If you are not including the ISO standard C library package then there will not be a
main()
function, so it becomes mandatory to provide this function (see
C library startup
).
To set up your own
cyg_user_start()
function, create a function by that name with the following prototype:
void cyg_user_start
( void )
When you return control from
cyg_user_start()
,
cyg_start()
will then invoke the scheduler, and any threads you created and resumed in
cyg_user_start()
will be executed. The preferred approach is to allow the scheduler to be started automatically, rather than to start it explicitly in
cyg_user_start()
.
Remember that
cyg_user_start()
is invoked before the scheduler (and frequently the scheduler is invoked as the last step in
cyg_user_start()
), so it should not use any kernel services that require the scheduler.
If you are supplying your own definition of this function from a C++ file, make sure it has "C" linkage.
System start-up | ||
---|---|---|