About KAL
The Kernel Abstraction Layer (KAL) is intended to be used by Micrium products (µC/FS, µC/TCP-IP, µC/USB-Device, etc.) to completely make abstraction of any kernel used.
KAL is not as a full-featured kernel abstraction layer and only aims to provide minimal kernel services for usage in Micriµm's products and thus its functions should not be called by your application(s), except for an optional call to KAL_Init.
The KAL implementation code for µC/OS-II and µC/OS-III is available. Users of third party kernel will need to provide their own KAL implement using the provided template file,.
Installation
The kal.h and <KERNEL>/kal.c file corresponding to the kernel used (no kernel, uC/OS-II or uC/OS-III) must be included in the project.
The path to the root of the kernel used (C:/Micrium/Software/uCOS-II or C:/Micrium/Software/uCOS-III, by default) must be added to the compiler's list of include paths.
uCOS-II/Source or uCOS-III/Source may also need to be added in the list of include paths, depending on the version of the kernel used.
Configuration
If KAL resources are allocated from the heap (no specific memory segment is used, as specified through KAL_Init), LIB_MEM_CFG_HEAP_SIZE (in lib_cfg.h) must provide enough memory for allocation of these resources.
Initialization
KAL must only be initialized by the application if a specific memory segment is to be used to allocate the resources used by KAL. These resources can include pools for semaphores, locks, timers and optionally task stacks.
If no specific memory needs to be used for KAL resources, the products using KAL (µC/FS, µC/TPC, etc.) will call KAL_Init themselves without specifying a memory segment. In that case, KAL will allocate its resources in the heap and LIB_MEM_CFG_HEAP_SIZE may need to be adjusted to provide enough memory for allocating these resources.
Initialization example for specific memory location use
This initialization example shows how KAL can be initialized and configured to use a specific memory location to allocate everything it needs.
(1) The application file must include KAL/kal.h and lib_mem.h, to access KAL and µC/LIB types and functions. (2) The size of the memory segment that KAL will use. The required size varies depending on the application. If more kernel objects (semaphores, tasks, etc.) are needed by the products (µC/FS, µC/USB-Host, etc.), the amount of memory used by KAL will be greater. (3) Declare a MEM_SEG variable, that will contain information about the memory segment used by KAL. (4) Declare memory that KAL will use (via the memory segment) to allocate everything needed. This memory could be allocated from elsewhere, depending on the application and type(s) of memory available. (5) Mem_Init() must be called before calling either Mem_SegCreate() and KAL_Init(). (6) Create the memory segment that will be used by KAL to allocate everything it needs. This memory segment could also be used to allocate other items, related to the kernel or not. (7) Set the MemSegPtr field of the KAL configuration to point to the created memory segment. (8) Initialize Kernel Abstraction Layer (KAL), using the desired configuration.#include <KAL/kal.h> (1)
#include <lib_mem.h>
#define APP_KAL_MEM_SEG_LEN (10u * 1024u) (2)
static MEM_SEG App_KAL_MemSeg; (3)
static CPU_INT08U App_KAL_MemSegData[APP_KAL_MEM_SEG_LEN]; (4)
static void AppTaskStart (void *p_arg)
{
KAL_CFG cfg_kal;
RTOS_ERR err_rtos;
LIB_ERR err_lib;
[...]
Mem_Init(); (5)
Mem_SegCreate("KAL - Memory segment", (6)
&App_KAL_MemSeg,
(void *)App_KAL_MemSegData,
sizeof(App_KAL_MemSegData),
&err_lib);
if (err_lib != LIB_MEM_ERR_NONE) {
APP_TRACE_INFO(("Could not create KAL memory segment w/err = %d\r\n", err_lib));
/* !!!! Handle error. */
}
cfg_kal.MemSegPtr = &App_KAL_MemSeg; (7)
KAL_Init(&cfg_kal, (8)
&err_rtos);
if (err_rtos!= RTOS_ERR_NONE) {
APP_TRACE_INFO(("Could not initialize KAL w/err = %d\r\n", err_rtos));
/* !!!! Handle error. */
}
[...]
}