送藥小車代碼倉(cāng)庫(kù)：https://gitee.com/lcsc/medical_car

送藥小車數(shù)據(jù)的發(fā)布與訂閱

既然使用了RTOS，就不能像以前裸機(jī)一樣全局變量滿天飛了（當(dāng)然裸機(jī)也不能全局變量滿天飛）。

在實(shí)時(shí)操作系統(tǒng)（RTOS）中，不推薦或不建議使用全局變量來傳遞信息的原因主要有以下幾點(diǎn)：

競(jìng)爭(zhēng)條件：在多任務(wù)環(huán)境下，全局變量會(huì)面臨競(jìng)爭(zhēng)條件的問題。當(dāng)多個(gè)任務(wù)同時(shí)讀寫同一個(gè)全局變量時(shí)，會(huì)導(dǎo)致數(shù)據(jù)的不一致性和錯(cuò)誤的結(jié)果。這是因?yàn)槿蝿?wù)的執(zhí)行是并發(fā)的，無法控制它們的執(zhí)行順序。

數(shù)據(jù)共享和保護(hù)：全局變量被所有任務(wù)共享，這意味著多個(gè)任務(wù)可以同時(shí)訪問和修改該變量。如果沒有正確的數(shù)據(jù)保護(hù)機(jī)制，可能會(huì)導(dǎo)致數(shù)據(jù)損壞或沖突。

可維護(hù)性和調(diào)試?yán)щy：使用全局變量傳遞信息可能導(dǎo)致代碼的可維護(hù)性和調(diào)試的困難。由于全局變量可以被任何任務(wù)修改，追蹤問題的根源和調(diào)試錯(cuò)誤可能會(huì)變得更加困難。

為了避免上述問題，RTOS提供了一些機(jī)制來進(jìn)行任務(wù)間的通信和數(shù)據(jù)傳遞，例如：

消息隊(duì)列：任務(wù)可以通過消息隊(duì)列來發(fā)送和接收消息。每個(gè)任務(wù)有自己的私有消息隊(duì)列，通過發(fā)送和接收消息來進(jìn)行通信，避免了全局變量的競(jìng)爭(zhēng)條件和數(shù)據(jù)共享問題。

信號(hào)量：信號(hào)量可以用于同步任務(wù)的執(zhí)行和共享資源的訪問。任務(wù)可以通過申請(qǐng)和釋放信號(hào)量來控制對(duì)共享資源的訪問，并確保任務(wù)之間的互斥性和同步性。

事件標(biāo)志組：事件標(biāo)志組可以用于任務(wù)之間的通知和事件觸發(fā)。一個(gè)任務(wù)可以等待一個(gè)或多個(gè)事件標(biāo)志的狀態(tài)變化，并在事件發(fā)生時(shí)被喚醒執(zhí)行相應(yīng)的操作。

通過使用這些RTOS提供的通信機(jī)制，可以更安全地在任務(wù)之間傳遞信息，避免競(jìng)爭(zhēng)條件和數(shù)據(jù)共享問題，并提高代碼的可維護(hù)性和調(diào)試效率。

在送藥小車這個(gè)工程中采用RT-Thread軟件包uMCN，uMCN (Micro Multi-Communication Node) 提供了一種基于發(fā)布/訂閱模式的安全跨線程/進(jìn)程的通信方式。在系統(tǒng)中，uMCN 被廣泛應(yīng)用于任務(wù)和模塊間的數(shù)據(jù)通信。使用發(fā)布-訂閱（Publish-Subscribe）機(jī)制可以提供更靈活和高效的任務(wù)間通信方式，支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的通信模式。這種機(jī)制可以解決使用全局變量傳遞信息可能帶來的競(jìng)爭(zhēng)條件和數(shù)據(jù)共享問題。

發(fā)布-訂閱機(jī)制基于事件驅(qū)動(dòng)的思想，其中包含兩個(gè)角色：發(fā)布者（Publisher）和訂閱者（Subscriber）。發(fā)布者負(fù)責(zé)發(fā)布事件或消息，而訂閱者則注冊(cè)對(duì)感興趣的事件或消息進(jìn)行訂閱。他提供了一種松散耦合的通信方式，允許任務(wù)或模塊之間通過發(fā)布和訂閱消息來進(jìn)行通信，而不需要直接知道彼此的存在。

在使用發(fā)布-訂閱模式獲取數(shù)據(jù)時(shí)，通常涉及以下角色和操作：

