簡 介： 本文內(nèi)容是在8月13日郵件接收到參加全國大學(xué)生智能車競賽同學(xué)寫來的一封郵件。其中對于公開的山東大學(xué)（威海）全向組提交的RT-Thread技術(shù)報告中所產(chǎn)生的若干疑點。針對于競賽中所使用的沁恒單片機在RAM，CPU速度等方面的不足，作者質(zhì)疑山東大學(xué)全向組報告中存在不實之處。

海韻三隊同學(xué)很快針對提出的疑問進行了書面的回復(fù)，具體內(nèi)容在本文的最后一節(jié)。
關(guān)鍵詞： RTT，智能車競賽，質(zhì)疑，沁恒單片機

01 問題來源

??卓大大你好，這是我閱讀您csdn上公布的獲得rtt專項獎進入國賽的技術(shù)報告后，產(chǎn)生的一些疑問，篇幅問題我寫成了word。如果確實有這個問題，希望卓大大能重視，如果是我自身因知識儲備不足而產(chǎn)生的誤解，希望卓大大樂一樂就好，不要在意。

??下面內(nèi)容是來自于郵件中WORD文檔內(nèi)容：關(guān)于山東大學(xué)（威海）全向組海韻三隊提交的 RT-Thread 技術(shù)報告中的若干疑點。

• 基于RT-Thread全向賽車控制算法開發(fā)^[1]

• 第十六屆全國大學(xué)生智能汽車競賽RT-Thread創(chuàng)新專項獎^[2]

02 若干疑點

一、關(guān)于RAM使用問題

??最明顯的一點是RAM的使用情況。文中作者也承認圖像處理線程sweep需要存儲的數(shù)據(jù)非常多，卻只為其設(shè)置了2KB的?？臻g，這顯然不正常，所以我對其RAM占用空間進行了分析。

??占用RAM的大頭是圖像數(shù)組。從總鉆風(fēng)傳回的為灰度圖像數(shù)組，根據(jù)作者提供的屏幕截圖，通過初略估計列像素點（數(shù)像素點），再通過圖像的長寬比例可以計算出圖像數(shù)組約為100*75。

??我采用逐飛提供的沁恒單片機 RT 開源庫，只修改圖像數(shù)組大小與作者一致，無任何其他處理程序和變量聲明，編譯后得到的存儲占用情況如下

??存入RAM里的包括data和bss的數(shù)據(jù)，即304 15976≈15.9KB，再加上作者分配的動態(tài)進程里的?？臻g5.7KB，顯然已經(jīng)超過了單片機的20KBRAM空間。這還是在最保守的情況下估計的RAM占用空間，即圖像顯示與圖像處理共用一個數(shù)組，而不是在二值化后重新開辟一個內(nèi)存空間用來存二值化后的圖像數(shù)組（CH32V103底層里的BOOL也被typedef成了unsigned char即最小的存儲單位是一個字節(jié)）。

??而采用共用數(shù)組的方法時，會有一個明顯的問題，就是在總鉆風(fēng)DMA傳回數(shù)據(jù)時，會更改當(dāng)前正在寫入顯示屏的這個數(shù)組，造成這個數(shù)組有幾行是有亂七八糟條紋的。至于DMA的問題，后面還有疑問。

??綜上所述，在作者不定義任何全局變量，僅有一些少的可憐的動態(tài)內(nèi)存還缺乏進程間通訊傳遞變量的情況下，僅僅一個圖像和?？臻g分配就已經(jīng)超出了單片機內(nèi)存，作者是如何做到讓小車正常運行不得而知。

二、攝像頭采集問題

??作者貼出了總鉆風(fēng)的配置函數(shù)，從中可以看出攝像頭的幀率是130，即7.8ms傳回一幀圖像不管單片機接不接收，而作者圖像的處理時間顯然大于這個間隔時間。

??在圖像傳回時這就可能有兩種情況出現(xiàn)，即場中斷優(yōu)先級大于進程 和 小于進程。

