CONFIGURING THE KERNEL ============================================================================== General instructions for configuring the XMK kernel for a specific application and/or project. TIP: Use projects/linux/i686/xmk/h8300/edk3664/sleep/simple as an example. The XMK kernel is configured via the 'xmkcfg.h' header file, which typically resides in the project's root source directory. The following items should be included in the header file AND in the order specified. 1. Define the maximum number of various kernel resources, such as the following: Max number of threads (always required) Max Priority levels (required when using the priority scheduler) Max number of TSD keys (required when using Thread-Specific-Data) Note: There are other compile-time parameters that can be customized by the application. 2. Configure which kernel services are needed. This is done by defining a series of USE_XMK_xxxx defines followed by including the header file, "xmk/config/resolve.h". See for list of available kernel services. 3. Provide the platform customizations based on the services selected in in the above step. XMK provides default platform-config header files under the src/xmk/config directory tree. The application can directly include the desired platform-config header file, or cut-n-paste the contents directly into xmkcfg.h. 4. Provide any required application/target specific supported that XMK requries. The specifics of the target support required varies based on which kernel services were selected in step 3. Interrupts ------------------------------------------------------------------------------ A single and seperate (from the thread stacks) stack is used for all interrupt processing. This approach provides significant RAM savings, especially as the number of threads increases. However, this means that ALL** interrupt processing must be handled by XMK so the interrupt stack can be 'swapped' in and out appropriately. XMK needs a interrupt-service-routine 'hook' for all interrupt vectors that are used by the applicaiton. XMK hooks into a interrupt vector, by providing the 'raw' interrupt-service routine to allow interaction with the kernel. The XMK ISR stubs in turn call the application's interrupt-service-routines. When the application builds its vector table, for all interrupt, it references the XMK ISR stubs. Since ISRs are VERY target specific, the application must create (and compile & link) the XMK ISR stubs. XMK make this step easier, by providing template source files for creating both non-nested and nested ISR stubs. These templates files can be found under the src/xmk/platform directory tree. ** Note: The restriction and/or requirement of "ALL" interrupt processing be handle by XMK is not an absolute requirement. The application can choose to bypass XMK's interrupt handlers if it meets the following conditions: 1) The application's custom ISRs make *NO* XMK calls. 2) The application provides sufficients stack space for all application stacks to 'handle' the stack usage of the application's custom ISR routine(s). Fatal Error Handler ------------------------------------------------------------------------------ XMK defines a inteface for handling fatal errors. The inteface is used by kernel and can be called the application for it own error handling needs. XMK provides a default implementation of the interface, but the application can provide its own by defining the following: #define USE_XMK_APPLICATION_FATAL_ERROR_HANDLER #define _Xmk_fatalError(e) Building the Kernel ------------------------------------------------------------------------------ The kernel is statically linked in with the application. Which XMK source files that need to be compiled & linked are dependent on what kernel services where configured in step3 (in xmcfg.h ) AND the target platform. To assist the developer in knowing what files to compile, under the src/xmk/config directory tree there is a collection of *.b files that list which source directories (by platform and kernel services) that need to compiled & linked.