eCos Mbox机制
背景
總結(jié)下 ecos mbox這個通信機制。
ecos下面的通信機制真的很少,沒有信號、消息隊列、信號量、unix域…, 當(dāng)然,我看到里面不少地方用到了 網(wǎng)絡(luò)socket,如DHCP客戶端的開啟和關(guān)閉。
mbox我理解上應(yīng)該就是Linux下消息隊列吧,但是BRCM下面的 rc 中,用到的非常簡單,僅僅使用這種機制來傳遞一個整數(shù),哈哈,真是蛋碎。
經(jīng)過擴展后,能傳遞字符串了。下面,走進去看下。
mbox的實現(xiàn)
tapf_sys_init->sys_main->(*sys_msg_init)() 這個函數(shù)指針封裝的,目前未發(fā)現(xiàn)有什么備用選擇。
->msg_init->cyg_mbox_create關(guān)鍵就是這個函數(shù)了,其它封裝后面說。
函數(shù)原型這樣,很簡單,一個ID, 一個結(jié)構(gòu)體。
這函數(shù)很坑,
3)handle保存mbox的地址,完全沒必要在這賦值啊。
估計是一些設(shè)計上的兼容性,才導(dǎo)致了這么奇怪的寫法。
第一個對象出場:Cyg_Mbox
構(gòu)造函數(shù)為空,但它調(diào)用了模板類 Cyg_Mboxt2,
Cyg_Mboxt2<void *, CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE> m;
這個模板中成員與C結(jié)構(gòu)中的成員一致,其構(gòu)建函數(shù)對 base , count成員賦 0 (mboxt2.inl) 。
獲取mbox
cyg_mbox_get(rc_mbox_handle) & 0xffff) -> ((Cyg_Mbox *)mbox)->get()為啥&0xffff, 把get出來的結(jié)果 取 低16位。
-> m.get( p ) 再調(diào)用模板方法。
get與set都是使用模板中方法實現(xiàn)的。
對于其中的每個條目操作,又有點環(huán)形隊列 了。
這里很簡單,僅僅是存儲指針數(shù)組,然后返回其中的一個原素。
put時,找到一個位置,然后插入進去。
當(dāng)然實現(xiàn)中會有些PV操作保證原子性、還有阻塞喚醒層面的操作。
再回頭看現(xiàn)有的封裝實現(xiàn) 。
struct msg_struct {cyg_handle_t mbox_msg_id;cyg_mbox mbox;PIU8 mbox_tag;PI8 msg_info[MAX_MBOX_MSG_NUM][MAX_MBOX_MSG_LEN]; };id / mbox同原來的調(diào)用函數(shù)。 msg_info用于存儲傳遞的字符串,二維的個數(shù)等同于系統(tǒng)中 mbox的存儲個數(shù)。
在操作時,要考慮獲取到的消息與msg_info中的對應(yīng)關(guān)系。
這種感覺,就像體制外,硬生生的附加上,當(dāng)然它能work well ,但缺少層次。
思考
變長與定長 ,加入消息頭(類UDP)。
消息僅傳遞malloc的指針,指向存儲的消息,通過頭部中的字段指定長度,來提取消息,完成后釋放。不知為什么,很多人(包括我)都會覺得ecos下面使用動態(tài)內(nèi)容就不安全,會產(chǎn)生莫名其妙的問題?會么?缺少獨立進程、互不影響的分離機制(有了可能就不叫ecos了,會增加復(fù)雜度),導(dǎo)致其它任何一處的有問題,必將壞掉一鍋湯。
但絕對不能“一朝被蛇咬,十年怕井繩”,這個機制是沒有問題的。并且這樣地是發(fā)揮了mbox的作用。(在機制上進行設(shè)計)
如何把存儲空間放到消息對象的內(nèi)部,減少 申請與釋放內(nèi)容的動作。
好吧,就能存儲10條消息、定長,那么就去擴展struct 及class吧,注意其它使用mbox的地方。
總結(jié)
以上是生活随笔為你收集整理的eCos Mbox机制的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 16位cpu 移位处理
- 下一篇: 文化氛围对新人培养新人的影响