日B视频 亚洲,啪啪啪网站一区二区,91色情精品久久,日日噜狠狠色综合久,超碰人妻少妇97在线,999青青视频,亚洲一区二卡,让本一区二区视频,日韩网站推荐

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

重點講解如何結(jié)合RTOS進行處理數(shù)據(jù)

454398 ? 來源:面包板社區(qū) ? 作者:小小毛 ? 2021-02-09 09:15 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

我們巧妙的利用了RTSO自帶的消息隊列,我們可以把每一個接收的數(shù)據(jù)看做一個消息元素。
先回顧一下知識點:

FreeRTOS消息隊列

基于 FreeRTOS 的應(yīng)用程序由一組獨立的任務(wù)構(gòu)成——每個任務(wù)都是具有獨立權(quán)限的程序。這些獨立的任務(wù)之間的通訊與同步一般都是基于操作系統(tǒng)提供的IPC通訊機制,而FreeRTOS 中所有的通信與同步機制都是基于隊列實現(xiàn)的。
消息隊列是一種常用于任務(wù)間通信的數(shù)據(jù)結(jié)構(gòu),隊列可以在任務(wù)與任務(wù)間、中斷和任務(wù)間傳送信息,實現(xiàn)了任務(wù)接收來自其他任務(wù)或中斷的不固定長度的消息。任務(wù)能夠從隊列里面讀取消息,當隊列中的消息是空時,掛起讀取任務(wù),用戶還可以指定掛起的任務(wù)時間;當隊列中有新消息時,掛起的讀取任務(wù)被喚醒并處理新消息,消息隊列是一種異步的通信方式。

隊列特性

1.數(shù)據(jù)存儲

隊列可以保存有限個具有確定長度的數(shù)據(jù)單元。隊列可以保存的最大單元數(shù)目被稱為隊列的“深度”。在隊列創(chuàng)建時需要設(shè)定其深度和每個單元的大小。
通常情況下,隊列被作為 FIFO(先進先出)緩沖區(qū)使用,即數(shù)據(jù)由隊列尾寫入,從隊列首讀出。當然,由隊列首寫入也是可能的。
往隊列寫入數(shù)據(jù)是通過字節(jié)拷貝把數(shù)據(jù)復(fù)制存儲到隊列中;從隊列讀出數(shù)據(jù)使得把隊列中的數(shù)據(jù)拷貝刪除。

2.讀阻塞

當某個任務(wù)試圖讀一個隊列時,其可以指定一個阻塞超時時間。在這段時間中,如果隊列為空,該任務(wù)將保持阻塞狀態(tài)以等待隊列數(shù)據(jù)有效。當其它任務(wù)或中斷服務(wù)例程往其等待的隊列中寫入了數(shù)據(jù),該任務(wù)將自動由阻塞態(tài)轉(zhuǎn)移為就緒態(tài)。當?shù)却臅r間超過了指定的阻塞時間,即使隊列中尚無有效數(shù)據(jù),任務(wù)也會自動從阻塞態(tài)轉(zhuǎn)移為就緒態(tài)。
由于隊列可以被多個任務(wù)讀取,所以對單個隊列而言,也可能有多個任務(wù)處于阻塞狀態(tài)以等待隊列數(shù)據(jù)有效。這種情況下,一旦隊列數(shù)據(jù)有效,只會有一個任務(wù)會被解除阻塞,這個任務(wù)就是所有等待任務(wù)中優(yōu)先級最高的任務(wù)。而如果所有等待任務(wù)的優(yōu)先級相同,那么被解除阻塞的任務(wù)將是等待最久的任務(wù)。

說些題外話,ucos中是具有廣播消息的,當有多個任務(wù)阻塞在隊列上,當發(fā)送消息的時候可以選擇廣播消息,那么這些阻塞的任務(wù)都能被解除阻塞。

3.寫阻塞

與讀阻塞想反,任務(wù)也可以在寫隊列時指定一個阻塞超時時間。這個時間是當被寫隊列已滿時,任務(wù)進入阻塞態(tài)以等待隊列空間有效的最長時間。
由于隊列可以被多個任務(wù)寫入,所以對單個隊列而言,也可能有多個任務(wù)處于阻塞狀態(tài)以等待隊列空間有效。這種情況下,一旦隊列空間有效,只會有一個任務(wù)會被解除阻塞,這個任務(wù)就是所有等待任務(wù)中優(yōu)先級最高的任務(wù)。而如果所有等待任務(wù)的優(yōu)先級相同,那么被解除阻塞的任務(wù)將是等待最久的任務(wù)。

