2. 程式人生 > >FreeRTOS（20）---FreeRTOS 任務通知分析

FreeRTOS（20）---FreeRTOS 任務通知分析

阿新 • • 發佈：2019-01-02

FreeRTOS 任務通知分析

FreeRTOS 任務通知分析

在FreeRTOS版本V8.2.0中推出了全新的功能：任務通知。在大多數情況下，任務通知可以替代二進位制訊號量、計數訊號量、事件組，可以替代長度為1的佇列（可以儲存一個32位整數或指標值），並且任務通知速度更快、使用的RAM更少！我在

《 FreeRTOS（８）—FreeRTOS 任務通知》一文中介紹了任務通知如何使用以及侷限性，今天我們將分析任務通知的實現原始碼，看一下任務通知是如何做到效率與RAM消耗雙贏的。

在《FreeRTOS（18）—FreeRTOS 訊號量分析》一文中我們已經知道，FreeRTOS的訊號量是使用佇列機制實現的，資料結構也完全是佇列的那一套。而任務通知則不同，它的資料結構嵌在任務TCB（任務控制塊，見《FreeRTOS（14）—FreeRTOS 任務建立分析》）中的，並且資料結構十分簡單，涉及到任務TCB的兩個欄位，我們將它單獨列出來：

volatile uint32_t ulNotifiedValue; 	/*任務通知值*/  
volatile uint8_t ucNotifyState;	/*任務通知狀態，標識任務是否在等待通知等*/

這兩個欄位佔用5位元組RAM（本文都是在32位系統下討論），而一個佇列資料結構至少佔用76位元組RAM！這不是同一數量級的，所以任務通知在RAM消耗上完勝。

在分析佇列和訊號量的文章中，我們知道在使用佇列、訊號量前，必須先建立佇列和訊號量，目的是為了建立佇列資料結構。比如使用API函式xQueueCreate()建立佇列，用API函式xSemaphoreCreateBinary()建立二進位制訊號量等等。再來看任務通知，由於任務通知的資料結構包含在任務TCB中，只要任務存在，任務通知資料結構就已經建立完畢，可以直接使用！在易用性上，任務通知再次獲勝。

要想了解任務通知在效能上佔優的原因，就要分析原始碼了。

只有任務可以等待通知，中斷服務函式中不可以。如果等待的通知無效，任務會進入阻塞狀態，我們可以將等待通知的任務看作是消費者；其它任務和中斷可以向等待通知的任務傳送通知，傳送通知的任務和中斷服務函式可以認為是生產者。處於阻塞的消費者得到通知後會再次進入就緒態。

任務通知API函式主要有兩類，一類傳送通知，一類等待通知。傳送通知API函式可以用於任務和中斷服務函式，等待通知API函式只能用在任務中。

傳送通知

我們先看一下發送通知API函式。這類函式比較多，有6個。但仔細分析會發現它們只能完成3種操作，每種操作有兩個API函式，分別為帶中斷保護版本和不帶中斷保護版本。FreeRTOS將API細分為帶中斷保護版本和不帶中斷保護版本是為了節省中斷服務程式處理時間，提升效能。

和訊號量類似，大多數傳送通知API介面也是由巨集實現的，如表1-1所示。

表1-1：傳送通知API函式與實際呼叫函式列表

在這裡插入圖片描述

xTaskGenericNotify()

不帶中斷保護的傳送通知API函式實際都是呼叫函式xTaskGenericNotify()實現的，我們看一下這個函式原型：

BaseType_t xTaskGenericNotify( 
        TaskHandle_t xTaskToNotify, 
        uint32_t ulValue, 
        eNotifyAction eAction, 
        uint32_t *pulPreviousNotificationValue )
  • xTaskToNotify：被通知的任務控制代碼。
  • ulValue：更新的通知值
  • eAction：列舉型別，指明更新通知值的方法，列舉變數成員以及作用見表1-2所示。
  • pulPreviousNotifyValue：回傳未被更新的任務通知值。如果不需要回傳未被更新的任務通知值，這裡設定為NULL。