1、場中斷優(yōu)先級大于進程優(yōu)先級

??優(yōu)先級大于進程時，場中斷都得到響應(yīng)，打開DMA通道讓DMA硬件傳輸。DMA指向的地址就是上面說的可憐的被共用的顯示和處理的圖像數(shù)組，此時該數(shù)組會被從頭一個個地更新，要是與此同時正跑著處理或者顯示的進程（大多數(shù)情況下肯定是的，因為這兩個進程優(yōu)先級高且用時長），會造成顯示錯誤或者處理錯誤。

2、場中斷優(yōu)先級小于進程優(yōu)先級

??OK，另一種情況，優(yōu)先級小于進程，則中斷頻頻得不到響應(yīng)，好不容易一次所有進程都掛起（太巧了），場中斷得到了響應(yīng)，打開DMA通道，同樣面臨上面的問題，且DMA中斷的優(yōu)先級如何？

• 小了甚至輪不到DMA中斷觸發(fā)，根本無從發(fā)出攝像頭采集完成的信號。
• 大了你怎么保證場中斷開啟DMA通道的時機攝像頭還沒開始回傳？

??大概率得到的是一幀錯位的，不完整的，甚至根本就得不到一幀圖像。

??在我調(diào)RTT的程序時，就出現(xiàn)了這樣的問題，我調(diào)了很久最后采用攝像頭兩個中斷優(yōu)先級最高，瘋狂降低幀率到30的方案才勉強協(xié)調(diào)了這個問題，也可能是我菜，不知道大佬是如何實現(xiàn)的？

??在我看來作者的方案是不現(xiàn)實的，除非去掉處理圖像這個占用時間極多且優(yōu)先級高的進程才有可能，那么這輛車還能運行嗎？

三、單片機運行速度問題

??在該章（文章中第8章第3節(jié)）中，作者聲稱采用RTT系統(tǒng)減短了其圖像處理的時間和獲取圖像的時間，這就很離譜了，在CPU沒有超頻，沒有優(yōu)化算法的情況下，為何采用了一個操作系統(tǒng)就讓單片機運算速度加快了？

??我能在文中找到作者比較勉強的解釋是：

從并發(fā)的角度來看，各個線程在使用delay , ?事件等待這類函數(shù)時， 會總動讓出CPU給其他需要的線程。不僅書寫 delay延時函數(shù)操的心少了，整個CPU的利用率也得到了提高，最終提升了并發(fā)性。

??這就很奇怪了，圖像的處理中還需要延時嗎？

??就算有延時，將圖像處理進程掛起去執(zhí)行其他進程，OK，CPU利用率確實得到了提高，但對圖像處理這個進程來說，這個延時不是還在嗎？？？

??處理完一幀圖像的時間根本不會減少甚至?xí)冮L?。ň€程的掛起，調(diào)度，壓棧出棧等等一切操作都是需要時間的）況且一般簡單的算法處理，根本不需要多線程進行，多線程也不會帶來效率的提升反而將問題復(fù)雜化。

變量 time 代表的是獲取一副圖像的時間。每獲取一幅圖像后發(fā)送一次數(shù)據(jù)給上位機，得到的結(jié)果如圖俗稱（縱軸的單位是）?？芍猂T-Thread操作系統(tǒng)下獲取一幅攝像頭圖像的時間在1000即左右。

??更離奇的是，在采用RTT后，連圖像的獲取都得到了加速，上面討論過，在操作系統(tǒng)的情況下要保證圖像場中斷以及DMA中斷的實時性有多么困難，且圖像是由攝像頭發(fā)出的，傳輸?shù)臅r間是由攝像頭DMA傳輸?shù)乃俣葲Q定的，怎么會因為接收方換了個系統(tǒng)就變快了？所以作者根本就是在 無中生有，編造事實 。

03 質(zhì)疑結(jié)論