消息隊列的工作流程1.發(fā)送消息

任務(wù)或者中斷服務(wù)程序都可以給消息隊列發(fā)送消息,當發(fā)送消息時,如果隊列未滿或者允許覆蓋入隊, FreeRTOS 會將消息拷貝到消息隊列隊尾,否則,會根據(jù)用戶指定的阻塞超時時間進行阻塞,在這段時間中,如果隊列一直不允許入隊,該任務(wù)將保持阻塞狀態(tài)以等待隊列允許入隊。當其它任務(wù)從其等待的隊列中讀取入了數(shù)據(jù)(隊列未滿),該任務(wù)將自動由阻塞態(tài)轉(zhuǎn)為就緒態(tài)。當任務(wù)等待的時間超過了指定的阻塞時間,即使隊列中還不允許入隊,任務(wù)也會自動從阻塞態(tài)轉(zhuǎn)移為就緒態(tài),此時發(fā)送消息的任務(wù)或者中斷程序會收到一個錯誤碼 errQUEUE_FULL。
發(fā)送緊急消息的過程與發(fā)送消息幾乎一樣,唯一的不同是,當發(fā)送緊急消息時,發(fā)送的位置是消息隊列隊頭而非隊尾,這樣,接收者就能夠優(yōu)先接收到緊急消息,從而及時進行消息處理。
下面是消息隊列的發(fā)送API接口,函數(shù)中有FromISR則表明在中斷中使用的。

o4YBAGAP0tyAcqp2AABD05nzisM612.png

消息隊列讀取

o4YBAGAP0uqABC4FAAAxVSVZBSc338.png


任務(wù)調(diào)用接收函數(shù)收取隊列消息, 函數(shù)首先判斷當前隊列是否有未讀消息, 如果沒有, 則會判斷參數(shù) xTicksToWait, 決定直接返回函數(shù)還是阻塞等待。
如果隊列中有消息未讀, 首先會把待讀的消息復(fù)制到傳進來的指針所指內(nèi), 然后判斷函數(shù)參數(shù) xJustPeeking == pdFALSE的時候, 符合的話, 說明這個函數(shù)讀取了數(shù)據(jù), 需要把被讀取的數(shù)據(jù)做出隊處理, 如果不是, 則只是查看一下(peek),只是返回數(shù)據(jù),但是不會把數(shù)據(jù)清除。
對于正常讀取數(shù)據(jù)的操作, 清除數(shù)據(jù)后隊列會空出空位, 所以查看隊列中的等待列表中是否有任務(wù)等發(fā)送數(shù)據(jù)而被掛起, 有的話恢復(fù)一個任務(wù)就緒, 并根據(jù)優(yōu)先級判斷是否需要出進行任務(wù)切換。
對于只是查看數(shù)據(jù)的, 由于沒有清除數(shù)據(jù), 所以沒有空間新空出,不需要檢查發(fā)送等待鏈表, 但是會檢查接收等待鏈表, 如果有任務(wù)掛起會切換其到就緒并判斷是否需要切換。

接下來,我們可以從中斷再到任務(wù)這樣一個流程去編寫代碼:

如下的框圖來說明一下 FreeRTOS 消息隊列的實現(xiàn),讓大家有一個形象的認識。

o4YBAGAP0viAbhHtAACALIk2QMw805.png

1. 中斷如何處理:

///

void LpUart0_IRQHandler(void)

{

BaseType_t xHigherPriorityTaskWoken = pdFALSE;

uint8_t res=0;

// if(LPUart_GetStatus(M0P_LPUART0, LPUartPE))/*奇偶檢驗錯誤*/

// {

// LPUart_ClrStatus(M0P_LPUART0, LPUartPE);

// }

if(LPUart_GetStatus(M0P_LPUART0, LPUartRC)) ///接收數(shù)據(jù)中斷

{

LPUart_ClrStatus(M0P_LPUART0, LPUartRC); ///<清接收中斷請求? ?? ???

res =LPUart_ReceiveData(M0P_LPUART0);

xQueueSendFromISR(usart_Queue,(void *) &res,&xHigherPriorityTaskWoken);

portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

}

}