表1-2：eNotifyAction列舉成員以及作用
在這裡插入圖片描述
與入隊操作相比較，傳送通知API函式顯得非常簡單，整理後的原始碼如下所示：

BaseType_t xTaskGenericNotify( TaskHandle_t xTaskToNotify, uint32_t ulValue, eNotifyAction eAction, uint32_t *pulPreviousNotificationValue )
{
TCB_t * pxTCB;
BaseType_t xReturn = pdPASS;
uint8_t ucOriginalNotifyState;


    configASSERT( xTaskToNotify );
    pxTCB = ( TCB_t * ) xTaskToNotify;


    taskENTER_CRITICAL();
    {
        if( pulPreviousNotificationValue != NULL )
        {
			/* 回傳更新前的通知值*/
            *pulPreviousNotificationValue = pxTCB->ulNotifiedValue;
        }


        ucOriginalNotifyState = pxTCB->ucNotifyState;


        pxTCB->ucNotifyState = taskNOTIFICATION_RECEIVED;


        switch( eAction )
        {
            case eSetBits   :
                pxTCB->ulNotifiedValue |= ulValue;
                break;


            case eIncrement :
                ( pxTCB->ulNotifiedValue )++;
                break;


            case eSetValueWithOverwrite :
                pxTCB->ulNotifiedValue = ulValue;
                break;


            case eSetValueWithoutOverwrite :
                if( ucOriginalNotifyState != taskNOTIFICATION_RECEIVED )
                {
                    pxTCB->ulNotifiedValue = ulValue;
                }
                else
                {
                    /* 上次的通知值還未取走,本次通知值丟棄 */
                    xReturn = pdFAIL;
                }
                break;


            case eNoAction:
                /* 不需要更新通知值*/
                break;
        }


        traceTASK_NOTIFY();


        /* 如果被通知的任務因為等待通知而阻塞,現在將它解除阻塞 */
        if( ucOriginalNotifyState == taskWAITING_NOTIFICATION )
        {
            ( void ) uxListRemove( &( pxTCB->xStateListItem ) );
            prvAddTaskToReadyList( pxTCB );


            if( pxTCB->uxPriority > pxCurrentTCB->uxPriority )
            {
                /* 如果被通知的任務優先順序高於當前任務,則觸發PendSV中斷,退出臨界區後進行上下文切換T*/
                taskYIELD_IF_USING_PREEMPTION();
            }
        }
    }
    taskEXIT_CRITICAL();


    return xReturn;
}

函式的功能可以概括為：按照指定的方法更新通知值，如果被通知的任務處於阻塞狀態，則將它解除阻塞，解除阻塞任務的優先順序如果大於當前任務的優先順序，則觸發一次任務切換。

與釋放訊號量API函式相比，本函式少了很多呼叫子函式開銷、少了很多判斷、少了對事件列表的操作等等，確實是比釋放訊號量的實現要簡潔的多。這也是有原因的，因為任務通知有它自己的侷限性，並不能完全代替訊號量。比如一個任務只能阻塞到一個通知上，如想要實現多個任務阻塞到同一個事件上，只能使用訊號量了。也正是因為這種侷限性，使得任務通知實現起來簡單高效，並且大多數情況下，任務通知的方法就已經能解決問題了。

vTaskNotifyGiveFromISR()

這個API函式是vTaskNotifyGive()的帶中斷保護版本，是專門設計用來在某些情況下代替二進位制訊號量和計數訊號量的。函式也很簡單，我們直接看原始碼，原始碼經過整理和註釋，以方便理解。

