This enable defining memory maps in source code in addition to
defining in MDEF files. This introduces the macro
DEFINE_MEM_MAP(mem_map_name, ...). The memory maps created this
way are the same, in functionality, as those defined in MDEF
files. They can be manipulated by the standard microkernel
memory map APIs.
Define the memory map using:
DEFINE_MEM_MAP(mem_map1, blocks, block_size);
and "mem_map1" can be used, for example:
task_mem_map_alloc(mem_map1, ...);
or,
task_mem_map_free(mem_map1, ...);
etc.
To use the memory map defined in another source file, simply add:
extern const kmemory_map_t mem_map1;
to the desired C or header file.
Change-Id: I9c551b90f9d0a95f961fd8ec1c5278c2ea44312d
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The _k_mem_map_list was a static array generated by sysgen,
where it containing all pre-defined memory maps from MDEF file.
To support private memory map objects (aka, defining them within
source files), the list has to accommodate memory maps that
are not only processed through sysgen, but also those defined
within source files.
This is done by creating a new section in binary, and all memory
map pointers go into this section. By doing this, the list
can still be manipulated as an array.
Change-Id: I1f3414b72f685fef4b99850749178661f14d9345
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This enable defining pipes in source code in addition to
defining in MDEF files. This introduces the macro
DEFINE_PIPE(pipe_name, ...). The pipes created this
way are the same, in functionality, as those defined in MDEF
files. They can be manipulated by the standard microkernel
pipe APIs.
Define the pipe using:
DEFINE_PIPE(pipe1, size);
and "pipe1" can be used, for example:
task_pipe_put(pipe1, ...);
or,
task_pipe_get(pipe1, ...);
etc.
To use the pipe defined in another source file, simply add:
extern const kpipe_t pipe1;
to the desired C or header file.
Change-Id: Iae8e04706359bc18aae51acc75df3e3d26388882
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The _k_pipe_list was a static array generated by sysgen,
where it containing all pre-defined pipes from MDEF file.
To support private pipe objects (aka, defining pipes within
source files), the pipe list has to accommodate pipes that
are not only processed through sysgen, but also those defined
within source files.
This is done by creating a new section in binary, and all pipe
pointers go into this section. By doing this, the pipe list
can still be manipulated as an array. The reason behind
putting the pointers to pipe, instead of the pipe objects
themselves, is that some compiler/linker may pad the large pipe
struct. For example, compiling under gcc and march=i686 pads
the struct to 32-byte alignment (march=atom to 64-byte alignment).
This causes issue with sizeof() and pointer arithmetic because
they have no idea about the padding. So use pointers here to
prevent padding.
Change-Id: I6d3b75614c4d8760c037a5c26746410d4e4b17cb
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This enable defining tasks in source code in addition to
defining in MDEF files. This introduces the macro
DEFINE_TASK(task_name). The tasks created this
way are the same, in functionality, as those defined in MDEF
files. They can be manipulated by the standard microkernel
task APIs.
Define the task using:
DEFINE_TASK(task1, priority, entry_func, stack_size, groups);
and "task1" can be used, for example:
task_start(task1);
or,
task_abort(task1);
etc.
To use the task defined in another source file, simply add:
extern const ktask_t task1;
to the desired C or header file.
Change-Id: Ib2f3572950ca74b359b7fde1ccd6cfd04783eefb
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The _k_task_list was a static array generated by sysgen,
where it containing all pre-defined tasks from MDEF file.
To support private task objects (aka, defining tasks within
source files), the task list has to accommodate tasks that
are not only processed through sysgen, but also those defined
within source files.
This is done by creating a new section in binary, and all task
objects go into this section. By doing this, the task list
can still be manipulated as an array, which is required for
task group operation.
Change-Id: I799d6967567079498bc414e0cb809e8af856b53e
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Removes references to obsolete BSP terminology. Where appropriate, replaces it
with platform terminology.
Change-Id: If38c859338c7cf0de58430336e1046b28f9e9944
Signed-off-by: Peter Mitsis <peter.mitsis@windriver.com>
The configuration of SRAM and flash options are no longer hardcoded in the
platform's linker script file, but are instead defined in the platform
configuration file.
Change-Id: I557a8228080d607f6add5f86b9b2509ed3fd31ce
Signed-off-by: Peter Mitsis <peter.mitsis@windriver.com>
The change replaces multiple asterisks to ** at
the beginning of comments and adds a space before
the asterisks at the beginning of lines.
Change-Id: I7656bde3bf4d9a31e38941e43b580520432dabc1
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
IRQ_CONNECT_STATIC() macro provides static interrupt registration.
It creates an entry for _sw_isr_table, table of interrupt handlers.
IRQ_CONFIG() macro provides interrupt controller configuration.
On ARM platform it configures the priority of each interrupt.
_sw_isr_table is implemented the way that each of it's elements
is located in individual section. Sections are marked a "linkonce",
thus when a device driver declares an interrupt handler, it overwrites
the default _sw_isr_table entry.
Change-Id: I182bf7158dd67f45b597783dca038a4f78166a03
Signed-off-by: Dmitriy Korovkin <dmitriy.korovkin@windriver.com>
Add infrastructure support having multiple instances of a driver
configured into the system each with its own compile time
configuration information.
Change-Id: I1e447af18311139b43f74fe0439483ccd132b63f
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Renaming the directory include/nanokernel to be include/arch, which
better reflects the real nature of the directory and the contents
inside.
Change-Id: I2bc33ebc6715e2f0403227a558279fdf52398ade
Signed-off-by: Dan Kalowsky <daniel.kalowsky@intel.com>
