845 lines
34 KiB
Plaintext
845 lines
34 KiB
Plaintext
/**
|
|
* @mainpage ChibiOS/RT
|
|
* @author Giovanni Di Sirio (gdisirio@users.sourceforge.net).
|
|
* @section Chibi Chibi ?
|
|
* It is the Japanese word for small as in small child. So ChibiOS/RT
|
|
* @htmlonly (<span class="t_nihongo_kanji" xml:lang="ja" lang="ja">ちび</span>OS/RT) \endhtmlonly
|
|
* means small Real Time Operating System.
|
|
* Source <a href="http://en.wikipedia.org/wiki/Chibi" target="_blank">Wikipedia</a>.
|
|
* @section ch_features Features
|
|
* <ul>
|
|
* <li>Free software, GPL3 licensed.</li>
|
|
* <li>Designed for realtime applications.</li>
|
|
* <li>Easily portable.</li>
|
|
* <li>Mixed programming model:</li>
|
|
* <ul>
|
|
* <li>Synchronous, using semaphores/mutexes/condvars and/or messages.</li>
|
|
* <li>Asynchronous, using event sources.</li>
|
|
* <li>Mix of the above models, multiple threads listening to multiple event
|
|
* sources while serving message queues.</li>
|
|
* </ul>
|
|
* <li>PC simulator target included, the development can be done on the PC
|
|
* using MinGW.<br>
|
|
* Timers, I/O channels and other HW resources are simulated in a
|
|
* Win32 process and the application code does not need to be aware of it.
|
|
* MinGW demo available.</li>
|
|
* <li>Preemptive scheduling.</li>
|
|
* <li>128 priority levels.</li>
|
|
* <li>Multiple threads at the same priority level allowed.</li>
|
|
* <li>Round robin scheduling for threads at the same priority level.</li>
|
|
* <li>Unlimited number of threads.</li>
|
|
* <li>Unlimited number of virtual timers.</li>
|
|
* <li>Unlimited number of semaphores.</li>
|
|
* <li>Unlimited number of mutexes.</li>
|
|
* <li>Unlimited number of condvars.</li>
|
|
* <li>Unlimited number of event sources.</li>
|
|
* <li>Unlimited number of messages in queue.</li>
|
|
* <li>Unlimited number of I/O queues.</li>
|
|
* <li>No static setup at compile time, there is no need to configure a maximum
|
|
* number of all the above resources.</li>
|
|
* <li>No *need* for a memory allocator, all the kernel structures are static
|
|
* and declaratively allocated.</li>
|
|
* <li>Threads, Semaphores, Event Sources, Virtual Timers creation/deletion at
|
|
* runtime.</li>
|
|
* <li>Optional, thread safe, Heap Allocator subsystem.</li>
|
|
* <li>Optional, thread safe, Memory Pools Allocator subsystem.</li>
|
|
* <li>Blocking and non blocking I/O channels with timeout and events generation
|
|
* capability.</li>
|
|
* <li>Minimal system requirements: about 8KiB ROM with all options enabled and
|
|
* speed optimizations on. The size can shrink under 2KiB by disabling the
|
|
* the unused subsystems and optimizing for size.</li>
|
|
* <li>Small memory footprint, unused subsystems can be excluded by the
|
|
* memory image.</li>
|
|
* <li>Almost totally written in C with little ASM code required for ports.</li>
|
|
* </ul>
|
|
*
|
|
* ChibiOS/RT architecture:<br><br>
|
|
* @subpage Concepts
|
|
*/
|
|
|
|
/**
|
|
* @page Concepts Concepts
|
|
* @{
|
|
* @section naming Naming Conventions
|
|
* ChibiOS/RT APIs are all named following this convention:
|
|
* @a ch\<group\>\<action\>\<suffix\>().
|
|
* The possible groups are: @a Sys, @a Sch, @a VT, @a Thd, @a Sem, @a Mtx,
|
|
* @a Cond, @a Evt, @a Msg, @a IQ, @a OQ, @a HQ, @a FDD, @a HDD, @a Dbg,
|
|
* @a Heap, @a Pool.
|
|
* The suffix is not present for normal APIs but can be one of
|
|
* the following:
|
|
* - <b>"I"</b>, I-Class APIs are invokable only from the I-Locked or S-Locked
|
|
* states. See @ref system_states.
|
|
* - <b>"S"</b>, S-Class APIs are invokable only from the S-Locked state. See
|
|
* @ref system_states.
|
|
*
|
|
* The APIs without suffix can be invoked only from the user code in the Normal
|
|
* state unless differently specified.<br>
|
|
* Examples: @p chThdCreateStatic(), @p chSemSignalI(), @p chIQGetTimeout().
|
|
*
|
|
* @section interrupts Interrupt Classes
|
|
* In ChibiOS/RT there are three logical interrupt classes:
|
|
* - <b>Regular Interrupts</b>. Maskable interrupt sources that cannot
|
|
* preempt the kernel code and are thus able to invoke operating system APIs
|
|
* from within their handlers. The interrupt handlers belonging to this class
|
|
* must be written following some rules. See the @ref System APIs group.
|
|
* - <b>Fast Interrupts</b>. Maskable interrupt sources with the ability
|
|
* to preempt the kernel code and thus have a lower latency. Such sources are
|
|
* not supported on all the architectures.<br>
|
|
* Fast interrupts are not allowed to invoke any operating system API from
|
|
* within their handlers. Fast interrupt sources may however pend a lower
|
|
* priority regular interrupt where access to the operating system is
|
|
* possible.
|
|
* - <b>Non Maskable Interrupts</b>. Non maskable interrupt sources are
|
|
* totally out of the operating system control and have the lowest latency.
|
|
* Such sources are not supported on all the architectures.
|
|
*
|
|
* The mapping of the above logical classes into physical interrupts priorities
|
|
* is, of course, port dependent. See the documentation of the various ports
|
|
* for details.
|
|
*
|
|
* @section system_states System States
|
|
* When using ChibiOS/RT the system can be in one of the following logical
|
|
* operating states:
|
|
* - <b>Initialization</b>. When the system is in this state all the maskable
|
|
* interrupt sources are disabled. In this state it is not possible to use
|
|
* any system API except @p chSysInit(). This state is entered after a
|
|
* physical reset.
|
|
* - <b>Normal</b>. All the interrupt sources are enabled and the system APIs
|
|
* are accessible, threads are running.
|
|
* - <b>Suspended</b>. In this state the fast interrupt sources are enabled but
|
|
* the regular interrupt sources are not. In this state it is not possible
|
|
* to use any system API except @p chSysDisable() or @p chSysEnable() in
|
|
* order to change state.
|
|
* - <b>Disabled</b>. When the system is in this state both the maskable
|
|
* regular and fast interrupt sources are disabled. In this state it is not
|
|
* possible to use any system API except @p chSysSuspend() or
|
|
* @p chSysEnable() in order to change state.
|
|
* - <b>Sleep</b>. Architecture-dependent low power mode, the idle thread
|
|
* goes in this state and waits for interrupts, after servicing the interrupt
|
|
* the Normal state is restored and the scheduler has a chance to reschedule.
|
|
* - <b>S-Locked</b>. Kernel locked and regular interrupt sources disabled.
|
|
* Fast interrupt sources are enabled. S-Class and I-Class APIs are
|
|
* invokable in this state.
|
|
* - <b>I-Locked</b>. Kernel locked and regular interrupt sources disabled.
|
|
* I-Class APIs are invokable from this state.
|
|
* - <b>Serving Regular Interrupt</b>. No system APIs are accessible but it is
|
|
* possible to switch to the I-Locked state using @p chSysLockI() and then
|
|
* invoke any I-Class API. Interrupt handlers can be preemptable on some
|
|
* architectures thus is important to switch to I-Locked state before
|
|
* invoking system APIs.
|
|
* - <b>Serving Fast Interrupt</b>. System APIs are not accessible.
|
|
* - <b>Serving Non-Maskable Interrupt</b>. System APIs are not accessible.
|
|
* - <b>Halted</b>. All interrupt sources are disabled and system stopped into
|
|
* an infinite loop. This state can be reached if the debug mode is activated
|
|
* <b>and</b> an error is detected <b>or</b> after explicitly invoking
|
|
* @p chSysHalt().
|
|
*
|
|
* Note that the above state are just <b>Logical States</b> that may have no
|
|
* real associated machine state on some architectures. The following diagram
|
|
* shows the possible transitions between the states:
|
|
*
|
|
* @dot
|
|
digraph example {
|
|
rankdir="LR";
|
|
node [shape=circle, fontname=Helvetica, fontsize=8, fixedsize="true", width="0.75", height="0.75"];
|
|
init [label="Initialization", style="bold"];
|
|
norm [label="Normal", shape=doublecircle];
|
|
susp [label="Suspended"];
|
|
disab [label="Disabled"];
|
|
slock [label="S-Locked"];
|
|
ilock [label="I-Locked"];
|
|
slock [label="S-Locked"];
|
|
sleep [label="Sleep"];
|
|
sri [label="SRI"];
|
|
sfi [label="SFI"];
|
|
init -> norm [label="chSysInit()", fontname=Helvetica, fontsize=8];
|
|
norm -> slock [label="chSysLock()", fontname=Helvetica, fontsize=8, constraint=false];
|
|
slock -> norm [label="chSysUnlock()", fontname=Helvetica, fontsize=8];
|
|
norm -> susp [label="chSysSuspend()", fontname=Helvetica, fontsize=8];
|
|
susp -> disab [label="chSysDisable()", fontname=Helvetica, fontsize=8];
|
|
norm -> disab [label="chSysDisable()", fontname=Helvetica, fontsize=8];
|
|
susp -> norm [label="chSysEnable()", fontname=Helvetica, fontsize=8];
|
|
disab -> norm [label="chSysEnable()", fontname=Helvetica, fontsize=8];
|
|
slock -> ilock [dir="both", label="Context Switch", fontname=Helvetica, fontsize=8];
|
|
norm -> sri [style="dotted", label="Regular IRQ", fontname=Helvetica, fontsize=8];
|
|
norm -> sfi [style="dotted", label="Fast IRQ", fontname=Helvetica, fontsize=8];
|
|
susp -> sfi [style="dotted", label="Fast IRQ", fontname=Helvetica, fontsize=8];
|
|
sri -> norm [label="Regular IRQ return", fontname=Helvetica, fontsize=8];
|
|
sfi -> norm [label="Fast IRQ return", fontname=Helvetica, fontsize=8];
|
|
sfi -> susp [label="Fast IRQ return", fontname=Helvetica, fontsize=8];
|
|
sri -> ilock [label="chSysLockI()", fontname=Helvetica, fontsize=8, constraint=false];
|
|
ilock -> sri [label="chSysUnlockI()", fontname=Helvetica, fontsize=8];
|
|
norm -> sleep [label="Idle Thread", fontname=Helvetica, fontsize=8];
|
|
sleep -> sri [style="dotted", label="Regular IRQ", fontname=Helvetica, fontsize=8];
|
|
sleep -> sfi [style="dotted", label="Fast IRQ", fontname=Helvetica, fontsize=8];
|
|
}
|
|
* @enddot
|
|
* Note, the Halted and SNMI states can be reached from any state and are not
|
|
* shown for simplicity.
|
|
*
|
|
* @section scheduling Scheduling
|
|
* The strategy is very simple the currently ready thread with the highest
|
|
* priority is executed. If more than one thread with equal priority are
|
|
* eligible for execution then they are executed in a round-robin way, the
|
|
* CPU time slice constant is configurable. The ready list is a double linked
|
|
* list of threads ordered by priority.<br><br>
|
|
* @image html readylist.png
|
|
* Note that the currently running thread is not in the ready list, the list
|
|
* only contains the threads ready to be executed but still actually waiting.
|
|
*
|
|
* @section thread_states Threads States
|
|
* The image shows how threads can change their state in ChibiOS/RT.<br>
|
|
* @image html states.png
|
|
*
|
|
* @section priority Priority Levels
|
|
* Priorities in ChibiOS/RT are a contiguous numerical range but the initial
|
|
* and final values are not enforced.<br>
|
|
* The following table describes the various priority boundaries (from lowest
|
|
* to highest):
|
|
* - @p IDLEPRIO, this is the lowest priority level and is reserved for the
|
|
* idle thread, no other threads should share this priority level. This is
|
|
* the lowest numerical value of the priorities space.
|
|
* - @p LOWPRIO, the lowest priority level that can be assigned to an user
|
|
* thread.
|
|
* - @p NORMALPRIO, this is the central priority level for user threads. It is
|
|
* advisable to assign priorities to threads as values relative to
|
|
* @p NORMALPRIO, as example NORMALPRIO-1 or NORMALPRIO+4, this ensures the
|
|
* portability of code should the numerical range change in future
|
|
* implementations.
|
|
* - @p HIGHPRIO, the highest priority level that can be assigned to an user
|
|
* thread.
|
|
* - @p ABSPRO, absolute maximum software priority level, it can be higher than
|
|
* @p HIGHPRIO but the numerical values above @p HIGHPRIO up to @p ABSPRIO
|
|
* (inclusive) are reserved. This is the highest numerical value of the
|
|
* priorities space.
|
|
*
|
|
* @section warea Thread Working Area
|
|
* Each thread has its own stack, a Thread structure and some preemption
|
|
* areas. All the structures are allocated into a "Thread working area",
|
|
* a thread private heap, usually allocated in an array declared in your
|
|
* code. Threads do not use any memory outside the allocated working area
|
|
* except when accessing static shared data.<br><br>
|
|
* @image html workspace.png
|
|
* <br>
|
|
* Note that the preemption area is only present when the thread is not
|
|
* running (switched out), the context switching is done by pushing the
|
|
* registers on the stack of the switched-out thread and popping the registers
|
|
* of the switched-in thread from its stack.
|
|
* The preemption area can be divided in up to three structures:
|
|
* - External context.
|
|
* - Interrupt stack.
|
|
* - Internal context.
|
|
*
|
|
* See the @ref Core documentation for details, the area may change on
|
|
* the various ports and some structures may not be present (or be zero-sized).
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Ports Ports
|
|
* @{
|
|
* This section describes the technical details for the various supported
|
|
* ChibiOS/RT ports.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup ARM7 ARM7TDMI
|
|
* @{
|
|
* <p>
|
|
* The ARM7 port supports 3 modes:
|
|
* </p>
|
|
* <ul>
|
|
* <li>Pure ARM mode, this is the preferred mode for code speed. The code size
|
|
* is larger however. This mode is enabled when all the modules are compiled
|
|
* in ARM mode, see the Makefiles.</li>
|
|
* <li>Pure THUMB mode, this is the preferred mode for code size. In this mode
|
|
* the execution speed is slower than the ARM mode. This mode is enabled
|
|
* when all the modules are compiled in THUMB mode, see the Makefiles.</li>
|
|
* <li>Interworking mode, when in the system there are ARM modules mixed with
|
|
* THUMB modules then the interworking compiler option is enabled. This is
|
|
* usually the slowest mode and the code size is not as good as in pure
|
|
* THUMB mode.</li>
|
|
* </ul>
|
|
* <p>
|
|
* The ARM7 port makes some assumptions on the application code organization:
|
|
* <ul>
|
|
* <li>The @p main() function is invoked in system mode.</li>
|
|
* <li>Each thread has a private user/system stack, the system has a single
|
|
* interrupt stack where all the interrupts are processed.</li>
|
|
* <li>The threads are started in system mode.</li>
|
|
* <li>The threads code can run in system mode or user mode, however the
|
|
* code running in user mode cannot invoke the ChibiOS/RT APIs directly
|
|
* because privileged instructions are used inside.<br>
|
|
* The kernel APIs can be eventually invoked by using a SWI entry point
|
|
* that handles the switch in system mode and the return in user mode.</li>
|
|
* <li>Other modes are not preempt-able because the system code assumes the
|
|
* threads running in system mode. When running in supervisor or other
|
|
* modes make sure that the interrupts are globally disabled.</li>
|
|
* <li>Interrupts nesting is not supported in the ARM7 code because their
|
|
* implementation, even if possible, is not really efficient in this
|
|
* architecture.</li>
|
|
* <li>FIQ sources can preempt the kernel (by design) so it is not possible to
|
|
* invoke the kernel APIs from inside a FIQ handler. FIQ handlers are not
|
|
* affected by the kernel activity so there is not added jitter.</li>
|
|
* <li>Interrupt handlers do not save function-saved registers so you need to
|
|
* make sure your code saves them or does not use them (this happens
|
|
* because in the ARM7 port all the OS interrupt handlers are declared
|
|
* naked).<br>
|
|
* Function-trashed registers (R0-R3,R12,LR,SR) are saved/restored by the
|
|
* system macros @p chSysIRQEnterI() and @p chSysIRQExitI().<br>
|
|
* The easiest way to ensure this is to just invoke a function from within
|
|
* the interrupt handler, the function code will save all the required
|
|
* registers.<br>
|
|
* Example:
|
|
* @code
|
|
* __attribute__((naked, weak))
|
|
* void irq_handler(void) {
|
|
* chSysIRQEnterI();
|
|
*
|
|
* serve_interrupt();
|
|
*
|
|
* VICVectAddr = 0; // This is LPC214x-specific.
|
|
* chSysIRQExitI();
|
|
* }
|
|
* @endcode
|
|
* This is not a bug but an implementation choice, this solution allows to
|
|
* have interrupt handlers compiled in thumb mode without have to use an
|
|
* interworking mode (the mode switch is hidden in the macros), this
|
|
* greatly improves code efficiency and size. You can look at the serial
|
|
* driver for real examples of interrupt handlers.</li>
|
|
* </ul>
|
|
* </p>
|
|
* @ingroup Ports
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup ARM7CONF Configuration Options
|
|
* @{
|
|
* <p>
|
|
* The ARM7 port allows some architecture-specific configurations settings
|
|
* that can be specified externally, as example on the compiler command line:
|
|
* <ul>
|
|
* <li>@p INT_REQUIRED_STACK, this value represent the amount of stack space used
|
|
* by an interrupt handler between the @p extctx and @p intctx
|
|
* structures.<br>
|
|
* In practice this value is the stack space used by the chSchDoReschedule()
|
|
* stack frame.<br>
|
|
* This value can be affected by a variety of external things like compiler
|
|
* version, compiler options, kernel settings (speed/size) and so on.<br>
|
|
* The default for this value is @p 0x10 which should be a safe value, you
|
|
* can trim this down by defining the macro externally. This would save
|
|
* some valuable RAM space for each thread present in the system.<br>
|
|
* The default value is set into <b>./ports/ARM7/chcore.h</b>.</li>
|
|
* </ul>
|
|
* </p>
|
|
* @ingroup ARM7
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup LPC214x LPC214x Support
|
|
* @{
|
|
* <p>
|
|
* The LPC214x support includes:
|
|
* <ul>
|
|
* <li>VIC support code.</li>
|
|
* <li>Buffered, interrupt driven, serial driver.</li>
|
|
* <li>SSP driver.</li>
|
|
* <li>A MMC/SD demo driver.</li>
|
|
* <li>A buzzer demo driver.</li>
|
|
* <li>A minimal demo, useful as project template.</li>
|
|
* <li>A demo supporting the kernel test suite.</li>
|
|
* <li>A C++ demo supporting the kernel test suite.</li>
|
|
* </ul>
|
|
* </p>
|
|
* @ingroup ARM7
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup AT91SAM7X AT91SAM7X Support
|
|
* @{
|
|
* <p>
|
|
* The AT91SAM7X support includes:
|
|
* <ul>
|
|
* <li>Buffered, interrupt driven, serial driver.</li>
|
|
* <li>EMAC driver with MII support.</li>
|
|
* <li>A demo supporting the kernel test suite.</li>
|
|
* <li>A Web server demo using the uIP TCP/IP stack.</li>
|
|
* </ul>
|
|
* </p>
|
|
* @ingroup ARM7
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup ARMCM3 ARM Cortex-M3
|
|
* @{
|
|
* <p>
|
|
* The ARM Cortex-M3 port is organized as follow:
|
|
* </p>
|
|
* <ul>
|
|
* <li>The @p main() function is invoked in thread-privileged mode.</li>
|
|
* <li>Each thread has a private process stack, the system has a single main
|
|
* stack where all the interrupts and exceptions are processed.</li>
|
|
* <li>Only the 4 MSb of the priority level are used, the 4 LSb are assumed
|
|
* to be zero.</li>
|
|
* <li>The threads are started in thread-privileged mode with BASEPRI level
|
|
* 0x00 (disabled).</li>
|
|
* <li>The kernel raises its BASEPRI level to 0x10 in order to protect the
|
|
* system mutex zones. Note that exceptions with level 0x00 can preempt
|
|
* the kernel, such exception handlers cannot invoke kernel APIs directly.
|
|
* It is possible to modify the priority levels by editing the
|
|
* <b>./ports/ARMCM3/chcore.h</b> file.</li>
|
|
* <li>Interrupt nesting and the other advanced NVIC features are supported.</li>
|
|
* <li>The SVC instruction and vector, with parameter #0, is internally used
|
|
* for commanded context switching.<br>
|
|
* It is possible to share the SVC handler at the cost of slower context
|
|
* switching.</li>
|
|
* <li>The PendSV vector is internally used for preemption context switching.</li>
|
|
* </ul>
|
|
* @ingroup Ports
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup ARMCM3CONF Configuration Options
|
|
* @{
|
|
* <p>
|
|
* The ARMCM3 port allows some architecture-specific configurations settings
|
|
* that can be specified externally, as example on the compiler command line:
|
|
* <ul>
|
|
* <li>@p INT_REQUIRED_STACK, this value represent the amount of stack space used
|
|
* by an interrupt handler between the @p extctx and @p intctx
|
|
* structures.<br>
|
|
* In the current implementation this value is guaranteed to be zero so
|
|
* there is no need to modify this value unless changes are done at the
|
|
* interrupts handling code.</li>
|
|
* <li>@p BASEPRI_USER, this is the @p BASEPRI value for the user threads. The
|
|
* default value is @p 0 (disabled).<br>
|
|
* Usually there is no need to change this value, please refer to the
|
|
* Cortex-M3 technical reference manual for a detailed description.</li>
|
|
* <li>@p BASEPRI_KERNEL, this is the @p BASEPRI value for the kernel lock code.
|
|
* The default value is 0x10.<br>
|
|
* Code running at higher priority levels must not invoke any OS API.<br>
|
|
* Usually there is no need to change this value, please refer to the
|
|
* Cortex-M3 technical reference manual for a detailed description.</li>
|
|
* <li>@p ENABLE_WFI_IDLE, if set to @p 1 enables the use of the @p wfi
|
|
* instruction from within the idle loop. This is defaulted to 0 because
|
|
* it can create problems with some debuggers. Setting this option to 1
|
|
* reduces the system power requirements.</li>
|
|
* </ul>
|
|
* </p>
|
|
* @ingroup ARMCM3
|
|
*/
|
|
/** @} */
|
|
|
|
|
|
/**
|
|
* @defgroup STM32F103 STM32F103 Support
|
|
* @{
|
|
* <p>
|
|
* The STM32F103 support includes:
|
|
* <ul>
|
|
* <li>Buffered, interrupt driven, serial driver.</li>
|
|
* <li>A demo supporting the kernel test suite.</li>
|
|
* </ul>
|
|
* </p>
|
|
* @ingroup ARMCM3
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup AVR MegaAVR
|
|
* @{
|
|
* <p>
|
|
* Notes about the AVR port:
|
|
* </p>
|
|
* <ul>
|
|
* <li>The AVR does not have a dedicated interrupt stack, make sure to reserve
|
|
* enough stack space for interrupts in each thread stack. This can be done
|
|
* by modifying the @p INT_REQUIRED_STACK macro into
|
|
* <b>./ports/AVR/chcore.h</b>.</li>
|
|
* </ul>
|
|
* @ingroup Ports
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup AVRCONF Configuration Options
|
|
* @{
|
|
* <p>
|
|
* The AVR port allows some architecture-specific configurations settings
|
|
* that can be specified externally, as example on the compiler command line:
|
|
* <ul>
|
|
* <li>@p INT_REQUIRED_STACK, this value represent the amount of stack space
|
|
* used by the interrupt handlers.<br>
|
|
* The default for this value is @p 32, this space is allocated for each
|
|
* thread so be careful in order to not waste precious RAM space.<br>
|
|
* The default value is set into <b>./ports/AVR/chcore.h</b>.</li>
|
|
* </ul>
|
|
* </p>
|
|
* @ingroup AVR
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup MSP430 MSP430
|
|
* @{
|
|
* <p>
|
|
* Notes about the MSP430 port:
|
|
* </p>
|
|
* <ul>
|
|
* <li>The MSP430 does not have a dedicated interrupt stack, make sure to reserve
|
|
* enough stack space for interrupts in each thread stack. This can be done
|
|
* by modifying the @p INT_REQUIRED_STACK macro into
|
|
* <b>./ports/MSP430/chcore.h</b>.</li>
|
|
* </ul>
|
|
* @ingroup Ports
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup MSP430CONF Configuration Options
|
|
* @{
|
|
* <p>
|
|
* The MSP430 port allows some architecture-specific configurations settings
|
|
* that can be specified externally, as example on the compiler command line:
|
|
* <ul>
|
|
* <li>@p INT_REQUIRED_STACK, this value represent the amount of stack space
|
|
* used by the interrupt handlers.<br>
|
|
* The default for this value is @p 32, this space is allocated for each
|
|
* thread so be careful in order to not waste precious RAM space.<br>
|
|
* The default value is set into <b>./ports/MSP430/chcore.h</b>.</li>
|
|
* </ul>
|
|
* </p>
|
|
* @ingroup MSP430
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Kernel Kernel
|
|
* @{
|
|
* @file ch.h ChibiOS/RT main include file, it includes everything else.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Config Configuration
|
|
* @{
|
|
* In @p chconf.h are defined the required subsystems for your application.
|
|
* @ingroup Kernel
|
|
* @file chconf.h ChibiOS/RT configuration file.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Core Core
|
|
* @{
|
|
* Non portable code.
|
|
* @ingroup Kernel
|
|
* @file chcore.c Non portable code.
|
|
* @file chcore.h Non portable macros and structures.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Types Types
|
|
* @{
|
|
* System types and macros.
|
|
* @ingroup Kernel
|
|
* @file chtypes.h System types and code modifiers.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup System System Management
|
|
* @{
|
|
* Initialization, Locks, Interrupt Handling, Power Management, Abnormal
|
|
* Termination.
|
|
* @ingroup Kernel
|
|
* @file sys.h System related macros and structures.
|
|
* @file chsys.c System related code.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Inline Inline
|
|
* @{
|
|
* System inline-able code.
|
|
* @ingroup Kernel
|
|
* @file inline.h Inline versions of some critical system routines.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Debug Debug
|
|
* @{
|
|
* Debug APIs and procedures.
|
|
* @ingroup Kernel
|
|
* @file debug.h Debug macros and structures.
|
|
* @file chdebug.c ChibiOS/RT Debug code.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Scheduler Scheduler
|
|
* @{
|
|
* ChibiOS/RT scheduler.
|
|
* @ingroup Kernel
|
|
* @file chschd.c Scheduler code.
|
|
* @file scheduler.h Scheduler macros and structures.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup ThreadLists Thread Lists and Queues
|
|
* @{
|
|
* ChibiOS/RT thread lists and queues utilities.
|
|
* @ingroup Kernel
|
|
* @file chlists.c Lists and queues code.
|
|
* @file lists.h Lists and queues macros and structures.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Threads Threads
|
|
* @{
|
|
* Threads creation and termination APIs.
|
|
* @file threads.h Threads structures, macros and functions.
|
|
* @file chthreads.c Threads code.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Time Time and Virtual Timers
|
|
* @{
|
|
* Time and Virtual Timers related APIs.
|
|
* @file include/vt.h Time macros and structures.
|
|
* @file chvt.c Time functions.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Heap Heap
|
|
* @{
|
|
* Heap Allocator related APIs.
|
|
* <b>Operation mode</b><br><br>
|
|
* The heap allocator implements a first-fit strategy and its APIs are
|
|
* functionally equivalent to the usual @p malloc() and @p free(). The main
|
|
* difference is that the heap APIs are thread safe.<br>
|
|
* By enabling the @p CH_USE_MALLOC_HEAP option the heap manager will use the
|
|
* runtime-provided @p malloc() and @p free() as backend for the heap APIs
|
|
* instead of the system provided allocator.<br>
|
|
* In order to use the heap APIs the @p CH_USE_HEAP option must be specified
|
|
* in @p chconf.h.
|
|
* @file include/heap.h Heap macros and structures.
|
|
* @file chheap.c Heap functions.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup MemoryPools Memory Pools
|
|
* @{
|
|
* Memory Pools related APIs.
|
|
* <b>Operation mode</b><br><br>
|
|
* The Memory Pools APIs allow to allocate/free fixed size objects in
|
|
* <b>constant time</b> and reliably without memory fragmentation problems.<br>
|
|
* In order to use the Time APIs the @p CH_USE_MEMPOOLS option must be
|
|
* specified in @p chconf.h.
|
|
* @file include/mempools.h Memory Pools macros and structures.
|
|
* @file chmempools.c Memory Pools functions.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Semaphores Semaphores
|
|
* @{
|
|
* Semaphores and threads synchronization.
|
|
* <b>Operation mode</b><br><br>
|
|
* A semaphore is a threads synchronization object, some operations
|
|
* are defined on semaphores:<br>
|
|
* <ul>
|
|
* <li><b>Signal</b>: The semaphore counter is increased and if the result
|
|
* is non-positive then a waiting thread is removed from the semaphore
|
|
* queue and made ready for execution.
|
|
* </li>
|
|
* <li><b>Wait</b>: The semaphore counter is decreased and if the result
|
|
* becomes negative the thread is queued in the semaphore and suspended.
|
|
* </li>
|
|
* <li><b>Reset</b>: The semaphore counter is reset to a non-negative value
|
|
* and all the threads in the queue are released.
|
|
* </li>
|
|
* </ul>
|
|
* Semaphores can be used as guards for mutual exclusion code zones but
|
|
* also have other uses, queues guards and counters as example.<br>
|
|
* In order to use the Semaphores APIs the @p CH_USE_SEMAPHORES
|
|
* option must be specified in @p chconf.h.<br><br>
|
|
* @file semaphores.h Semaphores macros and structures.
|
|
* @file chsem.c Semaphores code.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Mutexes Mutexes
|
|
* @{
|
|
* Mutexes and threads synchronization.
|
|
* <b>Operation mode</b><br><br>
|
|
* A mutex is a threads synchronization object, some operations are defined
|
|
* on mutexes:<br>
|
|
* <ul>
|
|
* <li><b>Lock</b>: The mutex is checked, if the mutex is not owned by some
|
|
* other thread then it is locked else the current thread is queued on the
|
|
* mutex in a list ordered by priority.
|
|
* </li>
|
|
* <li><b>Unlock</b>: The mutex is released by the owner and the highest
|
|
* priority thread waiting in the queue, if any, is resumed and made owner
|
|
* of the mutex.
|
|
* </li>
|
|
* </ul>
|
|
* In order to use the Event APIs the @p CH_USE_MUTEXES option must be
|
|
* specified in @p chconf.h.<br>
|
|
*
|
|
* <b>Constraints</b><br><br>
|
|
* In ChibiOS/RT the Unlock operations are always performed in Lock-reverse
|
|
* order. The Unlock API does not even have a parameter, the mutex to unlock
|
|
* is taken from an internal stack of owned mutexes.
|
|
* This both improves the performance and is required by the priority
|
|
* inheritance mechanism.
|
|
*
|
|
* <b>The priority inversion problem</b><br><br>
|
|
* The mutexes in ChibiOS/RT implements the <b>full</b> priority
|
|
* inheritance mechanism in order handle the priority inversion problem.<br>
|
|
* When a thread is queued on a mutex, any thread, directly or indirectly,
|
|
* holding the mutex gains the same priority of the waiting thread (if their
|
|
* priority was not already equal or higher). The mechanism works with any
|
|
* number of nested mutexes and any number of involved threads. The algorithm
|
|
* complexity (worst case) is N with N equal to the number of nested mutexes.
|
|
* @file mutexes.h Mutexes macros and structures.
|
|
* @file chmtx.c Mutexes functions.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup CondVars Conditional Variables
|
|
* @{
|
|
* Conditional Variables and threads synchronization.
|
|
* <b>Operation mode</b><br><br>
|
|
* The condition variable is a synchronization object meant to be used inside
|
|
* a zone protected by a @p Mutex. Mutexes and CondVars together can implement
|
|
* a Monitor construct.<br>
|
|
* In order to use the Conditional Variables APIs the @p CH_USE_CONDVARS
|
|
* option must be specified in @p chconf.h.<br><br>
|
|
* @file condvars.h Conditional Variables macros and structures.
|
|
* @file chcond.c Conditional Variables code.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Events Events
|
|
* @{
|
|
* Event Sources and Event Listeners.<br>
|
|
* <b>Operation mode</b><br><br>
|
|
* An Event Source is a special object that can be signaled by a thread or
|
|
* an interrupt service routine. Signaling an Event Source has the effect
|
|
* that all the threads registered on the Event Source will receive
|
|
* and serve the event.<br>
|
|
* An unlimited number of Event Sources can exists in a system and each
|
|
* thread can listen on an unlimited number of them.<br>
|
|
* Note that the events can be asynchronously generated but are synchronously
|
|
* served, a thread can serve event by calling a @p chEvtWaitXXX()
|
|
* API. If an event is generated while a listening thread is not ready to
|
|
* serve it then the event becomes "pending" and will be served as soon the
|
|
* thread invokes a @p chEvtWaitXXX().<br>
|
|
* In order to use the Event APIs the @p CH_USE_EVENTS option must be
|
|
* specified in @p chconf.h.
|
|
* @file events.h Events macros and structures.
|
|
* @file chevents.c Events functions.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Messages Messages
|
|
* @{
|
|
* Synchronous Messages.<br>
|
|
* <b>Operation Mode</b><br><br>
|
|
* Messages are an easy to use and fast IPC mechanism, threads can both serve
|
|
* messages and send messages to other threads, the mechanism allows data to
|
|
* be carryed in both directions. Data is not copyed between the client and
|
|
* server threads but just a pointer passed so the exchange is very time
|
|
* efficient.<br>
|
|
* Messages are usually processed in FIFO order but it is possible to process
|
|
* them in priority order by specifying CH_USE_MESSAGES_PRIORITY
|
|
* in @p chconf.h.<br>
|
|
* Threads do not need to allocate space for message queues, the mechanism
|
|
* just requires two extra pointers in the @p Thread structure (the message
|
|
* queue header).<br>
|
|
* In order to use the Messages APIs the @p CH_USE_MESSAGES option must be
|
|
* specified in @p chconf.h.
|
|
* @file messages.h Messages macros and structures.
|
|
* @file chmsg.c Messages functions.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup IOQueues I/O Queues
|
|
* @{
|
|
* ChibiOS/RT supports several kinds of queues. The queues are mostly used
|
|
* in serial-like device drivers. The device drivers are usually designed to
|
|
* have a lower side (lower driver, it is usually an interrupt service
|
|
* routine) and an upper side (upper driver, accessed by the application
|
|
* threads).<br>
|
|
* There are several kind of queues:<br>
|
|
* <ul>
|
|
* <li><b>Input queue</b>, unidirectional queue where the writer is the
|
|
* lower side and the reader is the upper side.</li>
|
|
* <li><b>Output queue</b>, unidirectional queue where the writer is the
|
|
* upper side and the reader is the lower side.</li>
|
|
* <li><b>Half duplex queue</b>, bidirectional queue where the buffer is shared
|
|
* between a receive and a transmit queues. This means that concurrent
|
|
* buffered input and output operations are not possible, this is perfectly
|
|
* acceptable for a lot of applications however, as example an RS485 driver.
|
|
* <li><b>Full duplex queue</b>, bidirectional queue where read and write
|
|
* operations can happen at the same time. Full duplex queues
|
|
* are implemented by pairing an input queue and an output queue together.
|
|
* </ul>
|
|
* In order to use the I/O queues the @p CH_USE_QUEUES option must
|
|
* be specified in @p chconf.h.<br>
|
|
* In order to use the half duplex queues the @p CH_USE_QUEUES_HALFDUPLEX
|
|
* option must be specified in @p chconf.h.
|
|
* @file queues.h I/O Queues macros and structures.
|
|
* @file chqueues.c I/O Queues code.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup Serial Serial Drivers
|
|
* @{
|
|
* This module implements a generic full duplex serial driver and a generic
|
|
* half duplex serial driver. It uses the I/O Queues for communication between
|
|
* the upper and the lower driver and events to notify the application about
|
|
* incoming data, outcoming data and other I/O events.
|
|
* The module also contains functions that make the implementation of the
|
|
* interrupt service routines much easier.<br>
|
|
* In order to use the serial full duplex driver the
|
|
* @p CH_USE_SERIAL_FULLDUPLEX option must be specified in @p chconf.h.<br>
|
|
* In order to use the serial half duplex driver the
|
|
* @p CH_USE_SERIAL_HALFDUPLEX option must be specified in @p chconf.h.
|
|
* @file serial.h Serial Drivers macros and structures.
|
|
* @file chserial.c Serial Drivers code.
|
|
*/
|
|
/** @} */
|
|
|
|
/**
|
|
* @defgroup CPlusPlusLibrary C++ Wrapper
|
|
* @{
|
|
* C++ wrapper module. This module allows to use the ChibiOS/RT functionalities
|
|
* from C++ as classes and objects rather the traditional "C" APIs.
|
|
* @file ch.hpp C++ wrapper classes and definitions.
|
|
* @file ch.cpp C++ wrapper code.
|
|
*/
|
|
/** @} */
|