有深入理解RTOS原理,或閱讀過RTOS源碼的同學(xué)應(yīng)該知道:RTOS實現(xiàn)任務(wù)間通信通常是由一系列指針進行操作實現(xiàn)的。
信號量,本質(zhì)是傳遞一個“事件”。比如:任務(wù)A完成發(fā)送數(shù)據(jù),通過信號量通知任務(wù)B。
OSSemPost(EventSem_SendOK);
我們主要想傳遞“完成發(fā)送數(shù)據(jù)”這個“事件”,進一步分析,其實就是一個“標(biāo)志”或“變量”。
隊列和信號量原理類似有點類似,只是這里是“變量”。比如:串口接收完成一幀數(shù)據(jù),通過隊列發(fā)送給任務(wù)B.
OSQPost(UARTRcvQueue, RcvBuf);
相比信號量,隊列傳遞的數(shù)據(jù)量更大,隊列傳遞的有效數(shù)據(jù)一般是“數(shù)組”。
還有郵箱,與隊列類似,可以理解為“二維數(shù)組”。
寫到這里,你會發(fā)現(xiàn),不管信號量,還是隊列,底層本質(zhì)也是傳遞“變量”“數(shù)組”。
那么問題來了:RTOS任務(wù)間通信為什么不用全局變量?
這個問題比較常見,也看到在我的技術(shù)交流群有討論,所以就簡單來分享一下看法。
全局變量有什么問題?
信號量、隊列通信原理
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);}
我們需要傳遞的有效信息雖然只有一個變量,但它會做“臨界區(qū)”管理,以及預(yù)判一些錯誤的情況等。
最后,RTOS源碼也可以算是一個優(yōu)秀的項目,特別是目前普及率比較高、裝機量比較多的RTOS,比如μC/OS、FreeRTOS、RT-Thread、ThreadX等。
最最后,有時間的小伙伴可以閱讀一下RTOS源碼,RTOS內(nèi)核我推薦μC/OS,閱讀源碼能讓你掌握一些軟件架構(gòu)的知識,也能讓你明白一些開發(fā)過程種常見的問題。