任務(wù)中接收信號,這里并不是每一條消息都接收嗎,因為沒有空閑中斷,而是做了100ms絕對延時,確保一幀數(shù)據(jù)接收完成。

/**

***********************************************************************

** \brief 2400波特率:'100ms = 24bytes'

**

**

** \param 1 :void

** \retval void

***********************************************************************/

void APP_LocalCOM_ReadData(void)

{

uint8_ttemp_bytes = 0; /*隊列中字節(jié)長度new*/

uint8_t cnt;

static uint8_tbuff[QueueSIZE] = {0}; /*暫存接收協(xié)議,從0x68開始,用于crc計算*/

static TickType_t StartTick = 0;

static uint8_t ShadowBytes = 0;/*old*/

temp_bytes = uxQueueMessagesWaiting(usart_Queue);//檢查消息數(shù)

if(temp_bytes == 0)//檢查隊列的長度

{

ShadowBytes = 0;

}

else

{

if(ShadowBytes != temp_bytes)//有新的數(shù)據(jù)

{

ShadowBytes = temp_bytes;

StartTick = xTaskGetTickCount();

}

else

{

if(xTaskGetTickCount() - StartTick > 100)

{

for(cnt = 0; cnt

{

xQueueReceive(usart_Queue,(void*)&buff[cnt%QueueSIZE],(TickType_t)100);//接收數(shù)據(jù)

}

protocol_parse(buff,temp_bytes);

//BSP_UARTx_SendBytes(M0P_UART0,temp_bytes, buff); //test

}

}

}

}
編輯:hfy

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 數(shù)據(jù)存儲
    +關(guān)注

    關(guān)注

    5

    文章

    1038

    瀏覽量

    53020
  • FreeRTOS
    +關(guān)注

    關(guān)注

    14

    文章

    500

    瀏覽量

    67301
  • 隊列
    +關(guān)注

    關(guān)注

    1

    文章

    46

    瀏覽量

    11254
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    基于極海APM32F4的Azure RTOS ThreadX移植過程分享

    最近在玩APM32F407IG的板子,發(fā)現(xiàn)官方提供了兩個RTOS的demo,F(xiàn)reeRTOS和RT-thread。想著APM32F4這么豐富的資源,是不是也可以跑一下ThreadX RTOS看看
    的頭像 發(fā)表于 04-02 11:30 ?1274次閱讀
    基于極海APM32F4的Azure <b class='flag-5'>RTOS</b> ThreadX移植過程分享

    C語言重點—指針篇

    C語言是比較偏底層的語言,為什么他比較偏底層,就是因為他的很多操作都是直接針對內(nèi)存操作的。 這篇我們就來講解C語言的一大特點,也是難點,指針和指針操作。 這篇文章我會先從基本類型的存儲過程和原理講起
    發(fā)表于 01-22 08:23

    RTOS在嵌入式開發(fā)中的作用

    事件驅(qū)動的RTOS,來替代基于輪詢的超循環(huán)結(jié)構(gòu),可以生成一個更有效的設(shè)計,更小的存儲占用,應(yīng)用可以獲得更多的處理器時間。 降低復(fù)雜度 RTOS允許應(yīng)用劃分為一個個小的自主運行的任務(wù)。任務(wù)執(zhí)行自己的上下文
    發(fā)表于 12-26 07:53

    使用RTOS時需要注意的幾點內(nèi)容分享

    的MCU。例如,CMX的CMX-RTX和CMX-Tiny+可運行在8位MCU到64位處理器上。 RTOS核心:調(diào)度和分割 大多數(shù)程序員不熟悉RTOS的限制和要求。大多數(shù)人通常因其性能選擇RT
    發(fā)表于 12-23 06:34

    選擇RTOS的要點

    更小和資源有限的MCU。例如,CMX的CMX-RTX和CMX-Tiny+可運行在8位MCU到64位處理器上。 RTOS核心:調(diào)度和分割 大多數(shù)程序員不熟悉RTOS的限制和要求。大多數(shù)人通常因其性能
    發(fā)表于 12-12 08:00

    如何在 RTOS處理微控制器的低功耗特性

    基于 RTOS 的低功耗設(shè)計思路。 越來越多的嵌入式產(chǎn)品基于 RTOS 作為軟件平臺, 有些產(chǎn)品對低功耗的要求也越來越高, 本文討論一下如何在 RTOS處理微控制器的低功耗特性。聊
    發(fā)表于 12-12 07:07

    RTOS Crash 問題全維度分析與解決指南

    ,RTOS Crash往往伴隨硬件級異常、任務(wù)調(diào)度紊亂、資源耗盡等核心問題,需結(jié)合RTOS內(nèi)核特性、硬件架構(gòu)、應(yīng)用邏輯分層定位。 一、RTOS Crash的核心誘因分類
    發(fā)表于 12-08 03:56

    學習RTOS的意義?

    對于嵌入式軟件工程師,學習RTOS非常有必要。 1. 項目需要 隨著產(chǎn)品要實現(xiàn)的功能越來越多,單純的裸機系統(tǒng)已經(jīng)不能完美地解決問題,反而會使編程變得更加復(fù)雜,如果想降低編程的難度,就必須引入
    發(fā)表于 11-27 08:16

    嵌入式需要掌握哪些核心技能?

    嵌入式需要掌握哪些核心技能? 若想通過學習嵌入式技術(shù)提升就業(yè)競爭力,需重點掌握C語言、嵌入式硬件架構(gòu)、RTOS/Linux開發(fā)、通信協(xié)議四大核心技能,并結(jié)合行業(yè)需求積累項目經(jīng)驗。 以下為具體分析
    發(fā)表于 10-21 16:25

    請問編譯純rtos到底是選擇Linux+rtos的sdk編譯only rtos還是直接使用rtos sdk?

    編譯純rtos到底是選擇Linux+rtos的sdk編譯only rtos還是直接使用rtos sdk?
    發(fā)表于 07-11 07:22

    下一代PX5 RTOS具有哪些優(yōu)勢

    許多古老的RTOS設(shè)計至今仍在使用,包括Zephyr(1980年代)、Nucleus(1990年代)和FreeRTOS(2003年)。所有這些舊設(shè)計都有專有的API,通常更大、更慢,并且缺乏下一代RTOS的必要安全認證和功能。
    的頭像 發(fā)表于 06-19 15:06 ?1327次閱讀

    rtosrtos&amp;linux能否調(diào)整連接windows后的設(shè)備名稱?

    rtosrtos&amp;linux 能否調(diào)整連接windows后的設(shè)備名稱
    發(fā)表于 05-14 06:19

    程序設(shè)計與數(shù)據(jù)結(jié)構(gòu)

    的地址)出發(fā),采用推導的方式,深入淺出的分析了廣大C程序員學習和開發(fā)中遇到的難點。 2. 從方法論的高度對C語言在數(shù)據(jù)結(jié)構(gòu)和算法方面的應(yīng)用進行了深入講解和闡述。 3. 講解了絕大多
    發(fā)表于 05-13 16:45

    如何在Eclipse ThreadX RTOS中集成SystemView

    SEGGER實時軟件分析工具SystemView已經(jīng)在ThreadX v6.4.2上進行了測試。SystemView從v3.60c版本支持Eclipse ThreadX(Azure RTOS),用戶
    的頭像 發(fā)表于 05-06 17:11 ?1643次閱讀

    RTOS如何在FX3中工作?

    大家好, 我正在使用 FX3 進行一個項目。 我想知道 RTOS 調(diào)度是如何工作的。 我知道調(diào)用“CyU3PKernelEntry();”后 RTOS 就會開始工作。 如果我只注冊一個應(yīng)用程序線程。 我的線程什么時候執(zhí)行?
    發(fā)表于 05-06 13:20
    眉山市| 怀仁县| 黎城县| 泾阳县| 鄂托克前旗| 周宁县| 志丹县| 逊克县| 丰都县| 山丹县| 淳安县| 儋州市| 阿坝县| 子长县| 祥云县| 察雅县| 彩票| 南川市| 星座| 五原县| 永登县| 响水县| 同德县| 潢川县| 休宁县| 彩票| 新郑市| 霍州市| 鹤山市| 抚宁县| 章丘市| 黄平县| 大城县| 宁武县| 沈阳市| 宁波市| 宜兰县| 增城市| 罗源县| 景德镇市| 祥云县|