KEIL RVMDK VS IAR EWARM 項目實戰(zhàn)比較(誰更有效率,?)?。?/span> http://bbs./BLOG_ARTICLE_1741482.HTMKEIL 和 IAR Systems都是嵌入式領(lǐng)域系統(tǒng)開發(fā)工具和服務(wù)商(IDE)的供應(yīng)商,,前者成立于-1986年,,總部在德國(如今已被大名鼎鼎的美國ARM公司收購);后者于成立1983年,公司總部位于北歐的瑞典,。 二者的最著名的產(chǎn)品分別是 KEIL uVision IDE 和 IAR Embeded Workbench,。目前他們最新的產(chǎn)品(用于ARM的開發(fā)工具,當(dāng)然也可以用于開發(fā)51單片機)的IDE分別是RealView MDK -ARM(4.10)和IAR EWARM 5.40,。 對于二者,,嘿嘿,各位具有豐富設(shè)計經(jīng)驗的GGMM恐怕都不陌生吧,,估計大部分的開發(fā)人員都用過,。因為他們都可以很好的支持各種不同版本的MCU。對于不同的開發(fā)環(huán)境,,用久了,,便會日久生情。用得順不順手,,快不快樂,,或喜歡,或討厭等等,,都因人而異的,。然而我們不能不考慮這個問題:能選擇到最適合自己,更有效率的工具,,才是最好的,。 先說說本人的個人經(jīng)歷吧。 先說KEIL,,個人感覺KEIL的IDE界面比較通俗易懂,,屬于平易近人的那種,尤其軟件仿真功能做得很不錯,,各種外設(shè)的仿真都很好,,軟件仿真,沒得說,,就是栩栩如生,,不好一點呢,印象中總是那個大名鼎鼎的文字編輯的BUG了,,KEIL的有些版本對于EDIT編輯對于漢字支持,,怎一個爛字了得! 而IAR呢,界面簡潔明了,軟件仿真雖然沒那么強悍,,但仿真起來也沒什么問題,,該咋地就咋地,整體感覺——專業(yè),。不好一點呢,就是對初學(xué)者來說入來說不太容易掌握,。但用上手了,,你就會感到有安全感。 曾幾何時,,在用51單片機的時候一直用KEIL C51 這個工具,,剛剛用的時候從不考慮各種效率和技巧的問題,畢竟當(dāng)時經(jīng)驗也不是很多,,追求的是會用,。用久了,對其的各種操作久了,,對其風(fēng)格也漸輕車熟駕,,版本前變?nèi)f變也就那樣,操作仍如往常,。漸漸的便覺得KEIL還不賴,,因此再用其他工具變很容易產(chǎn)生一種排斥之感(地方保護(hù)主義,嘿嘿),。 然而現(xiàn)實總是有壓力的,,對于學(xué)習(xí),也是這樣,。很多情況下還不得不‘被’接觸其他工具,。終于有一次項目開發(fā),用到IAR,,開發(fā)IC也是基于51內(nèi)核的IC,,是TI公司的一片RF IC CC1110。剛開始確實對IAR不感冒,,總喜歡拿KEIL來做比較,,有一種本能的排斥??偢杏XIAR,,很小兒科,不專業(yè),,比起KEIL來根本不是一個檔次,。當(dāng)項目開發(fā)完的時候,又用回了KEIL C51,。但是,,后來發(fā)現(xiàn)錯了,,真的錯了。就是我們常說的,,當(dāng)你失去一件寶貴的東西的時候,,你才發(fā)現(xiàn),原來學(xué)會珍惜,,是多么的重要,。這次用了KEIL C51,竟然讓我時常的懷念起了IAR,。,。。 這是為什么呢,, 回想當(dāng)時在用IAR,,自己用得很順手,那感覺就是像座上寶馬做開發(fā)一樣,,而現(xiàn)在用KEIL,,有時你真的不得不鳥它幾句,像驢一樣的東西,。懷念I(lǐng)AR它簡潔明了的界面,,高效編譯的速度,甚至有時讓你感到它的就是對的,,錯的就是你,。想想這次用的KEIL 怎么沒有像IAR的那種感覺呢。我想這一切總會是有原因的,。 而現(xiàn)在用上ARM了,,開發(fā)IC為STM32F系列,基于ARM公司的最新內(nèi)核CORTEX-M3,。目前有個項目既可用KEIL RVMDK平臺也可用IAR EWARM平臺,。但一直想弄個明白,RVMDK VS IAR 到底誰效率更高,,下面我用同一個項目做測試比較,。希望能解開心中糾結(jié)。 測試版本: Keil uVision V4.00,RVMDK 3.5(1999-20009) + IAR EWARM 5.40(2002-2009) 測試項目: pwhid 測試性能主要從以下兩個方面來測試: A. 項目整體編譯速度 B. 代碼產(chǎn)生效率(即最終代碼大小,為HEX文件) 測試日期:2010年05月23日
測試結(jié)果及過程: A.整體編譯速度(Built ALL) 在等同配置,,即KEIL的時候要求Target 設(shè)置的Ouput項: 選上:Debug Information + Create HEX File + Browse Information 其他保持默認(rèn)(要選中C的LIST項),。 同樣在IAR環(huán)境下,需要盡量配置成等同的配置,,其他需要全部選中LIST項,。 二者,在Rebuilt All 的時候: KEIL RVMDK的表現(xiàn): 編譯的完成的速度約為17s(目測速度) IAR EWARM的變現(xiàn): 編譯完成的速度約為12s(目測速度) 結(jié)論: IAR EWARM的編譯速度要比KEIL RVMDK快!
也就是說,,在你使用KEIL RVMDK編譯同一個項目的時候你每一次,,都需要多等5秒鐘。 這一小5秒,,積累起來就成了很大的5秒了,,無形中為自己的開發(fā)節(jié)省了多少時間。 為什么KEIL需要那么長時間呢,,主要因為在編譯產(chǎn)生 Browse Information的時間太多,。 如果把這個取消掉就會快了很多了。 這里有一個使用小訣竅,,每一次都Rebuilt ALL,是不明智的,,當(dāng)?shù)谝淮蜶ebuilt All的時候 如果其他文件并無改變的話,,直接用Built 就行了,這樣編譯速度就很快了,。 B.代碼產(chǎn)生效率,。 不同的編譯器都有自己的不同之點。然而,,編譯的結(jié)果終究是要產(chǎn)生可執(zhí)行的文件,。 這次以HEX文件為例,分別在編譯器不優(yōu)化和最佳優(yōu)化這兩種情況 下作比較,。 在IDE都不進(jìn)行優(yōu)化的時候: KEIL的優(yōu)化配置選LEVEL 00,,IAR的優(yōu)化配置選NONE,其他默認(rèn),。 KEIL RVMDK的表現(xiàn): HEX文件大小為:68.5KB IAR EWARM的表現(xiàn): HEX文件大小為:48.0KB 結(jié)論: 真是不比不知道,,一比嚇一跳。沒想到同一個項目,,RVMDK產(chǎn)生的垃圾代碼真不少,。 在IDE都進(jìn)行最佳優(yōu)化的時候: KEIL的優(yōu)化配置選為LEVEL 03,IAR的優(yōu)化配置選HIGH(BALANCE),,其他默認(rèn),。 KEIL RVMDK的表現(xiàn): HEX文件大小為:53.6KB IAR EWARM的表現(xiàn): HEX文件大小為:35.7KB 在二者編譯器默認(rèn)的優(yōu)化配置時 KEIL MVDK是defualt(即LEVEL02),IAR EWARM是LOW,。 二者表現(xiàn)分別是: 53.5KB 和 45.6KB 結(jié)論: 相差8~18KB,,還是人比人嚇?biāo)廊耍u比雞嚇?biāo)离u,。 想想,,為什么KEIL MVDK的編譯效率那么低呢,如果在KEIL未被ARM公司收購之前,,KEIL的這般效率,,也不足奇怪。究其原因,,那是因為KEIL MVDK在編譯的時候都統(tǒng)統(tǒng)把文件中所有的函數(shù)編譯成目標(biāo)文件了,。但是有一些永遠(yuǎn)都不會用到的(即未調(diào)用的函數(shù))。那么如何去掉這個不負(fù)責(zé)任的編譯呢,。 有辦法,,那就是在KEIL的TARGET 選項上,要選上Use Cross-Module 和 Use MricoLib,。 這樣KEIL的優(yōu)化效率就飛速提升了,,甚至超過了IAR的編譯效率(IAR配置為HIGH,size),。 分別如下: KEIL RVMDK的表現(xiàn): HEX文件大小為:33KB IAR EWARM的表現(xiàn): HEX文件大小為:34KB 結(jié)論: 得益于ARM的鼎力支持(其實KEIL已屬于ARM的一個部門了),,KEIL的編譯優(yōu)化方面已有一定的提升。不過IAR也不賴,,編譯速度一直很穩(wěn)定,。 最后總結(jié): 在這次實測中,發(fā)現(xiàn)KEIL 在編譯速度方面確實比IAR慢一些,,而且奇怪的發(fā)現(xiàn)了KEIL每次的編譯結(jié)果有可能都不一樣,,要想得到最終結(jié)果,你可能需要多編譯幾次才行,,這一點真讓人恐怖,! 對于IAR,用得多了,,偶爾也會發(fā)現(xiàn)一些令人不滿意的地方,就是,,IAR,,有時會‘休克’,裝死,,當(dāng)然KEIL也多多少少存在一點。 至于是不是IAR本身的問題,,這個就不得而知了。 因為XP系統(tǒng)也不是很可靠的東西,。另外這次只是中等項目編譯的比較,。 以上是這側(cè)項目的實測結(jié)果,但是還不知道程序能不能跑,,穩(wěn)定性能如何,。但是無論怎樣,,是驢是馬,,跑出來溜溜就知道了。經(jīng)程序下載檢驗,,一切正常,。至于穩(wěn)定性能如何還有待測試。 如果那個網(wǎng)友感興趣可以下載到自己的硬件板上做測試,。發(fā)現(xiàn)什么問題別忘了提出來(硬件平臺為STM32F103C8或RB,,最小系統(tǒng)即可,有USB功能),,下面是我測試的程序運行結(jié)果和測試文件: 令溫馨提示一下: 這里應(yīng)該算是MDK的一個BUG,, 在KEIL MDK中,硬件仿真時,,對于數(shù)組變量的擦看,如果數(shù)組量很多時候,,你所看到的數(shù)據(jù)有可能不對,,而IAR EWARM則沒有發(fā)現(xiàn)這個問題,,我曾在21IC上發(fā)過貼(有興趣,,可以去搜搜看) 另外,編譯器的優(yōu)化,,要慎用,。 畢竟這是機器優(yōu)化,有時會出現(xiàn)一些令人驚奇的,,莫名奇妙的錯誤,。 比如說,你在函數(shù)內(nèi)部要使用一個變量的時候,,它就無緣無故的把你要想用的變量優(yōu)化掉了,,變成了永遠(yuǎn)的 unavailable ! 最好的辦法,是要對自己要寫的代碼有信心,。
呀呀USB_hid上位機及程序文件請到dz561的個人博客上下載: http://www./blog/itspy 終上PK 結(jié)果,,心底終于有點數(shù)了。整體上,,感覺還是IAR略勝一籌,。不過話又說回來,,事物總會在變的,這些只是工具而已,,羅布青菜各有所愛吧,。 |
|