久久国产成人av_抖音国产毛片_a片网站免费观看_A片无码播放手机在线观看,色五月在线观看,亚洲精品m在线观看,女人自慰的免费网址,悠悠在线观看精品视频,一级日本片免费的,亚洲精品久,国产精品成人久久久久久久

分享

KEIL RVMDK VS IAR EWARM

 guitarhua 2015-03-29

KEIL RVMDK VS IAR EWARM


項目實戰(zhàn)比較(誰更有效率,?)?。?/span>

http://bbs./BLOG_ARTICLE_1741482.HTM

    KEIL 和 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略勝一籌,。不過話又說回來,,事物總會在變的,這些只是工具而已,,羅布青菜各有所愛吧,。

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,,不代表本站觀點,。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,,謹(jǐn)防詐騙,。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報,。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多