??該篇論文的槽點簡直數(shù)不勝數(shù)，讓人不得不懷疑其真實性。

??我不是說山威的同學(xué)就一定寫的假論文，可能只是因為我自身的無知，才會有這么多所謂的"疑點"。至少從論文中還是可以看出，作者是學(xué)過RTT的。

??我不是計算機專業(yè)的學(xué)生，這是我第一次使用單片機的操作系統(tǒng)。學(xué)習(xí)一個新的事物，在CH32V103上移植RTT也讓我吃盡了苦頭。但是直到現(xiàn)在，我還是堅持認為：在CH32V103這款單片機上像作者這樣跑操作系統(tǒng)是不可能的。就算是可能，有些設(shè)計也是拍腦袋寫出來的，不使用操作系統(tǒng)，可以做到更好。

??我的觀點可能有些是錯的，或者沒有 GET 到山威技術(shù)報告的點，但這些都不是空穴來風(fēng)，而是在我調(diào)RTT的過程中遇到過，考慮過的問題。相較于其他組別的單片機，沁恒的這款單片機顯然在RTT的適用性上差了不少，也正因此需要投入更多的精力處理而不是濫竽充數(shù)。

??所以我希望能要求山威立刻（以防連夜改出來）公開其軟件工程，接收全國車友的監(jiān)督。一旦程序被證實是假的，或者給不出來，取消其資格，并且追究其論文造假的責(zé)任。

??但我知道這個訴求大概率不會得到實現(xiàn)，這件事也大概率不了了之，畢竟 RTT的名單是RTT公司給出^[3] 的，可能查閱的專家因為不太了解比賽而以一些其他原因?qū)⑵湓u出，組委會也多一件事不如少一件事得過且過。

??怎么說呢，作為一個非利益相關(guān)者，山威進不進國賽對我也沒什么影響，但既然卓大大公布出來了，我看到了也不吐不快，希望能促成這個比賽往更好的方向發(fā)展，能少一些不公平不公正的現(xiàn)象發(fā)生。

04 回復(fù)質(zhì)疑

??我是海韻三隊的軟件隊員?，F(xiàn)在回復(fù)CSDN上對我們隊的質(zhì)疑。

一、回應(yīng)關(guān)于RAM使用問題

??質(zhì)疑者對我們圖像數(shù)組長寬比例的判斷直接目測估計100*75這一點未免也太不嚴謹了，我們真實使用的是80*60的數(shù)組，差出來的這些空間能放多少全局不量我就不說了。

??當(dāng)時我們還開了os優(yōu)化這一點非常重要，沒有在論文里提到。沒開優(yōu)化的話肯定是超出這個芯片的RAM及FLASH大小了，因為沒有對os能優(yōu)化多少空間有研究就不給出計算了。

??最后所有程序編譯一遍是剛好卡在超出大小邊緣了，以下是我剛剛編譯的結(jié)果而且并沒有臨時修改什么代碼的，RTT公司的人員應(yīng)該有我們的源程序可以讓他們編譯一遍。

??至于說公開源程序的話我是覺得不太合適的，如果要公開那也應(yīng)該公開所有通過RTT進國賽的人。如果要復(fù)現(xiàn)也應(yīng)該是所有人進行復(fù)現(xiàn)。我也看了其他人寫的RTT論文，說實話寫的也非常優(yōu)秀，但并不是所有人都對RTT的使用部分做了詳細說明，我們也是第一次研究RTT所以某些地方可能寫得不是那么嚴謹，當(dāng)時忙著交RTT論文也并沒有對所有貼上去的圖片進行檢查。

二、回應(yīng)攝像頭采集問題