void vTaskNotifyGiveFromISR( TaskHandle_t xTaskToNotify, BaseType_t *pxHigherPriorityTaskWoken )
{
TCB_t * pxTCB;
uint8_t ucOriginalNotifyState;
UBaseType_t uxSavedInterruptStatus;


    pxTCB = ( TCB_t * ) xTaskToNotify;


    uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();
    {
        ucOriginalNotifyState = pxTCB->ucNotifyState;
        pxTCB->ucNotifyState = taskNOTIFICATION_RECEIVED;


        /* 通知值加1,相當於釋放了一個訊號量 */
        ( pxTCB->ulNotifiedValue )++;


        /* 如果目標任務因為等待通知而阻塞,現在將它解除阻塞*/
        if( ucOriginalNotifyState == taskWAITING_NOTIFICATION )
        {
            /* 如果排程器正常,將任務放入就緒列表,否則放入掛起就緒列表 */
            if( uxSchedulerSuspended == ( UBaseType_t ) pdFALSE )
            {
                ( void ) uxListRemove( &( pxTCB->xStateListItem ) );
                prvAddTaskToReadyList( pxTCB );
            }
            else
            {
                vListInsertEnd( &( xPendingReadyList ), &( pxTCB->xEventListItem ) );
            }


            if( pxTCB->uxPriority > pxCurrentTCB->uxPriority )
            {
                /* 如果解除阻塞的任務優先順序大於當前任務優先順序,則設定上下文切換標識,等退出函式後手動切換上下文,或者在系統節拍中斷服務程式中自動切換上下文*/
                if( pxHigherPriorityTaskWoken != NULL )
                {
                    *pxHigherPriorityTaskWoken = pdTRUE;    /* 設定手動切換標誌 */
                }
                else
                {
                    xYieldPending = pdTRUE;                 /* 設定自動切換標誌 */
                }
            }
        }
    }
    portCLEAR_INTERRUPT_MASK_FROM_ISR( uxSavedInterruptStatus );
}

xTaskGenericNotifyFromISR()

如表1-1所示，帶中斷保護版本的API函式xTaskNotifyFromISR()和xTaskNotifyAndQueryFromISR()都是巨集定義，真正被呼叫的函式為xTaskGenericNotifyFromISR()。這個函式用於在中斷在中傳送通知，與不帶中斷保護的API函式xTaskGenericNotify()非常相似，只是增加了一些中斷保護措施，我們直接看原始碼。通用原始碼經過整理和註釋，以方便理解。

BaseType_t xTaskGenericNotifyFromISR( TaskHandle_t xTaskToNotify, uint32_t ulValue, eNotifyAction eAction, uint32_t *pulPreviousNotificationValue, BaseType_t *pxHigherPriorityTaskWoken )
{
TCB_t * pxTCB;
uint8_t ucOriginalNotifyState;
BaseType_t xReturn = pdPASS;
UBaseType_t uxSavedInterruptStatus;


    pxTCB = ( TCB_t * ) xTaskToNotify;


    uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();
    {
        if( pulPreviousNotificationValue != NULL )
        {
            /* 回傳更新前的通知值 */
            *pulPreviousNotificationValue = pxTCB->ulNotifiedValue;
        }


        ucOriginalNotifyState = pxTCB->ucNotifyState;
        pxTCB->ucNotifyState = taskNOTIFICATION_RECEIVED;
        
        /* 根據引數設定通知值 */
        switch( eAction )
        {
            case eSetBits   :
                pxTCB->ulNotifiedValue |= ulValue;
                break;


            case eIncrement :
                ( pxTCB->ulNotifiedValue )++;
                break;


            case eSetValueWithOverwrite :
                pxTCB->ulNotifiedValue = ulValue;
                break;


            case eSetValueWithoutOverwrite :
                if( ucOriginalNotifyState != taskNOTIFICATION_RECEIVED )
                {
                    pxTCB->ulNotifiedValue = ulValue;
                }
                else
                {
                    /* 上次的通知值還未取走,本次通知值丟棄 */
                    xReturn = pdFAIL;
                }
                break;


            case eNoAction :
                /* 不需要更新通知值*/
                break;
        }


        traceTASK_NOTIFY_FROM_ISR();


        /* 如果被通知的任務因為等待通知而阻塞,現在將它解除阻塞 */
        if( ucOriginalNotifyState == taskWAITING_NOTIFICATION )
        {   
            /* 如果排程器正常,將任務放入就緒列表,否則放入掛起就緒列表 */
            if( uxSchedulerSuspended == ( UBaseType_t ) pdFALSE )
            {
                ( void ) uxListRemove( &( pxTCB->xStateListItem ) );
                prvAddTaskToReadyList( pxTCB );
            }
            else
            {
                vListInsertEnd( &( xPendingReadyList ), &( pxTCB->xEventListItem ) );
            }


            if( pxTCB->uxPriority > pxCurrentTCB->uxPriority )
            {
                /* 如果解除阻塞的任務優先順序大於當前任務優先順序,則設定上下文切換標識,等退出函式後手動切換上下文,或者在系統節拍中斷服務程式中自動切換上下文*/
                if( pxHigherPriorityTaskWoken != NULL )
                {
                    *pxHigherPriorityTaskWoken = pdTRUE;    /* 設定手動切換標誌 */
                }
                else
                {
                    xYieldPending = pdTRUE;                 /* 設定自動切換標誌 */
                }
            }
        }
    }
    portCLEAR_INTERRUPT_MASK_FROM_ISR( uxSavedInterruptStatus );


    return xReturn;
}

