個人積分：10分
文章編號：7518080
個人積分：986分
文章編號：7518153
個人積分：1140分
文章編號：7518167
個人積分：114分
文章編號：7518327
scott9282001 wrote:
不然我買一台3000~4000元的導航機,什麼都有!!
可以看電視,看影片,聽音樂,聽MP3,藍牙,玩電動,但是導航的時候不順!!
你就會去思索你買這台的主要功能是什麼!!!!
Scott網友說的真好.....
小弟自己是從事網路資訊業的，所以想到的例子也是這個產業的例子。
在以往多數公司都認為只要有防火牆來擋駭客就足夠了，
但是從前兩年開始，病毒變木馬，郵件帶釣魚網頁，沒事還會被DoS攻擊。
所以資訊廠商紛紛對中小型企業開發UTM(Unified Threat Management)，就是防火牆、防毒、防駭加上防許多碗糕的設備。
但是這些設備可能因為目標市場預算的問題，都是用比較差的硬體規格，再搭上embedded Linux核心就開賣了。
只要客戶一開啟所有防xx的功能，整台機器就如同死了一般，結果只好請客戶關閉其中一兩項功能，才能順利使用。
沒錯，軟體上看起來什麼都能達成，只要RD肯花功夫下去寫。
但是搭配的硬體規格能不能匹配，這就是個問題了！
低價UTM連自己預先搭配的功能全開都不能執行了，更何況若是客戶還要求再追加功能在上頭？
沒有廠商會預先將超過軟體需求的硬體規格放在設備上，這絕對是不變的真理，因為廠商追求的是合理
的利潤。有良心的廠商堅持不開發這種低價卻什麼都有的東西，因為客戶用了只會覺得東西有問題，達不到宣稱的效果；
而不會認為這廠商真好，什麼功能都有放上去，只是我的預算不夠，沒辦法採購更高階的設備。
換成手持導航設備也是這樣，原廠搭配的硬體絕對是只比原先的軟體需求再高一些的，若是不斷追加功能，
最後的結果也只會落得像一些UTM設備一般，只好手動關閉一些功能或是選擇不升級。
因為升級的結果只會造成原本所須的設備功能都出問題。
非必取而不出眾，非全勝而不交兵，緣是萬舉萬當，一戰而定！
個人積分：6分
文章編號：7518342
個人積分：31分
文章編號：7519906
不然我們可不知道裡面裝了啥東西。說到 pure software 運算，我之前說的 2D maze 轉 3D，其實也是 pure software ，還得透過 BASIC interpreter直譯，速度上更是受很大的影響，不過在當年 80286/80386 時代的CPU，時脈不過 33Mhz 以下，運算等等也是全包了。沒錯啦，是有FPU(286, 386SX除外)，不過當年大家都用bit map 阿
圖檔不要塞JPG，塞BMP好了，反正解析度固定不需要縮放，一張圖大概要100K，1000張100MB，好像還能接受。
好像有點離題了，重點是，Garmin應該是不會把舊款升級的，不然中古200W與660，可能會很熱門。
murafrank wrote:
這我知道, 我可為他奮戰了幾個月呢XD
不過重點是在"浮點運算器"以及"Memory controller",
沒錯, 單純的話一張圖可能真的沒甚麼,
但是別忘了, 不只是Garmin, 現在台灣大多數的CPU靠的是pure software運算,
無論是2D drawing, route calculating, GPS signal process或者其他功能, 大都是用CPU去算的,
先別提route calculating跟其他的好了(以我的經驗, 在re-routing計算的時候, 533Mhz的ARM9最高會被占用90%左右),
光2D drawing就夠累得了,
pure software的2D是一個點一個點靠CPU去填資料的,
即便到了Pentium MMX時代, 記憶體早就64bit介面了, 要用這種方法去畫圖, 畫面還是挺慢的, 那麼沒有浮點運算器的ARM呢?
是真的挺慘的XD
先排除show jpeg這件事情, GPS可能要同時做的事情有:
2D MAP, Route Calculate, UI overlay, MP3 playback, Bluetooth sync, GPS signal process, POI search, OS processes, data transfer(read map,etc), TTS(maybe amr decode?), 圖資解壓縮, 甚至未來的TMC等等,
就算不考慮CPU好了, 來看看目前比較常見用在GPS上的SD RAM吧, 跑133Mhz好了, 跟graphics溝通的read/write可能就需要7 tick的hand-shaking了, 133Mhz的SD有效時脈可能根本只有20Mhz不到~ 再以16bit來算, per-pixel的有效時脈可能只有10Mhz (因為大都是8bit controller), 而PC很早以前就是32bit BUS甚至64bit BUS了!
以上這些事情或許400Mhz的ARM9 CPU是可以勝任的,
且286時代process還沒這麼多呀 (光mp3跟amr decode以及route計算就很耗資源了)
但是呢~ JPEG是要用到浮點運算的!
ARM可沒這種東西....所以在decode JPEG很花時間,而稍微舊一點(或者便宜一點)的ARM cpu是沒有多媒體功能的,
這些CPU要幹這種事情就會很吃力.
那哪些GPS用到這些CPU呢? 嗯, 沒錯, 就是舊的機種.
那是不是真的沒辦法? 當然不是, 只要圖檔不要放jpeg就好了, 但是如果這麼做, 那就得塞很大的flash.....
可是看看以往的機種, flash有多大? Nuvi 760都只有2GB了..
當然啦, 市場考量可能是最主要的原因. 不過, 事實上舊款的硬體再加上一個jpeg decode以及search額外的POI的確是有可能很慢的, 那就沒有加入的意義了~
阿..好像寫太多了..其實我只是想表達, PC的世界跟embedded世界是完全不一樣的XD
個人積分：19分
文章編號：7523303
個人積分：0分
文章編號：7523856
個人積分：99分
文章編號：7526712
個人積分：10分
文章編號：7529588
回覆 murafrank ：
其實您多慮了！
我手上的老爺機 GONAV S900 算是慢的機種，
根本不能跟三星的 S3C2440 400Mhz 機種的 GPS 比。
但是照樣跑路口放大的軟體多達三套以上，順道不行，更不用說那些 400Mhz 機種。
400Mhz 機種可以跑路口放大的軟體更多到五套以上。
上面說明，秀個路口放大的實景圖，這根本不是件難事。
路口放大這個戰場，是 Garmin 才剛剛拿出來玩的，許多大廠早已經玩過了，
人家現在都在玩 3D 實體導航。
在 embedded 的世界裡頭，除了硬體的支援，也要軟體的 "分時多工" 技巧要搞好。
就拿路口實景放大而言，不是要即時處哩事件，是等條件成立以後，慢慢的秀出那張圖。
我所謂慢慢的秀出那張圖，對於人類來講，已經是夠快的了，是可以接受的快。
解壓縮時間根本不是問題，因為並沒有要即時處裡(Realtime Processing)。
以上是我的愚見
關閉廣告