12月 我與rt thread的「江湖恩怨」

2022-06-17 16:18:15 字數 3778 閱讀 3880

大約在2023年下半年,在換找工作的時候,聽到rt-thread(有的簡稱rtt,很容易理解成segger公司的jlink工具元件rtt view/client),當時去乙個公司面試,前乙個工程師要離就開給我簡單介紹了一下,以前接觸過ucosii/iii,但rt-thread是第一次聽說,優雅的**引的我驚鴻一瞥。

2018~2019,不斷關注各種微作業系統,期間rtt在鄭州舉辦過2次線下培訓,都去了(甚至有的是請假,因為感覺時機難得),培訓中間的動手操作環節,因為對env等不熟悉,跟著老師操作有的都沒完成實驗,感覺非常遺憾。19年rtt又推出了線上認證,但因工作繁忙準備不足,差一點就過了。

2023年初疫情期間,我在家裡辦公,又去搜rtt資料,驚奇發現官網有了很詳細的文件,然後就如痴如迷的所有文件過了一遍,再去看它的核心**,尤其是用c語言去實現c++的思想(裝置物件)時深深折服,此時不再彷徨於究竟今後用啥微作業系統了,就它,rtt,沒錯了。

進入新公司,專案需要在微控制器的多個串列埠同時實現多個modburtu主機,從機,還需要modbustcp,這種情況下,以前自己寫的解析協議棧和freemodbus不適合,網上搜到libmodbus可以支援,並且rtt支援以w5500,at命令集,tcp/ip連線網路,所以就決定了在rtt上用w5500+libmodbus的架構。但當時對rtt只是看了很多文件,ucos微作業系統使用過,拿乙個新專案練手,現在看來怎麼說都太瘋狂。如果弄不好專案可能就黃了,自己也可能捲鋪蓋走人。但當時我的真實想法是,我一直在隔靴撓癢,在門外轉悠,放又放不下,進又進不去,如果不逼自己一把,自己可能永遠沒機會專案中用上。rtt作為國產優秀的開源微作業系統的代表,我不能缺席落後。而且我發現其msh,驅動編寫等和linux很接近,我可以通過rtt進入linux世界大門。而不僅僅是乙個pc端的體驗者。

但回過頭來看,這舉動風險還是太大,萬幸,自己的堅持加上rtt官方的服務態度和能力的提公升讓自己的專案越過乙個個險灘安全著陸。但作為過來人,我對後面學習的網友衷心建議不要冒這麼大的風險,在新公司,新專案,在對rtt還不太完全熟悉的情況下,不要貿然上馬,因為在專案進度,結果負責等約束下風險太大,你完全可以拿你已經量產的產品,在沒有時間進度要求的情況下,嘗試去用rtt實現它,因為此時硬體已經保證無誤,驅動都已現成弄好的,業務邏輯都已了然於胸,又沒有時間要求和要你為結果負責,這樣去應用rtt應該是最好的一種模式,等你弄好再和原來產品對比,達到或效能超過就是一大成功,這會給你以後專案獨立應用rtt增添很大的信心。

rtt在使用過程中經過了三個階段,keil裸機,keil+env,studio。因為樣機也是首次開發,如果一開始就上系統,如果出問題你不知道是硬體問題還是驅動問題或是系統原因。所以你需要先按自己熟悉的方法開發好裸機驅動程式,驗證了硬體電路沒有問題,然後用在系統中用任務去呼叫,熟悉rtt下任務的開發特點,最後按rtt驅動開發的規範文件,修改驅動讓它符合rtt系統的特點,儘管不一定那麼規範,但至少大體上符合要求,能執行起來。最後在結合核心和ipc通訊適應完全的rtt開發模式。

在開發之初,很多網友會疑惑env和studio的取捨,env歷史悠久,開發比較成熟,資料和了解的人比較多,編譯的**尺寸也比studio高,官方文件的資料很多都是以env為基礎講的;studio是個新生事物,還不成熟不完善,編譯**尺寸也稍大,但勝在它是現在rtt主推的,更加直觀的元件軟體包配置方便了許多。我的理解凡事廠家主推的都是符合發展趨勢的,就如我們大多數開發stm32從暫存器開發,再到標準庫,最後到hal/ll庫一樣,儘管使用者對新生事物有很大的惰性不願遷移,特別是現有的特別經典,但拗不過趨勢,特別是在如今,stm32在cubmx大獲成功極大提高使用者效率的情況下,昔日最執拗的那一部分人也開始慢慢改變。微軟的winxp-win7-win10是一樣的歷史發展過程。

搞定了取捨之後就是在studio下的開發了,我又沒走尋常路,沒有基於bsp開發,直接基於晶元模式開發。中間踩過很多坑,一度壓力非常大,懷疑自己能否搞定這一切,但好在,我不是乙個輕易放棄的人;rtt也在積極的改變。最終專案量產,rtt的改變也是有目共睹。我想這就是開源軟體和開發者和諧共生,共進成長的魅力。下面就結合踩坑計具體講下在這過程中我和rtt的「江湖恩怨」及「愛恨情仇」。

開始就懵逼:當我基於晶元建立工程安裝說明文件一頓操作猛如虎之後,終端居然紋絲不動,一頓抓耳撓腮,當時studio剛推出用的人不多,大家都對env熟悉,為此我還專門建立env的bsp工程但env下沒有問題,最後經過追蹤發現,對於不常用型號的stm32晶元,且我用的是串列埠5,studio裡面對串列埠io的復用定義有誤,對照晶元手冊該正了這一點就正常了。