等待通知

等待通知API函式只能用在任務中，沒有帶中斷保護版本，因此只有兩個API函式：ulTaskNotifyTake()和xTaskNotifyWait ()。前者是為代替二進位制訊號量和計數訊號量而專門設計的，它和傳送通知API函式xTaskNotifyGive()、vTaskNotifyGiveFromISR()配合使用；後者是全功能版的等待通知，可以根據不同的引數實現輕量級二進位制訊號量、計數訊號量、事件組和長度為1的佇列。

等待通知API函式都帶有最大阻塞時間引數，當任務因為等待通知而進入阻塞時，用來規定最大阻塞時間。

ulTaskNotifyTake()

這個API函式用於實現輕量級的二進位制訊號量和計數訊號量，原始碼如下所示。它有兩個引數，如果第一個引數xClearCountOnExit設定為pdFALSE，則用來實現二進位制訊號量，函式退出時將通知值清零；如果第一個引數設定為pdTRUE，則用來實現計數訊號量，函式退出時，將通知值減一。

uint32_t ulTaskNotifyTake( BaseType_t xClearCountOnExit, TickType_t xTicksToWait )
{
uint32_t ulReturn;


    taskENTER_CRITICAL();
    {
        /* 僅當通知值為0，才進行阻塞操作*/
        if( pxCurrentTCB->ulNotifiedValue == 0UL )
        {
            /* 設定標誌,表示當前任務等待一個通知*/
            pxCurrentTCB->ucNotifyState = taskWAITING_NOTIFICATION;


            if( xTicksToWait > ( TickType_t ) 0 )
            {   
                /* 將任務加入延時列表 */
                prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
                traceTASK_NOTIFY_TAKE_BLOCK();


                /* 觸發PendSV中斷,等到退出臨界區時立即執行任務切換 */
                portYIELD_WITHIN_API();
            }
        }
    }
    taskEXIT_CRITICAL();
    /* 到這裡說明其它任務或中斷向這個任務傳送了通知,或者任務阻塞超時,現在繼續處理*/
    taskENTER_CRITICAL();
    {
        traceTASK_NOTIFY_TAKE();
        ulReturn = pxCurrentTCB->ulNotifiedValue;   


        if( ulReturn != 0UL )
        {
            if( xClearCountOnExit != pdFALSE )
            {
                pxCurrentTCB->ulNotifiedValue = 0UL;
            }
            else
            {
                pxCurrentTCB->ulNotifiedValue = ulReturn - 1;
            }
        }
        /* 設定標誌,表示不需要等待通知 */
        pxCurrentTCB->ucNotifyState = taskNOT_WAITING_NOTIFICATION;
    }
    taskEXIT_CRITICAL();


    return ulReturn;    /* 如果返回值為0,說明是任務阻塞超時了 */
}

與獲取二進位制訊號量和獲取計數訊號量函式相比，本函式少了很多呼叫子函式開銷、少了很多判斷、少了事件列表處理、少了佇列上鎖與解鎖處理等等，因此本函式相對效率很高。

xTaskNotifyWait()

這個函式用於實現全功能版的等待通知，根據引數的不同，可以靈活的用於實現輕量級的佇列、二進位制訊號量、計數訊號量和事件組功能，函式原型為：

