看板 Soft_Job 關於我們 聯絡資訊
※ 引述《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