發(fā)布者（Publisher）：負(fù)責(zé)生成和發(fā)布數(shù)據(jù)或事件。發(fā)布者將數(shù)據(jù)發(fā)送到一個(gè)或多個(gè)特定的主題（Topic），而不關(guān)心具體的訂閱者。

訂閱者（Subscriber）：訂閱者對(duì)特定的主題感興趣，并通過訂閱該主題來接收與之相關(guān)的數(shù)據(jù)或事件。

主題（Topic）：主題是數(shù)據(jù)或事件的分類或標(biāo)識(shí)符，發(fā)布者根據(jù)主題將數(shù)據(jù)發(fā)送到相應(yīng)的通道，而訂閱者根據(jù)主題來選擇訂閱的數(shù)據(jù)源。

使用發(fā)布-訂閱模式獲取數(shù)據(jù)的好處在于，系統(tǒng)中的任務(wù)或模塊之間解耦合，發(fā)布者和訂閱者之間不直接依賴于彼此的存在，從而提高了系統(tǒng)的可擴(kuò)展性和靈活性。此外，發(fā)布-訂閱模式還能夠支持多對(duì)多的通信，允許多個(gè)訂閱者同時(shí)接收相同的數(shù)據(jù)或事件，實(shí)現(xiàn)了信息的分發(fā)和共享。

他的優(yōu)勢(shì)如下：

松耦合性：發(fā)布-訂閱機(jī)制使任務(wù)之間的通信更加松耦合。發(fā)布者不需要直接知道訂閱者的存在，也不需要關(guān)心具體的訂閱者數(shù)量和位置。訂閱者只需要訂閱感興趣的事件或消息，從而實(shí)現(xiàn)任務(wù)之間的解耦。

靈活性：發(fā)布-訂閱機(jī)制支持多對(duì)多的通信模式，一個(gè)發(fā)布者可以有多個(gè)訂閱者，一個(gè)訂閱者也可以訂閱多個(gè)發(fā)布者的事件或消息。這種靈活性使得任務(wù)之間可以方便地建立復(fù)雜的通信關(guān)系。

擴(kuò)展性：通過發(fā)布-訂閱機(jī)制，可以方便地?cái)U(kuò)展系統(tǒng)，添加新的發(fā)布者或訂閱者，而不需要修改現(xiàn)有的任務(wù)邏輯。這種擴(kuò)展性使得系統(tǒng)更具可維護(hù)性和可擴(kuò)展性。

將各個(gè)數(shù)據(jù)發(fā)布，并對(duì)接上echo輸出函數(shù)后，就可以在RT-Thread的Finsh控制臺(tái)獲取到數(shù)據(jù)信息了（下面是通過uMCN獲取電機(jī)編碼器1的數(shù)據(jù)）：

具體使用參考uMCN的倉(cāng)庫(kù)：

添加新主題

為了添加新的主題 (topic)，你需要先創(chuàng)建一個(gè)主題內(nèi)容。例如：

typedef struct {
        rt_uint32_t a;
        float b;
        int8_t c[4];
} data_content;

uMCN對(duì)主題內(nèi)容的長(zhǎng)度和類型沒有限制，所以理論上可以用來傳輸任何類型的消息。

然后你需要使用宏 MCN_DEFINE(name, size) 來定義主題。一般在發(fā)布主題的源文件的頂部定義主題。例如：

MCN_DEFINE(my_topic, sizeof(data_content));

uMCN 支持一個(gè)主題擁有多個(gè)發(fā)布者和訂閱者。注意同一個(gè)主題名字不同被重復(fù)定義，不然編譯器會(huì)報(bào)錯(cuò)。

下一步就是使用 mcn_advertise() 來注冊(cè)主題。例如：

mcn_advertise(MCN_ID(my_topic), my_topic_echo);

MCN_ID() 宏根據(jù)主題名獲得樞紐節(jié)點(diǎn)。my_topic_echo 是一個(gè)回調(diào)函數(shù)，用來打印主題的數(shù)據(jù)。

static int my_topic_echo(void* param)
{
        data_content data;
        if(mcn_copy_from_hub((McnHub*)param, &data) == FMT_EOK){
                printf("a:%d b:%f c:%c %c %c %cn", data.a, data.b, data.c[0], data.c[1], data.c[2], data.c[3]);
        return 0;
        }
        return -1;
}

發(fā)布主題

可以在系統(tǒng)的任意位置使用函數(shù) mcn_publish() 來發(fā)布一個(gè)主題。例如：

data_content my_data = {50, -2.0, {1，2，3，4}}；
mcn_publish(MCN_ID(my_topic), &my_data);

審核編輯 黃宇