BaseType_t xTaskNotifyWait( uint32_tulBitsToClearOnEntry,
                     uint32_tulBitsToClearOnExit,
                     uint32_t*pulNotificationValue,
                     TickType_txTicksToWait );
  • ulBitsToClearOnEntry：在使用通知之前，先將任務的通知值與引數ulBitsToClearOnEntry的按位取反值按位與操作。設定引數ulBitsToClearOnEntry為0xFFFFFFFF(ULONG_MAX)，表示清零任務通知值。
  • ulBitsToClearOnExit：在函式xTaskNotifyWait()退出前，將任務的通知值與引數ulBitsToClearOnExit的按位取反值按位與操作。設定引數ulBitsToClearOnExit為0xFFFFFFFF(ULONG_MAX)，表示清零任務通知值。
  • pulNotificationValue：用於向外回傳任務的通知值。這個通知值在引數ulBitsToClearOnExit起作用前將通知值拷貝到*pulNotificationValue中。如果不需要返回任務的通知值，這裡設定成NULL。
  • xTicksToWait：因等待通知而進入阻塞狀態的最大時間。時間單位為系統節拍週期。巨集pdMS_TO_TICKS用於將指定的毫秒時間轉化為相應的系統節拍數。

這個函式的實現和ulTaskNotifyTake()有很多相通之處，我將整個流程以註釋形式置於原始碼中，原始碼如下所示：

BaseType_t xTaskNotifyWait( uint32_t ulBitsToClearOnEntry, uint32_t ulBitsToClearOnExit, uint32_t *pulNotificationValue, TickType_t xTicksToWait )
{
BaseType_t xReturn;


    taskENTER_CRITICAL();
    {
        /* 只有任務沒有等待通知，才會將任務阻塞 */
        if( pxCurrentTCB->ucNotifyState != taskNOTIFICATION_RECEIVED )
        {
            /* 使用任務通知值之前,先將引數ulBitsToClearOnEntryClear取反後與任務通知值位與.可以用這種方法在使用任務通知值之前,將通知值的某些或全部位清零 */
            pxCurrentTCB->ulNotifiedValue &= ~ulBitsToClearOnEntry;


            /* 設定任務狀態標識:等待通知 */
            pxCurrentTCB->ucNotifyState = taskWAITING_NOTIFICATION;


            if( xTicksToWait > ( TickType_t ) 0 )
            {
                /* 阻塞當前任務 */
                prvAddCurrentTaskToDelayedList( xTicksToWait, pdTRUE );
                traceTASK_NOTIFY_WAIT_BLOCK();


                /* 觸發PendSV中斷,等到退出臨界區後,執行任務切換 */
                portYIELD_WITHIN_API();
            }
        }
    }
    taskEXIT_CRITICAL();


    /* 到這裡說明其它任務或中斷向這個任務傳送了通知,或者任務阻塞超時,現在繼續處理*/
    taskENTER_CRITICAL();
    {
        traceTASK_NOTIFY_WAIT();


        if( pulNotificationValue != NULL )
        {
            /* 輸出當前通知值,通過指標引數傳遞*/
            *pulNotificationValue = pxCurrentTCB->ulNotifiedValue;
        }


        /* 判斷是否是因為任務阻塞超時 */
        if( pxCurrentTCB->ucNotifyState == taskWAITING_NOTIFICATION )
        {
            /* 沒有收到任務通知,是阻塞超時 */
            xReturn = pdFALSE;
        }
        else
        {
            /* 收到任務值,先將引數ulBitsToClearOnExit取反後與通知值位與,用於在退出函式前,將通知值的某些或者全部位清零. */
            pxCurrentTCB->ulNotifiedValue &= ~ulBitsToClearOnExit;
            xReturn = pdTRUE;
        }
        /* 更改任務通知狀態,解除任務通知等待 */
        pxCurrentTCB->ucNotifyState = taskNOT_WAITING_NOTIFICATION;
    }
    taskEXIT_CRITICAL();


    return xReturn;
}

