This article builds on top of Mastering multithreading with ChibiOS: a beginner’s guide<\/a> and delves into the details of thread scheduling in ChibiOS\/RT. It focuses on how threads switch, the impact of thread priorities on scheduling, the effects of priority inversion, and guidelines for configuring the scheduler to optimize the RTOS performance.<\/p>\n\n\n\n One of the key features of an RTOS, such as ChibiOS\/RT and perhaps its most fundamental feature, is multithreading. But what exactly is a thread? We can think of a thread as a single path of execution: a sequence of instructions that the system executes in order. A thread typically starts with some initial configuration and then enters a loop, where it performs a series of periodic tasks indefinitely. This loop continues unless the application stops (e.g. the MCU is powered down) or the thread is terminated through software commands.<\/p>\n\n\n\n A thread is a continuous stream of code execution that can potentially run endlessly.<\/p>\n<\/blockquote>\n\n\n\n If we were to imagine a thread therefore, we could imagine it as straight arrow that starts at a point and extends indefinitely.<\/p>\n\n\n An RTOS like ChibiOS\/RT enables multiple threads to operate in a parallel fashion, even on a single-core CPU. It achieves this by allocating CPU time to each thread according to specific rules. Hence, an RTOS is often referred to as a Scheduler<\/strong>, and the set of rules it uses to determine the execution order of threads is known as the Scheduling Strategy<\/strong>.<\/p>\n\n\n\n An RTOS allows for execution of multiple threads in a parallel fashion. <\/p>\n<\/blockquote>\n\n\n\n In ChibiOS\/RT, threads have the capability to spawn additional threads, and they can also terminate. There are a variety of synchronization mechanisms available to manage these events. Returning to our arrow analogy, we might envision a multithreaded application as follows:<\/p>\n\n\n Here, the application consists of three threads: the main thread creates two additional threads, and all threads appear to operate independently of each other.<\/p>\n\n\n\n In ChibiOS\/RT, a thread comprises two essential components:<\/p>\n\n\n\n Upon creation, each thread is assigned a Priority level <\/strong>and it has access to shared variables located in RAM, external to any thread stack. Additionally, it can access hardware resources, including CPU registers and I\/O peripherals.<\/p>\n\n\n It’s important to distinguish between the Thread Function and the thread itself. The Thread Function merely defines the thread’s behavior. This distinction is evident from our exploration in the article Parametric Threads with ChibiOS<\/a>, where we demonstrated the ability to instantiate multiple threads from the same Thread Function, each utilizing separate working areas.<\/p>\n\n\n\n ChibiOS\/RT primarily supports two types of threads:<\/p>\n\n\n\n While static threads are generally favored to prevent memory fragmentation<\/a>, there are cases where dynamic allocation is necessary. ChibiOS\/RT includes a comprehensive API to support dynamic thread allocation.<\/p>\n\n\n\n Consider the following code snippet, which illustrates how to allocate a new static working area for a thread with 128 bytes of usable space, referred to as For readers already experienced with building applications using ChibiOS, this API will be familiar. It is assumed that you are reading this article to deepen your understanding of the scheduling dynamics. If you require a refresher, however, I recommend revisiting the section What is a Thread?<\/a> from Mastering multithreading with ChibiOS: a beginner’s guide<\/a>.<\/p>\n\n\n\n In ChibiOS\/RT, the The Another notable characteristic of the The The In this scenario, the Here is an illustration of a simple multithreading application in ChibiOS\/RT, which comprises the In this example, placeholders indicate where to insert initialization and routine task code for each thread. It’s noteworthy that Microcontrollers often have single-core CPUs, yet they can run multiple code sequences seemingly in parallel. How is this possible? The key is the word “seemingly”. In reality, at any instant, only one thread actually runs. The job of the ChibiOS\/RT is to rapidly and efficiently allocate CPU time among the threads, creating the illusion of concurrent execution.<\/p>\n\n\n\n The answer to our question posed at the beginning of this chapter is Context Switching<\/strong>. This involves temporarily stopping one thread and starting another. To grasp this concept, let us consider the following code<\/p>\n\n\n\n Focusing on the instruction within the while loop, if we translate it into assembly for an ARM Cortex-M architecture, it would look like this:<\/p>\n\n\n\n This example demonstrates how the CPU employs its General-Purpose registers<\/strong> for operations, specifically R0 and R1 in this case. Alongside these, Special-Purpose registers<\/strong> are critical for code execution. Among those:<\/p>\n\n\n\n Like those, other Special Purpose registers are involved, directly or indirectly, in the code execution. Which brings us to the next statement<\/p>\n\n\n\n The values contained in the CPU (Special-Purpose and General-Purpose) registers represent the context of a thread or process that is currently being executed by the CPU.<\/p>\n<\/blockquote>\n\n\n\n So, let’s define the Current Execution Context<\/strong> (or simply Context<\/strong>) as the combined value of several CPU registers. It is important to notice that the registers which are crucial to the Context depends on the architecture in use: as example, In the ARM Cortex-M architecture, during a context switch, it is not typically necessary to manually save the contents of registers R0 to R3. This is because these registers are used as argument and return value registers and are not expected to be preserved across function calls. They are considered “scratch” registers or volatile registers. Additionally, if the MCU is equipped with a Floating Point Unit<\/strong> (FPU<\/strong>) – a dedicated hardware unit designed for floating-point calculations – the context saved during a switch will also include the registers of the FPU.<\/p>\n\n\n\n The context switch is essentially the act of saving the current thread’s context into memory and loading the context of the next thread. This allows the next thread to resume exactly where it left off during its last suspension, ensuring seamless task switching. <\/p>\n\n\n Equipped with this comprehensive set of new insights, we can now update our depiction of a multi-threaded application to be more accurate and realistic.<\/p>\n\n\n But were exactly is the context saved? In ChibiOS\/RT, when we define a static working area using the However, the actual memory allocated is larger than the specified size. This is because ChibiOS\/RT’s API automatically includes extra space for the In general, a thread can occupy one of three primary states. Although ChibiOS offers a more complex state system, for our current discussion, the following simplifications are sufficient:<\/p>\n\n\n\n In a single-core application, only one thread can be in the ‘current’ state at any given time, actively utilizing the CPU. The user can employ APIs to transition a thread’s state to ‘Ready’ or ‘Suspended’. Additionally, the scheduler is equipped to automatically transition a thread to ‘Ready’ when specific conditions are fulfilled. Common triggers for such transitions include:<\/p>\n\n\n\n In ChibiOS\/RT, the thread state model is indeed more nuanced, encompassing a broader spectrum of states:<\/p>\n\n\n\n The above definitions expand upon our initial overview. Here’s how they correspond:<\/p>\n\n\n\n The remaining states are variations of suspension, each with different conditions for reactivation. Of particular note are:<\/p>\n\n\n\n Understanding the sequence in which threads operate allows us to grasp the necessity of the The time spent in the ChibiOS\/RT is a Real Time Operating System and as such it needs to possess certain characteristics. Indeed an RTOS stands out due to its ability to efficiently process data and respond to inputs within a guaranteed timeframe, often referred to as a deadline<\/strong>. The crucial aspect here is the assurance of response within this timeframe, stemming from the first most important characteristic of an RTOS: determinism<\/strong><\/strong>. In deterministic systems, like in mathematics, there is no randomness. Determinism leads to two outcomes:<\/p>\n\n\n\n While determinism is what makes an OS Real Time capable, however the goodness of an RTOS falls on low latency<\/strong> or, in other words, the shortest deadline it can reliably meet. ChibiOS\/RT achieves low latency with a fully-preemptive priority scheduling<\/strong> where each thread is assigned a priority and the order of execution is influenced by it. <\/p>\n\n\n\n In ChibiOS\/RT each thread is assigned a Priority<\/strong>: this determines the order in which threads are executed, with higher priority threads being attended to first. Whenever a Thread at higher priority becomes ready, the current one is immediately suspended: this process, known as Preemption<\/strong>, ensures that higher priority threads are served with low latency.<\/p>\n\n\n\n It is important to notice that here is that, in ChibiOS\/RT, priorities are specific numbers:<\/p>\n\n\n\n The We’ve learned about threads, but what happens to them when an interrupt occurs? For instance, if a thread is put to sleep, what wakes it up?<\/p>\n\n\n\n Interrupt Requests can interrupt even the highest-priority thread. Imagine Interrupt Service Routines (ISRs) running at a priority above the operating system itself. Therefore, ISRs should not have blocking functions, as this can cause delays, making our application not real-time. In fact, ISRs capture events that are frequently used to reschedule and determine which thread will run next. A common example is the IRQ generated by a timer when a thread is put to sleep for a specific amount of time.<\/p>\n\n\n However, there are times when we don’t want interrupts to preempt critical code sections. In ChibiOS\/RT, we can prevent this by using “critical zones.” We can protect code areas from IRQs and other threads using specific APIs. For example, the code below can be used in any thread to create a critical zone:<\/p>\n\n\n\n This code needs to be used carefully as it can introduce latency on higher priority thread or ISRs. Similarly, we can create a critical zone in ISR context with this API:<\/p>\n\n\n\n So, who manages the ISRs in ChibiOS applications? ChibiOS\/RT does. The RTOS provides an API for handling ISRs. ChibiOS\/HAL uses this API to build device drivers that work efficiently with threads.<\/p>\n\n\n\n To achieve precise deadlines, an RTOS utilizes a hardware timer for scheduling. ChibiOS\/RT follows this approach, typically assigning one of the high-resolution timers to a special peripheral exclusively for the Scheduler, known as the System Tick (ST). The assignment of this timer is configured in the Three additional important configurations are set in Traditional RTOS designs use a tick-based approach, where the system clock generates periodic interrupts (ticks) for task scheduling. With the above configuration ( In tick-less mode, ChibiOS\/RT forgoes the need for periodic tick interrupts for scheduling. Instead, the RTOS reconfigures the timer to generate interrupts only at task deadlines, thus avoiding superfluous IRQs. Rather than waking up at regular intervals to check for needed context switches (as in traditional mode), the system in tickless mode wakes only when necessary to perform a task. This mode is especially beneficial for low-power applications or in situations where minimizing power consumption is crucial.<\/p>\n\n\n\n ChibiOS provides various APIs that are crucial for thread management. Among these are specific APIs identified as blocking from the perspective of the calling thread. These APIs are designed to implicitly suspend the calling thread, and plan ahead to resume the thread at a subsequent moment when certain conditions are met. To aid our upcoming discussion, we will list and explain some of these APIs, focusing on their impact on the calling thread.<\/p>\n\n\n\n These APIs are preferred for simple applications, as they suspend a Thread for a specific time. They are essentially redefinitions of the These functions set an alarm using a hardware timer and suspend the calling thread. When the alarm expires, it triggers an IRQ, and ChibiOS\/RT adds the thread back to the ready list. If it’s the highest-priority thread, it resumes immediately. ChibiOS\/RT uses a hardware timer for accurate scheduling. The state of the calling thread is set to ChibiOS\/HAL<\/strong> is a crucial part of the ChibiOS project, consisting of a set of device drivers carefully crafted to offer a consistent API across various platforms. Its primary goal is to empower application developers by allowing them to design applications that are mostly independent of the specific hardware they run on. One notable feature of HAL is that is is perfectly coupled with ChibiOS\/RT offering a thread ready API.<\/p>\n\n\n\n When a peripheral is enabled, HAL takes over the ISR handling from RT. HAL provides a set of APIs for each driver, known to be blocking. Examples of these APIs include:<\/p>\n\n\n\n These APIs usually utilize Direct Memory Access for transactions, depending on the low-level driver implementation. When called, the API configures the DMA for the transaction and suspends the calling thread. The DMA’s Interrupt Service Routine (ISR) is intercepted by ChibiOS\/HAL which calls some RT API to wake up the original thread.<\/p>\n\n\n\n ChibiOS\/RT provides an event API which we’ll delve into more in a future article. This event engine offers an API for waiting on single or multiple events using OR or AND logic.<\/p>\n\n\n\n When a thread calls any of these APIs, it is suspended until the required combination of events is signaled from another part of the code (either thread or ISR). This causes the suspended thread to join the ready list. Depending on the API function used, the state of the calling thread is set to either Threads and multithreading<\/h2>\n\n\n\n
Multithreading 101<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/playembedded.org\/wp-content\/uploads\/2024\/01\/Single-thread-application-PE.png\")
\n
![\"\"](\"https:\/\/playembedded.org\/wp-content\/uploads\/2024\/01\/Multithread-application-PE.png\")
What is actually a thread in ChibiOS\/RT?<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/playembedded.org\/wp-content\/uploads\/2023\/04\/Thread-block-diagram-PE-1024x845.png\")
\n
waThread1<\/code>. It also defines a Thread Function named Thread1<\/code> and, in the main<\/code> function, it creates and starts the thread:<\/p>\n\n\n\nstatic THD_WORKING_AREA(waThread1, 128);\nstatic THD_FUNCTION(Thread1, arg) {\n\n \/* One-time setup for Thread1. *\/\n \/\/ Your one-time code here\n\n while (true) {\n \n \/* Periodic task for Thread1. *\/\n \/\/ Your periodic action code here\n\n chThdSleepMilliseconds(100);\n }\n}\n\nint main(void) {\n \n ...\n chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO + 1, Thread1, NULL);\n ...\n}<\/pre>\n\n\n\nConsideration about the main and idle thread<\/h3>\n\n\n\n
main<\/code> function is not just the entry point of the user application; it is also a thread, a special one at that. It initializes the scheduler by calling chSysInit()<\/code>. When this occurs, the following actions are taken:<\/p>\n\n\n\n\n
main<\/code> is registered as a thread with the priority NORMALPRIO<\/code>.<\/li>\n\n\n\nidle<\/code> thread, is created and added to the scheduling list.<\/li>\n<\/ul>\n\n\n\nmain<\/code> thread holds a unique status within ChibiOS\/RT as it is the initial thread, both in declaration and in execution. As the entry point, it not only kicks off the scheduler but also has the primary responsibility of spawning the first set of additional threads. From there, these newly created threads have the ability to create further threads, forming a branching hierarchy of operations, all tracing back to the main<\/code> thread. This lineage emphasizes the main<\/code> thread’s pivotal role in the life cycle of the application’s multithreading process.<\/p>\n\n\n\nmain<\/code> thread is the way its Thread Stack is handled. Unlike other threads, whose stacks are explicitly declared within the C files, the main<\/code> stack is implied in the project’s makefile, as shown below:<\/p>\n\n\n\n# Stack size to be allocated to the Cortex-M process stack. This stack is\n# the stack used by the main() thread.\nifeq ($(USE_PROCESS_STACKSIZE),)\n USE_PROCESS_STACKSIZE = 0x400\nendif<\/pre>\n\n\n\n
idle<\/code> thread is active by default and operates at IDLEPRIO<\/code>, the lowest priority level in ChibiOS\/RT. To maintain system efficiency, no other thread should share this priority. The idle<\/code> thread is executed when no other threads are running. ChibiOS provides hooks to execute code upon entering and exiting the idle<\/code> thread, allowing for operations such as disabling peripherals and reconfiguring the clock for low power consumption, though this comes at the cost of increased latency.<\/p>\n\n\n\nidle <\/code>thread can be disabled by modifying the configuration in chconf<\/code>:<\/p>\n\n\n\n\/**\n * @brief Idle thread automatic spawn suppression.\n * @details When this option is activated the function @p chSysInit()\n * does not spawn the idle thread. The application @p main()\n * function becomes the idle thread and must implement an\n * infinite loop.\n *\/\n#if !defined(CH_CFG_NO_IDLE_THREAD)\n#define CH_CFG_NO_IDLE_THREAD FALSE\n#endif<\/pre>\n\n\n\n
main<\/code> function takes on the role of the idle<\/code> thread, and its execution loop should be left empty.<\/p>\n\n\n\nExample of a multithreading application<\/h3>\n\n\n\n
main<\/code> thread and an additional useful thread named Thread1<\/code>, aside from the idle<\/code> thread.<\/p>\n\n\n\n\/*\n * Thread1 related declarations\n *\/\nstatic THD_WORKING_AREA(waThread1, 128);\nstatic THD_FUNCTION(Thread1, arg) {\n\n \/* One-time setup for Thread1. *\/\n \/\/ Your one-time code here\n\n while (true) {\n \n \/* Periodic task for Thread1. *\/\n \/\/ Your periodic action code here\n\n chThdSleepMilliseconds(100);\n }\n}\n\n\/*\n * Main thread related declarations\n *\/\nint main(void) {\n \n \/* Initial setup for the system. *\/\n halInit();\n chSysInit();\n\n \/* Starting Thread1. *\/\n chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO + 1, Thread1, NULL);\n\n \/* One-time setup for main. *\/\n \/\/ Your one-time code here\n\n while (true) {\n \n \/* Periodic task for main. *\/\n \/\/ Your periodic action code here\n\n chThdSleepMilliseconds(150);\n }\n}<\/pre>\n\n\n\nThread1<\/code> and the main<\/code> thread are assigned different priorities and operate at varying frequencies due to their respective sleep durations. A timing analysis of this setup will be conducted later to examine how these factors influence the scheduling.<\/p>\n\n\n\nHow can multithread happen?<\/h2>\n\n\n\n
Context-switch: the magic behind multithreading<\/h3>\n\n\n\n
function void increase(int* p) {\n int tmp = *p;\n tmp++;\n *p = tmp;\n}\n\nint main(void) {\n int a = 0;\n \n while(1) {\n increase(&a);\n }\n}<\/pre>\n\n\n\n; Function: increase\nincrease:\n PUSH {LR} ; Push the return address onto the stack\n LDR R1, [R0] ; Load the value of 'a' from the address in R0 into R1\n MOV R2, R1 ; Move the value of R1 (a) into R2 (tmp)\n ADD R2, R2, #1 ; Increment the value in R2 (tmp)\n STR R2, [R0] ; Store the incremented value in R2 (tmp) back at the address in R0\n POP {LR} ; Pop the return address off the stack\n BX LR ; Return from the subroutine\n\n; Main function loop\nmain:\n LDR R0, =a ; Load the address of 'a' into R0\nloop:\n BL increase ; Call the increase function\n B loop ; Infinite loop back to itself<\/pre>\n\n\n\n\n
BL increase<\/code>” causes the PC to jump to the first instruction of the “increase<\/code>” function, rather than following a linear execution path.<\/li>\n\n\n\ntmp<\/code>, is created, the SP adjusts to allocate space for it on the stack, pointing to the next available memory slot.<\/li>\n\n\n\nincrease<\/code> is called via BL increase<\/code>, LR<\/code> stores the return address. After increase<\/code> completes, LR<\/code> is used to return to the instruction following the call in the main function, ensuring a smooth continuation of the program flow.<\/li>\n<\/ol>\n\n\n\n\n
![\"\"](\"https:\/\/playembedded.org\/wp-content\/uploads\/2024\/01\/Context-Switch-PE.png\")
![\"\"](\"https:\/\/playembedded.org\/wp-content\/uploads\/2024\/01\/Multithread-application-realityPE.png\")
THD_WORKING_AREA<\/code> API, we provide two parameters: a name and a pointer to the working area, and the size in bytes for the thread’s use, mainly for automatic variables and stack frames.<\/p>\n\n\n\nstatic THD_WORKING_AREA(waThread1, 128);<\/pre>\n\n\n\n
ch_thread<\/code> structure. This structure holds all the thread’s pertinent information, including its current state but also ample space to save the thread’s context during suspension: this explains why exactly each thread need his own working area.<\/p>\n\n\n\nThread states<\/h3>\n\n\n\n
\n
\n
\/**\n * @name Thread states\n * @{\n *\/\n#define CH_STATE_READY (tstate_t)0 \/**< @brief Waiting on the ready list. *\/\n#define CH_STATE_CURRENT (tstate_t)1 \/**< @brief Currently running. *\/\n#define CH_STATE_WTSTART (tstate_t)2 \/**< @brief Just created. *\/\n#define CH_STATE_SUSPENDED (tstate_t)3 \/**< @brief Suspended state. *\/\n#define CH_STATE_QUEUED (tstate_t)4 \/**< @brief On a queue. *\/\n#define CH_STATE_WTSEM (tstate_t)5 \/**< @brief On a semaphore. *\/\n#define CH_STATE_WTMTX (tstate_t)6 \/**< @brief On a mutex. *\/\n#define CH_STATE_WTCOND (tstate_t)7 \/**< @brief On a cond.variable. *\/\n#define CH_STATE_SLEEPING (tstate_t)8 \/**< @brief Sleeping. *\/\n#define CH_STATE_WTEXIT (tstate_t)9 \/**< @brief Waiting a thread. *\/\n#define CH_STATE_WTOREVT (tstate_t)10 \/**< @brief One event. *\/\n#define CH_STATE_WTANDEVT (tstate_t)11 \/**< @brief Several events. *\/\n#define CH_STATE_SNDMSGQ (tstate_t)12 \/**< @brief Sending a message,in queue. *\/\n#define CH_STATE_SNDMSG (tstate_t)13 \/**< @brief Sent a message, waiting answer. *\/\n#define CH_STATE_WTMSG (tstate_t)14 \/**< @brief Waiting for a message. *\/\n#define CH_STATE_FINAL (tstate_t)15 \/**< @brief Thread terminated. *\/\n\/** @} *\/<\/pre>\n\n\n\n\n
CH_STATE_READY<\/code> and CH_STATE_CURRENT<\/code> align with the ready<\/strong> and current <\/strong>states in our simplified model.<\/li>\n\n\n\nCH_STATE_WTSTART<\/code> is the initial state of a new thread that is waiting to be added to the schedule, which you can achieve using chThdCreateSuspended()<\/code>.<\/li>\n\n\n\nCH_STATE_FINAL<\/code> represents a thread that has terminated.<\/li>\n<\/ul>\n\n\n\n\n
CH_STATE_SUSPENDED<\/code>: A general suspension state, entered by invoking chThdSuspend()<\/code> on a thread.<\/li>\n\n\n\nCH_STATE_SLEEPING<\/code>: Indicative of a thread that is temporarily inactive but scheduled to wake after a set period, typically initiated by calling one of the chThdSleep()<\/code> and derived functions.<\/li>\n<\/ul>\n\n\n\nThe reason behind idle<\/h3>\n\n\n\n
idle<\/code> thread. Consider a situation where all user threads are in a suspended state, each awaiting an event to proceed. In such instances, the CPU has no immediate tasks to perform, which is where the idle<\/code> thread comes into play. It acts as a standby process, essentially filling the gap in CPU activity by executing a low-priority task that yields to any other thread as soon as it becomes ready.<\/p>\n\n\n\nidle<\/code> thread is indicative of the CPU’s inactivity. By measuring the duration the CPU remains in this state within a specific time frame, we can determine the idle<\/code> time percentage. This figure is a useful indicator of the application’s CPU usage efficiency. If the idle<\/code> thread is active for a large portion of time, it suggests that the CPU has a considerable amount of untapped processing capacity, which could mean the application is not demanding or that the system is highly efficient.<\/p>\n\n\n\nAbsolving to Real Time applications<\/h2>\n\n\n\n
Determinism: repeatability and predictability<\/h3>\n\n\n\n
\n
Low latency: preemptiveness and priorities<\/h3>\n\n\n\n
\/**\n * @name Priority constants\n * @{\n *\/\n#define NOPRIO (tprio_t)0 \/**< @brief Ready list header priority. *\/\n#define IDLEPRIO (tprio_t)1 \/**< @brief Idle priority. *\/\n#define LOWPRIO (tprio_t)2 \/**< @brief Lowest priority. *\/\n#define NORMALPRIO (tprio_t)128 \/**< @brief Normal priority. *\/\n#define HIGHPRIO (tprio_t)255 \/**< @brief Highest priority. *\/\n\/** @} *\/<\/pre>\n\n\n\nidle<\/code> thread is the only one set at IDLEPRIO<\/code>. The main thread is automatically set at NORMALPRIO<\/code> unless it acts as the idle<\/code> thread. Thread priorities are relative, not absolute. For example, in a two-thread application with main<\/code> and Thread1<\/code>, Thread1<\/code>‘ priority being NORMALPRIO + 1<\/code> or NORMALPRIO + 10<\/code> will not affect the order of execution. The only thing that matters is that Thread1<\/code>‘ priority is higher than main<\/code>‘s.<\/p>\n\n\n\nInterrupt Requests and Critical Zones<\/h3>\n\n\n\n
![\"\"](\"https:\/\/playembedded.org\/wp-content\/uploads\/2023\/04\/Multithread-ISRPE.png\")
chSysLock(void);\n\/* Your critical zone in thread context here. *\/\nchSysUnlock(void);<\/pre>\n\n\n\n
chSysLockFromISR(void);\n\/* Your critical zone in ISR context here. *\/\nchSysUnlockFromISR(void);<\/pre>\n\n\n\n
System tick and tick-less mode<\/h3>\n\n\n\n
mcuconf.h<\/code> file:<\/p>\n\n\n\n\/*\n * ST driver system settings.\n *\/\n#define STM32_ST_IRQ_PRIORITY 8\n#define STM32_ST_USE_TIMER 2<\/pre>\n\n\n\n
chconf.h<\/code>:<\/p>\n\n\n\n\n
CH_CFG_ST_RESOLUTION<\/strong><\/code>: Defines the precision of the hardware timer used. A high-precision timer is recommended for more accurate time measurement and better control over task scheduling and delays, improving system efficiency and responsiveness.<\/li>\n\n\n\nCH_CFG_ST_FREQUENCY<\/strong><\/code>: Determines the system tick frequency. In tick mode, this sets frequency of interrupt requests generated by the timer. This setting also defines the smallest time unit the RTOS can manage.<\/li>\n\n\n\nCH_CFG_ST_TIMEDELTA<\/strong><\/code>: Indicates whether the system operates in traditional or tick-less mode. A value of 0 means traditional mode; a value of 2 or higher means tick-less mode and sets the minimum safe number of ticks for timeout directives.<\/li>\n<\/ul>\n\n\n\n\/**\n * @brief System time counter resolution.\n * @note Allowed values are 16, 32 or 64 bits.\n *\/\n#if !defined(CH_CFG_ST_RESOLUTION)\n#define CH_CFG_ST_RESOLUTION 32\n#endif\n\n\/**\n * @brief System tick frequency.\n * @details Frequency of the system timer that drives the system ticks. This\n * setting also defines the system tick time unit.\n *\/\n#if !defined(CH_CFG_ST_FREQUENCY)\n#define CH_CFG_ST_FREQUENCY 10000\n#endif\n\n\/**\n * @brief Time delta constant for the tick-less mode.\n * @note If this value is zero then the system uses the classic\n * periodic tick. This value represents the minimum number\n * of ticks that is safe to specify in a timeout directive.\n * The value one is not valid, timeouts are rounded up to\n * this value.\n *\/\n#if !defined(CH_CFG_ST_TIMEDELTA)\n#define CH_CFG_ST_TIMEDELTA 2\n#endif<\/pre>\n\n\n\n
CH_CFG_ST_FREQUENCY <\/code>equal to 10000), this interrupt would occur every 100µs. However, ChibiOS\/RT also offers a tick-less mode<\/strong>.<\/p>\n\n\n![\"\"](\"https:\/\/playembedded.org\/wp-content\/uploads\/2024\/01\/Tick-vs-Tickless-mode.png\")
Blocking APIs<\/h3>\n\n\n\n
Sleep functions<\/h4>\n\n\n\n
chThdSleep()<\/code>: while this function accepts an integer representing the system tick clock value these redefinitions specify delays in second, milliseconds or microseconds.<\/p>\n\n\n\n\/** Delays thread for specified seconds, considering system tick clock and value limits. *\/\n#define chThdSleepSeconds(sec) chThdSleep(TIME_S2I(sec))\n\n\/** Delays thread for specified milliseconds, considering system tick clock and value limits. *\/\n#define chThdSleepMilliseconds(msec) chThdSleep(TIME_MS2I(msec))\n\n\/** Delays thread for specified microseconds, considering system tick clock and value limits. *\/\n#define chThdSleepMicroseconds(usec) chThdSleep(TIME_US2I(usec))\n<\/pre>\n\n\n\n
CH_STATE_SLEEPING<\/code> when suspended.<\/p>\n\n\n\nChibiOS\/HAL blocking API<\/h4>\n\n\n\n
\/**\n * SPI Full Duplex Transfer\n * Performs a full duplex SPI transfer, blocking until operation is complete.\n *\/\nvoid spiExchange(SPIDriver *spip, size_t n, const void *txbuf, void *rxbuf);\n\n\/**\n * I2C Master Transmit\n * Transmits data as an I2C master, blocks until completion.\n *\/\nmsg_t i2cMasterTransmit(I2CDriver *i2cp, i2caddr_t addr, const uint8_t *txbuf, size_t txbytes, uint8_t *rxbuf, size_t rxbytes);\n\n\/**\n * ADC Conversion\n * Performs an ADC conversion, blocking until the conversion is completed.\n *\/\nmsg_t adcConvert(ADCDriver *adcp, const ADCConversionGroup *grpp, adcsample_t *samples, size_t depth);\n\n\/**\n * DAC Conversion\n * Performs a DAC conversion, blocking until the conversion is completed.\n *\/\nmsg_t dacConvert(DACDriver *dacp, const DACConversionGroup *grpp, dacsample_t *samples, size_t depth);\n\n\/**\n * USB Data Transmit\n * Transmits data over USB, blocks until the operation is complete.\n *\/\nsize_t usbTransmit(USBDriver *usbp, usbep_t ep, const uint8_t *buf, size_t n);\n\n\/**\n * USB Data Receive\n * Receives data over USB, blocks until data is received.\n *\/\nsize_t usbReceive(USBDriver *usbp, usbep_t ep, uint8_t *buf, size_t n);\n<\/pre>\n\n\n\n
Event API<\/h4>\n\n\n\n
\/** Blocks until any one of the specified events occurs. *\/\neventmask_t chEvtWaitOne(eventmask_t events);\n\n\/** Blocks until one or more of the specified events occur. *\/\neventmask_t chEvtWaitAny(eventmask_t events);\n\n\/** Blocks until all of the specified events occur. *\/\neventmask_t chEvtWaitAll(eventmask_t events);\n<\/pre>\n\n\n\n
CH_STATE_WTOREVT<\/code> or CH_STATE_WTALLEVT<\/code>.<\/p>\n\n\n\nMutex API<\/h4>\n\n\n\n