作者sedgewick (三分熟的鬧鐘)
看板Soft_Job
標題Re: [閒聊] 要如何精進RTOS技術
時間Sat Mar 15 21:27:09 2014
※ 引述《ccccboom (西西)》之銘言:
: 目前在MCU寫RTOS的code
: 不過也只是去call API而已
: 請問如果想要精進(=可以開更高的薪水)
: 應該先去讀RTOS SDK的code,
: 還是開始寫Linux的RTOS?
: 謝謝
說到 RTOS, 最近我也遇到一些好玩的路線之爭...
以前最常聽到的就是「RT-system 怎麼可能還包一個 OS 進去?」
同時檯面上所有台灣的 design house 都會聯合起來講 RTOS 不堪大用.
但奇怪的是, 最近顯然有越來越多的研發團隊投到這個方向.
而且不只發生在台灣(台灣恐怕還是隨波逐流, 後知後覺的結果. )
裡面還有很多 big names 哦...
當然 Microsoft 那是不用講, 此外最明顯的是 Google...
想像一下 RT-Android, 這個野心夠大吧?
又譬如 nVidia, 我也想不到他們會去弄 RT-system.
然後呢, 連 Apple 也在做.
我要特別強調一點, 這些都不是前瞻性的學術研究.
而是真正進入產品端的設計.
所以不會看到這些公司發佈「某某團隊正在設計次世代的 RTOS」云云.
相反地, 會直接看到 application design, 帶著 real-time behavior.
那我說的路線之爭是在爭什麼?
所謂的 RT-system...
到底應該著重於硬體上的響應時間、分時精確度... 等等.
然後滿足設計需求?做 MCU 的大概都是這一派.
或者反過來是符合設計需求的前提下.
去調出一套即時系統?做 ARM, GPU 的大概都是這一派.
兩者中間還有一個角色很尷尬的 DSP designer.
也不曉得該說兩邊討好還是兩邊不討好.
會寫在 Soft_job 這個版, 我顯然是站在 ARM 這一派的.
因為我覺得保持運算彈性這件事遠比當個時鐘重要.
用 MCU 好不容易拼湊出 FFT...
結果人家冒出來說我們要的其實是 DFT.
然後另一邊又跳出來說, 不管是 FFT 或者 DFT 都是老掉牙的技術了.
請問有沒有 Haar wavelet transform 可用?
路過的鄉民又說, Haar 也好意思稱人家老掉牙.
那我手上的 MCU 怎麼辦?這樣幾行爭論就可以死五次.
但 MCU 派也不是省油的燈.
他們說, 我們有偽裝成 MCU 的 DSP 可以用.
你加掛一顆 ARM 已經夠我們加掛四顆 MCU 還有找.
尤其這個年代別說什麼 FFT/DFT 那些發霉的東西了...
只要講得清楚, 連風洞模擬都做給你.
它們也是很好玩的組合...
這些 DSP/MCU 旁邊還是會有個 CPU, 上面跑一個 OS.
只是這個 OS 的 real-time challenge 「在想像上」就相對地小很多.
當然這個想像有可能是錯誤的.
可是至少 MCU 派可以保證即時性、運算速度、耗電量、設計單純與成本.
唯一的問題只是軟體開發的彈性很低.
而且是非常非常低, 一大堆封閉的自有架構.
至於 ARM 這一派的優缺點則完全反過來.
可是不管內部爭論或者外部環境, 我都看不出來哪個選擇才是正確的.
目前卡在一個不上不下的狀態就是了, 講給大家聽聽.
--
新詩練習:新鮮。踩破初春裡的狗大便;不經意的滄桑,滿溢著嫩黃的喜悅。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 1.170.133.60
→ dophin332:摻在一起做塞尿牛丸,保持整個solution的cost與彈性 03/15 22:53
推 za7788az:快拜請jserv 03/15 23:33
推 damody:各有優缺,像microchip的優點就是短路不燒mcu 03/16 03:12
→ damody:應該說很難燒壞,所以比較穩定 像arm一不小心就燒壞了 03/16 03:13
→ damody:有些更需要奇怪溫度奇怪電壓的更會希望用簡單元件解決 03/16 03:15
→ damody:連mcu都不要用最好 03/16 03:15
→ damody:當然也可以接多一些元件來解決 arm 需要精密的問題 03/16 03:17