縱觀整個任務通知的實現，可以發現它比佇列、訊號量相比要簡單很多。它可以實現輕量級的佇列、二進位制訊號量、計數訊號量和事件組，並且使用更方便、更節省RAM、更高效。FreeRTOS的作者做過測試，在同一平臺下，使用使用GCC編譯器、-o2優化級別，相比使用訊號量解除任務阻塞，使用任務通知可以快45%！這個效能的提升是巨大的。我們分析過訊號量的原始碼，今天又分析了任務通知的原始碼，這使得我們知道，之所以有這麼大的效能提升，一方面緣於任務通知資料結構簡單、實現簡潔；另一方面也跟FreeRTOS的訊號量機制臃腫、效率低下有關。因為訊號量的實現全部是使用佇列機制，並沒有為訊號量做專門優化。

此外，著重說明一下任務通知並不能完全代替佇列、二進位制訊號量、計數訊號量和事件組，任務通知有自己的侷限性，我們就以它的侷限性來結束本文：

  • 只能有一個任務接收通知事件。
  • 接收通知的任務可以因為等待通知而進入阻塞狀態，但是傳送通知的任務即便不能立即完成傳送通知，也不能進入阻塞狀態。

相關推薦

FreeRTOS（20）---FreeRTOS 任務通知分析

FreeRTOS 任務通知分析 FreeRTOS 任務通知分析 傳送通知 xTaskGenericNotify() vTaskNotifyGiveFromISR() xTaskGenericNotifyFrom

FreeRTOS（８）---FreeRTOS 任務通知

FreeRTOS 任務通知函式描述引數描述返回值函式描述引數描述用法舉例獲取通知函式描述引數描述返回值用法舉例等待通知函式描述引數描述返回值用法舉例函式描述引數描述返回值 FreeRTOS 任務通知 每個RTOS任務都有一個32位的通知值，任務建立時，這個值被初

FreeRTOS（23）---FreeRTOS 空閒任務分析

FreeRTOS 空閒任務分析 FreeRTOS 空閒任務分析 釋放記憶體 處理空閒優先順序任務 執行空閒任務鉤子函式 低功耗tickless模式 FreeRTOS 空閒任務分析 當RTOS排程器

FreeRTOS（16）---FreeRTOS 任務切換分析

@TOC FreeRTOS任務相關的程式碼大約佔總程式碼的一半左右，這些程式碼都在為一件事情而努力，即找到優先順序最高的就緒任務，並使之獲得CPU執行權。任務切換是這一過程的直接實施者，為了更快的找到優先順序最高的就緒任務，任務切換的程式碼通常都是精心設計的，甚至會用到彙編指令

FreeRTOS（14）---FreeRTOS 任務建立分析

FreeRTOS 任務建立分析 FreeRTOS 任務建立分析 建立任務堆疊和任務TCB 初始化任務TCB必要的欄位 初始化任務堆疊 進入臨界區 當前任務數量增加1 為第一次執行做必要的初始化 更新當前正

FreeRTOS（3）---FreeRTOS 任務概述

FreeRTOS 任務概述 任務和協程（Co-routines） 應用程式可以使用任務也可以使用協程，或者兩者混合使用，但是任務和協程使用不同的API函式，因此在任務和協程之間不能使用同一個佇列或訊號量傳遞資料。 通常情況下，協程僅用在資源非常少的微處理器中，

FreeRTOS（4）---FreeRTOS 任務建立和刪除

FreeRTOS 任務建立和刪除任務建立函式描述引數描述返回值用法舉例任務刪除任務描述引數描述 FreeRTOS 任務建立和刪除 在FreeRTOS移植到Cortex-M3硬體平臺的文章中，我們已經見過任務建立API，但那篇文章的重點在於如何移植FreeRTOS

FreeRTOS（15）---FreeRTOS 排程器啟動過程分析