w5500驅動:可以說這是我專案中風險的最大變數。當初就是看到官方說明對w5500的支援,想必不會有坑,但現實是理想太豐滿。剛開始就報錯。後來遮蔽ops函式算是編譯通過。

libmodbus是我當初選擇rtt的關鍵,但在modbustcp時缺遭受了很大的打擊,原demo支援多客戶端連線,但斷開鏈結感覺很不正常,後來查詢各種資料和詢問人,將裡面的關閉檔案網路裝置函式改成關閉埠就好了。

最膽顫心驚的一幕:產品開發好後就放在辦公室內模擬執行除錯。但測試人員發現,將w5500的裝置終端和遠端子站在乙個區域網內不經過路由時就會報錯,系統無法執行。經驗證確實是這樣,只有經過一層路由就沒有問題。而我們的裝置是用在地下隧道內,都是直接經過交換機沒有路由。跟蹤發現w5500在遠端客戶端進來建立socket時出錯,剛建立socket就會非關閉狀態直接返回。然後就一方面聯絡w5500官方,另一方面聯絡軟體包作者,rtt官方。但w5500深圳和香港總部都說w5500肯定沒有問題,已經有那麼多裝置在使用不可能有這個問題,而rtt他們沒用過,不熟悉;軟體包作者不能遠端,不能**,rtt的維護者也不方便建立類似環境來驗證問題。為此我將三方人員聚集在乙個群裡以商討解決這個問題,眼看專案就用施工安裝了,卻暴露出這個乙個天大問題,如果解決不了,專案整個就泡湯了,這個後果我是無法承擔的,早期開發不出來就算了,這已經和第三方商定好了施工日期了突遭變故,這怎麼辦?後來我自己發現建立socket失敗後短延時可以降低失敗頻率但不能杜絕;最後rtt給出遮蔽rtt的檢查網路連線部門**的方案,暫時算是解決了這一問題。有驚無險的化解了該危機

月滿則虧,花滿則衰。因為不夠完美所以才會有完善,才會有進步。記得有人說過,乙個人最好的狀態不是圓滿,而是含苞未放之時,因為此時有無限之可能,在此過程中的積累將是以後最寶貴難忘的記憶。在與rtt共同成長過程中,自己的一些意見在rtt論壇和studio工具中得到體現,這讓人有一種滿滿的參與感,自豪感也油然而生。

最後還有幾點建議:

官網的軟體包可以按使用者進行收藏管理,用過的,對新增加感興趣的,可以分類管理。因為同一功能的軟體包有多個,自己用過覺得好的(不一定是星數多的)可以有些備註和感悟,並且有時候自己還需要適當「修改一下軟體包」以用來避免一些錯誤和更好的適配。且隨著軟體包庫的增多,沒有自己的收藏管理,在汪洋的乙個個軟體包裡面,不知道那些是重要的,好用的,值得關注的。

每個軟體包的管理者提高對github的瀏覽速度,這個是對分類軟體包問題的集中之地,可以說比論壇更容易分類查詢相關問題,如果長期得不到回應的話,就讓使用者和後來者對軟體包質量失去信任,不利於軟體包的有效利用。

推出或與tracealyzer合作,讓studio或rtt能使用該強大工具進行錯誤定位,任務瓶頸和優化分析。因為在大家學會核心/ipc通訊同步之後,經常要面臨任務設計不合理協調不暢,嚴重影響系統的效率。在hardfault定位方面,雖然cmbacktrace可以簡單定位一下範圍,但是還是不直接,使用的難度和有效性沒有tracealyzer好,這麼好的工具希望早一點能在rtt上看到,那將是大家的福音。

寫在最後:

開源軟體的發展和繁榮,中國國產優秀軟體的崛起需要大家共同的努力,中國不缺乏夢想之人,也不缺實幹家,國外人能做好的東西相信在勤奮踏實肯幹的中國人面前也一樣不是問題。只要我們群策群力,善於革自己的命,勇於學新東西,勇於改變,有一定能將rtt做成國產最優秀的微作業系統,一定能將rtt發揚光大!!!

最後希望大家關注我的部落格和論壇位置,以後還會不斷更新有關rtt相關的技術問題的文章,拋磚引玉,希望能與大家成為志同道合的朋友,一同成長!

RT Thread學習記錄12 郵箱的使用

1.郵箱的工作機制 rt thread作業系統的郵箱用於執行緒間通訊 郵箱具有資料互動功能,但互斥量 訊號量等ipc沒有資料互動功能 特點是開銷比較低,效率較高。郵箱中的每一封郵件只能容納 固定的4位元組內容 針對32位處理系統,指標的大小即為4個位元組,所以一封郵件恰好能夠容納乙個指標 執行緒或中...

公尺新江,我的老師(語錄)

怎麼說呢,在tgb已經4個多月了。而在tgb裡面我感觸最多的就是公尺老師說的那些 金玉其中 的至理!公尺老師講的好多話,剛聽到時,覺得也就那樣。但是過後自己回想起來時又是一番不一般的感受。下面這些公尺老師講過的是給我感觸最深的話,謹藉此機會分享給大家。1 多乙個朋友,多一條路 多乙個仇人,多一堵牆。...

2023年12月28日,我的linux筆記。

掛載的資訊都記在 etc mtab 和 proc mounts裡面了,mount命令顯示的就是這兩個檔案的內容。這是為了其他程式的執行。如果不想要掛載的資訊記在裡面,mount命令用 n選項。在單使用者模式中,檔案系統以readonly掛載,要使他變成可讀,用命令 mount n o remount...