??我坦白一點，可能是對RAM的分配還不怎么合理，所以小車在發(fā)10 次車還是會出現(xiàn)1次的死機現(xiàn)象，可能是因為內(nèi)存爆了吧。但是出現(xiàn)的概率比較低所以我們就沒有再對RAM分配進行最好的優(yōu)化了。然后質(zhì)疑者還提到了場中斷優(yōu)先級的問題，說實話當(dāng)時我們并沒有想到是這個問題，所以這可能是造成我們還會偶爾死機幾次的原因，謝謝你提出來了。

??然后質(zhì)疑者還提到了什么共用數(shù)組會有亂七巴糟的條紋，現(xiàn)在我澄清一下。首先我在原有的數(shù)組 mt9v034_image下又創(chuàng)建了一個放二值化數(shù)據(jù)的數(shù)組，應(yīng)該是因為os優(yōu)化的原因bss和dec確實沒有超，如果超了我們就用備用的雙核方案了。這個數(shù)組僅僅是方便我對比灰度圖和二值化圖，并不是時時刻刻在用的！！只有在調(diào)參系統(tǒng)里按下了圖像顯示頁面選項時才會跳到那個函數(shù)進行二值化并顯示，平常車在跑的時候是只用到了mt9v034_image數(shù)組的而且并不需要對數(shù)組進行二值化賦值，因為我的算法是用mt9v034_image數(shù)組灰度值大小直接跟二值化閾值進行比較來判斷這個點是趨于黑還是趨于白，這樣做的好處是省下了對數(shù)組每一個像素點賦值的時間。

??質(zhì)疑者還提到同時跑著處理和顯示的線程，額...實際上因為算法原因顯示線程是和調(diào)參系統(tǒng)掛鉤的，只在我需要調(diào)試看圖像及參數(shù)的時候才會同時開著圖像顯示，當(dāng)然不會讓小車跑的同時開著圖像了，這個明顯是常識問題我肯定不會犯錯。

三、回應(yīng)單片機速度問題

??這篇論文并不是全都是我寫的，有一部分是另一個隊友寫的，但他并沒有參與軟件開發(fā)，所有軟件算法、調(diào)參、控制全都是我一個人寫的，沒有那么牛逼也包攬其他雜活了。

??那個延時的問題我當(dāng)然不可能在圖像處理里面延時這不是傻子嗎。這一小部分可能是我隊友為了水的字數(shù)寫上去的，但是我還是要為當(dāng)時因為時間緊湊沒有嚴格刪掉水的部分而為大家道歉。

??然后質(zhì)疑者提到了處理完一幀的時間壓根不會減少，這一點我其實是同意的，但是可能是我放測試運行時間的代碼位置不對，上位機給出的結(jié)果確實是少了，但是當(dāng)時要到交論文的截止時間了所以并沒有深入探究嚴謹性，造成了質(zhì)疑者的誤解這一點我要道歉。

四、回應(yīng)質(zhì)疑總結(jié)

??最后在總結(jié)一下，說實話突然被告知自己的隊伍被舉報了還挺意外的，為什么只舉報我們山威的而不專門發(fā)一篇文章也舉報其他隊呢？其他隊的論文我也看了說實話能舉報的點比我的論文多得多吧，這一點也不經(jīng)讓我產(chǎn)生質(zhì)疑，是有人眼紅山威今年的成績而專門挑刺嗎？

??公開源程序的話我是覺得不太合適的，這設(shè)計到了我們的核心算法，如果要公開那也應(yīng)該公開所有通過RTT進國賽的人，然后質(zhì)疑者就可以從中”參考”他們的代碼了？

??這篇文章臨時寫出來的可能在用詞上和行文結(jié)構(gòu)上不太嚴謹請各位見諒。

參考資料

[1]基于RT-Thread全向賽車控制算法開發(fā): https://zhuoqing.blog.csdn.net/article/details/119652068

[2]第十六屆全國大學(xué)生智能汽車競賽RT-Thread創(chuàng)新專項獎: https://zhuoqing.blog.csdn.net/article/details/118506454

[3]RTT的名單是RTT公司給出: https://zhuoqing.blog.csdn.net/article/details/119544099