FreeRTOS 排程器啟動過程分析 使用FreeRTOS，一個最基本的程式架構如下所示： int main(void) { 必要的初始化工作; 建立任務1; 建立任務2; ... vTaskStartSchedule

FreeRTOS（18）---FreeRTOS 訊號量分析

FreeRTOS 訊號量分析 FreeRTOS的訊號量包括二進位制訊號量、計數訊號量、互斥訊號量（以後簡稱互斥量）和遞迴互斥訊號量（以後簡稱遞迴互斥量）。關於它們的區別可以參考《 FreeRTOS系列第19篇—FreeRTOS訊號量》一文。 訊號量API函式實

FreeRTOS（22）---FreeRTOS 系統節拍時鐘分析

FreeRTOS 系統節拍時鐘分析 FreeRTOS 系統節拍時鐘分析 排程器正常情況 排程器掛起情況 自動任務切換 FreeRTOS 系統節拍時鐘分析 作業系統的執行是由系統節拍時鐘驅動的。 在Fr

FreeRTOS（21）---FreeRTOS 系統延時分析

FreeRTOS 系統延時分析 FreeRTOS 系統延時分析 相對延時函式vTaskDelay() 絕對延時函式vTaskDelayUntil() 小結 FreeRTOS 系統延時分析 FreeRTOS

FreeRTOS（19）---FreeRTOS 記憶體管理分析

FreeRTOS 記憶體管理分析 FreeRTOS 記憶體管理分析 heap_1.c 記憶體申請：pvPortMalloc() 獲取當前未分配的記憶體堆大小：xPortGetFreeHeapSize() 其它函

FreeRTOS（17）---FreeRTOS 佇列分析

FreeRTOS 佇列分析 FreeRTOS 佇列分析 佇列建立函式 入隊 xQueueGenericSend() xQueueGenericSendFromISR () 出隊

FreeRTOS（７）---FreeRTOS 核心控制

FreeRTOS 核心控制 核心控制的一些功能需要移植層提供，為了方便移植，這些API函式用巨集來實現，比如上下文切換、進入和退出臨界區、禁止和使能可遮蔽中斷。核心控制函式還包括啟動和停止排程器、掛起和恢復排程器以及用於低功耗模式的調整系統節拍函式。 強制上下

FreeRTOS（9）---FreeRTOS 佇列

FreeRTOS 佇列 佇列是主要的任務間通訊方式。可以在任務與任務間、中斷和任務間傳送資訊。大多數情況下，佇列用於具有執行緒保護的FIFO（先進先出）緩衝區：新資料放在佇列的後面。當然，資料也可以放在佇列的前面，在下一篇講佇列API函式時，會涉及到資料的存放

FreeRTOS（10）---FreeRTOS 佇列API函式

FreeRTOS 佇列API函式 FreeRTOS為操作佇列提供了非常豐富的API函式，包括佇列的建立、刪除，靈活的入隊和出隊方式、帶中斷保護的入隊和出隊等等。下面就來詳細講述這些API函式。 獲取佇列入隊資訊數目 函式描述 UBaseType_t uxQue

FreeRTOS（13）---FreeRTOS 列表和列表項

FreeRTOS 列表和列表項 FreeRTOS核心排程大量使用了列表（list）和列表項（list item）資料結構。我們如果想一探FreeRTOS背後的執行機制，首先遇到的攔路虎就是列表和列表項。對於FreeRTOS核心來說，列表就是它最基礎的部分。我們

FreeRTOS筆記（四）初識任務

文章目錄 01 - 單任務與多工 1.1 - 單任務系統 1.2 - 多工系統 02 - 建立和刪除任務 2.1 - FreeRTOS_API 2.2 - 任務函式

第一節：FreeRTOS （MDK）系統移植 (詳細)

移植總結： 第一步準備素材：如何在官網上下載原始檔 第二步移植程式碼：包括兩步：①從原始碼中提需需要的檔案②將程式碼新增到工程中 第三步修改程式碼：最關鍵的一步使程式碼能夠執行起來。 移植例程程式碼DEMO https://download.csdn.net/download/z

jdk 原始碼分析（20）java NIO包簡單分析

BIO 是一種阻塞的io，主要體現在： 1）accept 時候或者客戶端嘗試連線時是阻塞的， 2）資料讀寫是阻塞的，即使是沒有讀到資料，而且每次都是讀寫一個位元組。 對於服務端一般系統中常用的方式是沒接收一個請求new 一個thread，然後由這個handler去