關(guān)注+星標(biāo)公眾號(hào)，不錯(cuò)過精彩內(nèi)容
作者 |?strongerHuang
微信公眾號(hào)?| strongerHuang
信號(hào)量，本質(zhì)是傳遞一個(gè)“事件”。比如：任務(wù)A完成發(fā)送數(shù)據(jù)，通過信號(hào)量通知任務(wù)B。
OSSemPost(EventSem_SendOK);我們主要想傳遞“完成發(fā)送數(shù)據(jù)”這個(gè)“事件”，進(jìn)一步分析，其實(shí)就是一個(gè)“標(biāo)志”或“變量”。
隊(duì)列和信號(hào)量原理類似有點(diǎn)類似，只是這里是“變量”。比如：串口接收完成一幀數(shù)據(jù)，通過隊(duì)列發(fā)送給任務(wù)B.
OSQPost(UARTRcvQueue, RcvBuf);相比信號(hào)量，隊(duì)列傳遞的數(shù)據(jù)量更大，隊(duì)列傳遞的有效數(shù)據(jù)一般是“數(shù)組”。
還有郵箱，與隊(duì)列類似，可以理解為“二維數(shù)組”。
寫到這里，你會(huì)發(fā)現(xiàn)，不管信號(hào)量，還是隊(duì)列，底層本質(zhì)也是傳遞“變量”“數(shù)組”。
那么問題來了：RTOS任務(wù)間通信為什么不用全局變量？
這個(gè)問題比較常見，也看到在我的技術(shù)交流群有討論，所以就簡(jiǎn)單來分享一下看法。
全局變量有什么問題？
信號(hào)量、隊(duì)列通信原理
INT8U OSSemPost (OS_EVENT *pevent){OS_CPU_SR cpu_sr = 0u;if (pevent == (OS_EVENT *)0) { /* Validate 'pevent' */return (OS_ERR_PEVENT_NULL);}if (pevent->OSEventType != OS_EVENT_TYPE_SEM) { /* Validate event block type */return (OS_ERR_EVENT_TYPE);}OS_ENTER_CRITICAL();if (pevent->OSEventGrp != 0u) { /* See if any task waiting for semaphore *//* Ready HPT waiting on event */(void)OS_EventTaskRdy(pevent, (void *)0, OS_STAT_SEM, OS_STAT_PEND_OK);OS_EXIT_CRITICAL();OS_Sched(); /* Find HPT ready to run */return (OS_ERR_NONE);}if (pevent->OSEventCnt < 65535u) { /* Make sure semaphore will not overflow */pevent->OSEventCnt++; /* Increment semaphore count to register event */OS_EXIT_CRITICAL();return (OS_ERR_NONE);}OS_EXIT_CRITICAL(); /* Semaphore value has reached its maximum */return (OS_ERR_SEM_OVF);}
我們需要傳遞的有效信息雖然只有一個(gè)變量，但它會(huì)做“臨界區(qū)”管理，以及預(yù)判一些錯(cuò)誤的情況等。
最后，RTOS源碼也可以算是一個(gè)優(yōu)秀的項(xiàng)目，特別是目前普及率比較高、裝機(jī)量比較多的RTOS，比如μC/OS、FreeRTOS、RT-Thread、ThreadX等。
最最后，有時(shí)間的小伙伴可以閱讀一下RTOS源碼，RTOS內(nèi)核我推薦μC/OS，閱讀源碼能讓你掌握一些軟件架構(gòu)的知識(shí)，也能讓你明白一些開發(fā)過程種常見的問題。
------------?END?------------
●專欄《嵌入式工具》
●專欄《嵌入式開發(fā)》
●專欄《Keil教程》
●嵌入式專欄精選教程
點(diǎn)擊“閱讀原文”查看更多分享。
