tag:blogger.com,1999:blog-3106091275855855777.post5424579407098910332..comments2024-03-28T10:33:24.959+08:00Comments on ChamberPlus System Level Studio: USB DIY--自學計畫_CAN Bus Application (一) --- 前言ChamberPlus Taiwanhttp://www.blogger.com/profile/15411773154295502356noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-3106091275855855777.post-53270428662271393462018-12-05T18:32:42.315+08:002018-12-05T18:32:42.315+08:00優質文章優質文章sfdhttps://www.blogger.com/profile/13627288855712249567noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-5956074498782136652018-01-16T23:53:48.378+08:002018-01-16T23:53:48.378+08:00我剛進這一行時,是做 Scanner SOC。因為那時用C 的觀念還沒有,(那時Keil 也還是
...我剛進這一行時,是做 Scanner SOC。因為那時用C 的觀念還沒有,(那時Keil 也還是<br /><br />不是很普及),而且當初為了成本,用組合語言是不得已的時空背景。<br /><br />當然缺點就是當初的FW 就得集中在少數關鍵人物身上,也或許這樣子,我才可以剛入行<br /><br />就可以以一個產品奠定下不錯的基礎。之後接下MP3 SOC 就已經完全以C 平台處理了。<br /><br />因為牽涉到記憶卡的 File system,那根本不是組合語言的可以處理的。也需要團隊。<br /><br />我又以一個產品完成韌體程式的轉型成長。我很幸運...在這個過程中沒有浪費或是走過<br /><br />甚麼冤枉路,甚至也沒有幹過太多重複性的開發工作。<br /><br />其實我看過太多工程師做過太多重複性的開發工作,而不懂得思索與改變,<br /><br />到最後都變得有點怪怪的,當你繞不出來時,老闆自然就會找你"麻煩"了,<br /><br />你既然不懂得改變,那老闆就幫你了囉。至少我覺得這樣子還是一件好事,因為可以看到<br /><br />彼此成長,萬一你不改,老闆也不懂得改,最後其實是兩敗俱傷的。<br /><br />這說起來有點無奈,但這也是沒辦法的事:搞科技與技術,是永遠不等人的,<br /><br />不是產品技術改變,就是市場觀念要改變,所以最後我從這裏面悟到一個道理:<br /><br />你問我還要學甚麼?或是我會不會擔心自己以後會因為跟不上而失去競爭力?<br /><br />不會,就是因為走過這些之後,自然就更懂得如何在短時間內去掌握一些關鍵重點。<br /><br />與其原地踏不前(就是一直困在重複性工作裡)或是亂槍打鳥的到處蜻蜓點水式的東摸摸,<br /><br />西摸摸的,真的不如主動出擊的去接觸系統應用市場。讓自己更全面的接受挑戰,<br /><br />自然在心態上就有自信,也更健康的迎向未來。這一點真的比窩在家裡搞MCU 、APP等<br /><br />好很多了。或許大家可以思考與參考看看吧。<br /><br />反正這一行走到今天如此環境,對你我來說:也沒有比眼前這個情況糟糕了。<br /><br />那你我還有甚麼好擔心的呢?你說對不對啊?<br />ChamberPlus Taiwanhttps://www.blogger.com/profile/15411773154295502356noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-39632069515392836682018-01-16T17:42:14.227+08:002018-01-16T17:42:14.227+08:00STM32的HID也吃了一次虧。後來是用手機APP抓到。在軟體人員進來前就寫好部分功能。
後來軟體改...STM32的HID也吃了一次虧。後來是用手機APP抓到。在軟體人員進來前就寫好部分功能。<br />後來軟體改了,再來就不是我可以控制的。但至少硬體除錯就很快過去了。Beehttps://www.blogger.com/profile/03820211638232445760noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-19006417049684231492018-01-16T17:29:13.951+08:002018-01-16T17:29:13.951+08:00技術海...現在覺得是常態了。問題在於如何選,如何評估。
年輕時技術數目不足,硬要用,和老闆鬧翻。是...技術海...現在覺得是常態了。問題在於如何選,如何評估。<br />年輕時技術數目不足,硬要用,和老闆鬧翻。是有學到,但也付出代價。<br />現在,已是掛資深,其實沒有特定領域,反而要使用以前的經驗去做評估。用了RTOS會出什事?不用又會如何?<br />老闆不會照你想的發展,所以公司每一項產品,我早已想好下一代要如何做,Cost down要如何做。然後等老闆出招。要用的技術先查好,小玩一下,以免要上了找不到人問。<br />公司可能的未來產品也要去想,老闆閒下來一定會問,也是準備好了答案。<br />但...老闆總是去找來不相干的產品來做。這就不是算得到的。Beehttps://www.blogger.com/profile/03820211638232445760noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-43908082063548526812018-01-16T16:57:06.272+08:002018-01-16T16:57:06.272+08:00我也同意這個看法,
想想自已的FW學習,
也是從FLAG51開始用組合語言學習的,
慢慢的看了一些比...我也同意這個看法,<br />想想自已的FW學習,<br />也是從FLAG51開始用組合語言學習的,<br />慢慢的看了一些比較大型的案子後,<br />才了解也體會為什麼C在這個領域會這麼受歡迎,<br />也了解程式碼的重用與多人合作開發時的壓力與整合的麻煩,<br />回頭看看,<br />還真的是不經一事不長一智,<br />(這句話真好,<br />不管用在人生經驗還是工作經驗都可以用<br />XD<br />)<br />不過,<br />也因為是FW的coding,<br />難免會與底層硬體牽扯較深,<br />有時連原廠提供的HAL也不見的是動作正確無誤的,<br />難免會有bug,<br />就比如說STM32的USB,<br />如果用它的CubeMX直接用Custom HID設定完,<br />flash program後,<br />系統是認不到它的,<br />這不是STM的錯,<br />但是這就考驗FW工程師對這一個週邊熟悉度了。<br />幸好這會由時間來解決的,<br />只是在當下趕時間時,<br />就像鄒大說的老闆不會給你時間去適應新硬體的,<br />這也是我還在技術海中浮浮沉沉的原因......<br />別讓自已別被技術的浪潮給淹沒了。小烏龜https://www.blogger.com/profile/10391597376042578020noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-88317461627829700692018-01-16T15:36:54.081+08:002018-01-16T15:36:54.081+08:00同意。
這個觀念就像以前我舉過的例子:你說碗筷對於生活重不重要?當然重要。
但還有多少人或工程比...同意。<br /><br />這個觀念就像以前我舉過的例子:你說碗筷對於生活重不重要?當然重要。<br /><br />但還有多少人或工程比重的人會去研究:筷子或碗該需要改成甚麼樣子嗎?<br /><br />你說 8 bit MCU 還有沒有市場?當然有。就像筷子和碗一樣。餓不死也賺不了大錢。<br /><br />那好~ 那還要不要改作 32 bits MCU ?這個要好像已經不是甚麼答案了,而真正的答案<br /><br />應該就是您所說的這件事了。但我看到許多國內MCU 廠所推出的 32bits MCU 也好像沒有<br /><br />創造不同於早期以 8 bit MCU對應國外MCU 廠的那一種市場價值。也只不過就是你有,我也有<br /><br />而已罷了。之後呢?...但不同的是:以前搞 8 bits MCU 只要小貓兩三隻就可以開幹了。<br /><br />但現在完全不同,誠如你所說的:原廠必須給C的原碼驅動。整合一定的底層架構,<br /><br />甚麼 RAL(Registers Access Layer)或是甚麼 HAL (Hardware Access Layer)等等。<br /><br />甚至都還給個 RTOS 平台驗證範例。... 結果還是缺系統應用的最後一哩路:<br /><br />也是你說的:合併整合程式系統驗證。所以呢?這也是就是我當初在多核心MCU 公司看到的<br /><br />盲點。8 bits MCU 可不可以做這些?那如果是你的小孩子,你還會讓他去做這些產品嗎?<br /><br />最後有一個軟體工程師的故事:<br /><br />NASA神級女工程師!她寫的代碼讓人類登月、2次解救太空危機<br />http://plays01.com/view3/?p=68986<br /><br />最後一段話很值得思考:<br /><br />因為“別無選擇,只能成為先驅者,沒有時間成為初學者”。<br /><br />所以啊~對年輕的工程師們,你們要更懂得把握許多未來未知的挑戰。<br /><br />唯有如此您們才會有更好的未來機會。<br />ChamberPlus Taiwanhttps://www.blogger.com/profile/15411773154295502356noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-70569763682275526622018-01-16T13:32:31.836+08:002018-01-16T13:32:31.836+08:00回頭看一下歷史。
1998年我就業時MCU都是8位元,多是8051,大家都在寫組合語言。我看到C會起...回頭看一下歷史。<br />1998年我就業時MCU都是8位元,多是8051,大家都在寫組合語言。我看到C會起來,和老闆提用C做案子,被否決,原因是反應太慢無法用。<br />2002年,公司開始用C語言做案子,因為引用16位元的DSP進來。DSP用組合語言寫演算法容易出問題,所以老闆同意用C。我提出應用RTOS做為主結構,公司也買了。結果我做起來比8051反應還慢,案子換人重來,我也離開了。<br />2011年,開始用ARM,重新安裝RTOS,結果三個人一起寫程式,寫不同的IO,三個月完成案子。IO之間沒有干擾問題。若非RTOS,合併程式必然有IO時序干擾。<br />現在沒人在組合語言了。而且只會組合語言現在也不好開發了。廠商只給C的原碼驅動,用組合語言變成要自己再寫一次。<br />再下來時代,RTOS是基本,會變成函式庫拼裝時代。網路上的函式庫上萬個,很多都是一堆人看過用過除錯過,實在沒有時間再去重寫。若沒有O.S.能用的函式庫只剩下幾百個。<br />硬體會進步,請考量進去。不然未來就沒有路了,老闆不會給你時間去適應新硬體的。Beehttps://www.blogger.com/profile/03820211638232445760noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-40268585948888661922018-01-11T15:59:49.147+08:002018-01-11T15:59:49.147+08:00Jean J. Labrosse 的專訪:
https://www.eeweb.com/featu...Jean J. Labrosse 的專訪:<br /><br />https://www.eeweb.com/featured-engineers/interview-with-jean-j-labrosse<br /><br />我發現:很巧,他也做過引擎控制器(噴油及點火)的韌體設計。<br /><br />從這一篇專訪,剛好也可以提供許多這方面領域的工程師們一點參考價值。<br /><br />尤其是最後一段,也剛好呼應我之前文章提到的觀點。 <br /><br />新一代的微處理器在提升其效能之後,也會慢慢地提供各多工程師們來共同維護一套<br /><br />微處理器的韌體系統,就顯得OS 平台的重要性了。ChamberPlus Taiwanhttps://www.blogger.com/profile/15411773154295502356noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-85484186098854681262018-01-11T14:02:51.384+08:002018-01-11T14:02:51.384+08:00千萬別稱小弟為大大...小弟就是一個一事無成的中年人罷了,只是有一些失敗經驗可以分享,哈哈哈
其實...千萬別稱小弟為大大...小弟就是一個一事無成的中年人罷了,只是有一些失敗經驗可以分享,哈哈哈<br /><br />其實uCOS2的歷史很有趣,他的作者 Jean J. Labresse 是唸電子出身的,當年他也不是一開始就靠uCOS2吃飯的,他是在工作上用了某家公司的RTOS覺得很難用,原廠又愛理不理的,就決定自己自己DIY一個(當時是1991年),結果發表之後受到熱烈回應,至此之後他也從員工變成老闆開創自己的事業<br /><br />這個故事恐怕比吵說要不要用RTOS還要有意義,不知道各位先進以為如何?Goodspeedhttps://www.blogger.com/profile/08502416651306399363noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-91685892283374862302018-01-11T12:44:05.460+08:002018-01-11T12:44:05.460+08:00你不用太在意啦。沒有所謂的失敗之說,總是一種學習嘛!
懂得自我檢討,就會懂得改進,其實對未來許多工...你不用太在意啦。沒有所謂的失敗之說,總是一種學習嘛!<br /><br />懂得自我檢討,就會懂得改進,其實對未來許多工作都很有幫助的。<br /><br />至於該用那套RTOS?這都很難說的啦,你也不用去奢望老闆們能夠了解或支持之類的。<br /><br />我在引擎ECU 之中也用一些簡單的分時多工概念的東西。雖然還稱不上甚麼RTOS。<br /><br />但後來我自己許多應用中,都用得得心應手,甚至我在以前開發MP3 SOC 時,<br /><br />我還是繼續用,後來我部門一位台清交資工員工,幫我在這個平台再加入一些State Event<br /><br />機制,結果不管在UI、顯示及許多上層應用軟體,都讓許多人得心應手,就連大陸許多<br /><br />客人與工程師們都讚不絕口。我老闆當然不懂,我只是覺得我能很快地把工作做好,績效<br /><br />做得出來,他們就覺得滿意了。我哪需要自己跟他們講一大堆有的沒有的....<br /><br />這種事情最後只有做過的人自己懂,別人很難體會的。<br /><br />至於是uCOS-II或是 FreeRTOS 等,就只是讓比較沒經驗的人有一套可以依循參考的例子。<br /><br />就像一個工具會用的,應該就會隨時拿出來用。用這些比較好的是:當別人問或是要作一些<br /><br />教育訓練時,還可以推給網路,叫人自己K~呵~呵~不用像我以前還要自己搞教材做教育訓練。<br /><br />不過,GodSpeed 大大說的:或許也是因為如此,我後來在許多上台場合,就比較懂得技術<br /><br />解說拿捏的尺寸吧。也算是另一種收穫。<br /><br />所以我才說:沒有所謂的失敗之說,就是一種訓練與學習吧。<br /><br />加油!ChamberPlus Taiwanhttps://www.blogger.com/profile/15411773154295502356noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-57391056709268633112018-01-10T16:51:10.077+08:002018-01-10T16:51:10.077+08:00看了chamber大哥與諸位先進們的討論,
我也不斷的問自已是不是也因那一股"傲氣&quo...看了chamber大哥與諸位先進們的討論,<br />我也不斷的問自已是不是也因那一股"傲氣"而造成諸多的失敗?<br /><br />其實就Godspeed大所說的沒錯,<br />以我的經驗來看,<br />RTOS的使用與否,<br />Flash ROM size佔了極大因素,<br />其實如果FW工程師可以決定是否使用RTOS的話,<br />我想應該九成以上都會選擇使用,<br />不用與底層硬體牽掛太深,<br />又可以不用太顧慮軟體的效能,<br />何樂而不為呢?<br />但能作這個選擇的往往不是該任務的執行者,<br />而是再上層決策者,<br />再來以台灣系統的公司,<br />決大多數以成本先決,<br />以及上層的技術決策者應該大多數也不想去考慮技術決策的問題,<br />所以<br />能怎麼cost down就怎麼cost down<br />自然而然,最終的選項就又回到原先的老路了......<br /><br />小烏龜https://www.blogger.com/profile/10391597376042578020noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-24966536123839558052018-01-09T23:06:46.865+08:002018-01-09T23:06:46.865+08:00"若是MCU的容量是每年縮小,我支持不學OS是對的。
未來十年的MCU仍會只有數KB?只能..."若是MCU的容量是每年縮小,我支持不學OS是對的。<br />未來十年的MCU仍會只有數KB?只能在數KB上開發的工程師,你認為薪水會好?"<br /><br />---對,這些工作有太多可取代性了。就留給年輕工程師入行練兵用,我們就不要再跟人家<br />搶飯碗了。至於系統的發展之所以會走到模組化,代表著就是會引進所謂的中央控管觀念:<br />那就是OS。當所有的MCU 都有這樣的機制平台之後,接下來,一切需要的就是系統整合測試。就連整合測試也會在這樣的平台下進行。<br /><br />就以我們搞車用電子,也都走向系統OS 平台化了:AutoSAR 。也已經發表到 4.1 版了。往後沒有這些OS 平台,你怎麼跟人家搞互聯網?車聯網啊?<br /><br />"雲端編譯,手機燒錄。<br />PC無需使用" <br />---- mbed 是ARM 搭配他們移動裝置所提供的開放OS 平台,其企圖心也無容置疑的。<br />這個絕對是趨勢。不懂搞這些的以後大概就只能分到麵包屑吃吃而已---就是你只能搞周邊<br />那些小玩意,最後賺大錢的就是利用平台賺大錢的人。<br />喔~你會IO:那就搞幾片給我,不過要記得喔:也要提供作業系統平台的介面喔。<br />你說:您怎麼賺別人的錢?<br /><br />"Wifi,BLE,USB及NFC"... 這三種裡面只有一個不是無線介面,雖然我是搞USB的,但我還<br />是得面對現實,這四種裡面發展空間最小的可能就是USB 了。他最多大概只能當Tools用<br />而已。要主流可能比較難。<br /><br />@Godspeed:我跟你說啦,話雖然如你所說的:"如果能找到一個好的市場,裡面的系統應用管他用8/16/32/64 bit相信工程師的待遇都不會太差的" ---這一種東西是越來越少了啦。<br />以前或許我們會用這種話鼓勵年輕人或安慰自己,但要能從系統應用整合搞到說:管他用8/16/32/64 bit都是好方案,其實有很多東西也都跳脫我們從MCU 看事物的角度了。<br /><br />舉一個簡單的例子來說:Gogoro 被人家吹捧的像是甚麼高科技產品似的,<br /><br />結果就被一個龍頭電子鎖給搞得像裡外不是人的豬頭。你說:這個電磁閥用8/16/32/64 bit<br /><br />MCU 有差嗎?誰管他用甚麼MCU啊?結果人家是要看機電整合到產品測試驗證不能出問題<br /><br />啊?所以我才體會很深的告訴各位:工程師~啊有時真的不要太鐵齒,也不要有那一股"傲氣"<br /><br />。否則要你真的從系統應用整合過程中,還有你的罪受的囉。<br /><br />這點相信我說:以後或許可以從我的部落格故事中看到這樣子的故事的。<br /><br />(其實已經經常發生在我周遭了,此時還不太方便講得太明白而已!)<br />ChamberPlus Taiwanhttps://www.blogger.com/profile/15411773154295502356noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-91040077538118140442018-01-09T17:05:31.626+08:002018-01-09T17:05:31.626+08:00從大環境來看跟你會8bit/16bit/32bit MCU其實關係不大(或者是玩幾KB還是幾MB f...從大環境來看跟你會8bit/16bit/32bit MCU其實關係不大(或者是玩幾KB還是幾MB firmware)有些行業已經被玩爛了,淘寶一搜那個價格可能是你出手的成本價<br /><br />所以回過頭來...還是要如ChamberPlus老前輩講的,要從系統應用倒推回來看需要什麼,RTOS是支微末節的東西,如果能找到一個好的市場,裡面的系統應用管他用8/16/32/64 bit相信工程師的待遇都不會太差的Goodspeedhttps://www.blogger.com/profile/08502416651306399363noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-9959095829778581122018-01-09T16:53:01.357+08:002018-01-09T16:53:01.357+08:00就個人目前開發的案子來看。MCU去連手機這個趨勢根本無法避免。手機只有四種連接方法:Wifi,BLE...就個人目前開發的案子來看。MCU去連手機這個趨勢根本無法避免。手機只有四種連接方法:Wifi,BLE,USB及NFC。此三者皆無法以8位元MCU可以有效使用。是有部分案子可用,但程式碼很特別,且沒有剩下多少空間給使用者,功能也不完整。Beehttps://www.blogger.com/profile/03820211638232445760noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-47655255755439933802018-01-09T16:17:12.935+08:002018-01-09T16:17:12.935+08:00https://www.androidauthority.com/mbed-everything-y...https://www.androidauthority.com/mbed-everything-you-need-to-know-605491/<br />雲端編譯,手機燒錄。<br />PC無需使用Beehttps://www.blogger.com/profile/03820211638232445760noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-58499320622817884422018-01-09T16:00:38.210+08:002018-01-09T16:00:38.210+08:00若是MCU的容量是每年縮小,我支持不學OS是對的。
未來十年的MCU仍會只有數KB?只能在數KB上開...若是MCU的容量是每年縮小,我支持不學OS是對的。<br />未來十年的MCU仍會只有數KB?只能在數KB上開發的工程師,你認為薪水會好?<br />我會用OS不是為了技術,而是為了未來的適應力。<br />現在OS的書也很多,我為了數KB的MCU也創造出一套多工系統,只是那是不得已時才會用的。<br />也有人說想學MCU,我真的建議不要去拿8/16位元MCU,老是為了數KB在想程式如何精簡,往往又引不很奇怪的問題。像是要做和中斷內的變數保護等等問題,這些問題又不好解。<br />MCU真的不是一個薪水會漲的行業,還是會配合AI。<br />技術還是要往前看才是。Beehttps://www.blogger.com/profile/03820211638232445760noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-90420320722368217112018-01-09T12:04:37.513+08:002018-01-09T12:04:37.513+08:00沒錯,兩位大哥都講得很好。
我自己也是可以承認自己的毛病,我的程式都得要壓在幾K 以內,我哪來的O...沒錯,兩位大哥都講得很好。<br /><br />我自己也是可以承認自己的毛病,我的程式都得要壓在幾K 以內,我哪來的OS?<br /><br />又這一種小程式,自己一個維護還差不多了,還要搞一大堆人進來攪局?<br /><br />這些都是我們這些老傢伙的毛病,也是不懂得長進的人。<br /><br />我跟你們說:那怕現在MCU 的程式容量資源都已經不可同日而語,但還是有一堆老人家<br /><br />還是像我這一種老習慣的老毛病。寫韌體程式還是老方法... <br /><br />為什麼?對啊~你們說得沒錯,我幹嘛還要去研究人家的函數庫,去架設一個OS 在系統內?<br /><br />就我們一兩個人寫的程式還需要這麼麻煩嗎?<br /><br />但很不幸的是:現在簡簡單單的系統,已經不是我們以前那一種觀念可以應付的啦。<br /><br />我們那一種觀念,講難聽一點,人家原廠給個範例程式就可以了。一些簡單應用都沒啥問題<br /><br />讓甚麼介面打通、要讓馬達轉啊,都輕而易舉的事,其實接下來最難的就是因應許多不同<br /><br />應用所產生的問題。全都是會糾結在一起的問題...<br /><br />就像我們為什麼就非得用CAN Bus 不行?難道UART/RS232/RS485 不行嗎?<br /><br />這些都是牽涉到許多系統應用的眉眉角角的。這些都不一般人所能體會的。<br /><br />尤其是那一些專門搞 SOHO 族,或是一些小公司,接小案子的人所能理解的。<br /><br />(這也不能怪他們,每日為三餐勞心勞力了,還有甚麼時間研究這些呢?)<br /><br />各位都是很幸福的人,因為都曾經待過大公司或是工作上需求,而有非用不可的動力。<br /><br />我現在的確可以深深的體會這一點,因為同樣的MCU 讓我挑,我就真的不會再挑以前<br /><br />那一種小小的MCU 了,倒不是因為CP 值的問題,而真的是有想到兩位大哥所提到的<br /><br />OS 觀念問題,所以大家如果還真的有興趣,或有機會的話,就不要在用我們以前那一套<br /><br />方法在學MCU 了。(我就很奇怪,現在坊間許多教新程式語言的電腦叢書,還像我們以前<br /><br />那樣:第一章 I/O,按鍵、LED 跑馬燈,第二章:LCD ...,真的搞不懂耶!)<br /><br />反正痛苦就只有一次,以後就受用無窮了。<br /><br />各位看倌啊,真的,上面兩個前輩講話,所提供的意見真的要聽。我的方法就不要學了。<br /><br />這真的是過來人的心聲。ChamberPlus Taiwanhttps://www.blogger.com/profile/15411773154295502356noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-18869510746129384622018-01-09T11:30:41.594+08:002018-01-09T11:30:41.594+08:00其實真要看懂也不難,像uC/OS-II就有出書,還一行一行解釋給你看,小弟這種爛私立大學都看得懂,各...其實真要看懂也不難,像uC/OS-II就有出書,還一行一行解釋給你看,小弟這種爛私立大學都看得懂,各位精英應該小菜一碟<br /><br />其實一堆人不用,不是因為看不懂,而是覺得沒必要,看不出RTOS能給他什麼好處,覺得增加我程式的複雜度,我自己的系統應用都做不完了還搞這個?所以uCOS2作者在書上花一整章解釋有RTOS跟沒有RTOS差在哪裡?<br /><br />如果是寫習慣 8bit ROM size 只有幾 KB 到幾十 KB 的 8bit MCU 工程師,叫他用 RTOS 他恐怕也會覺得莫名其妙,我自己的東西都快把 ROM 塞爆了你跟我講 RTOS @%$&^&...<br /><br />個人淺見 RTOS 要到你的 code 大到要用 NOR/NAND Flash 才裝得下時,過了那個死亡交叉,才會有非用不可的動力Goodspeedhttps://www.blogger.com/profile/08502416651306399363noreply@blogger.comtag:blogger.com,1999:blog-3106091275855855777.post-86965933223173865392018-01-08T17:50:28.750+08:002018-01-08T17:50:28.750+08:00不只要善用,用別人的原始碼也很重要。MCU工程師的壞習慣是,非自己看過的函式庫就不用。大部分人不想去...不只要善用,用別人的原始碼也很重要。MCU工程師的壞習慣是,非自己看過的函式庫就不用。大部分人不想去除別人的錯。但在開放原始碼的時代,一般不是錯碼,而是誤用。如何看懂別人的函式庫如何用才是重點。<br />以FreeRTOS為例,一堆人不用,就是因為看不懂。但O.S.為何要看懂,主要是會用,要能在有O.S.的狀況下除錯。我都是用到有問題才去追OS內部,但大部分都是沒有設好,而非程式問題。<br />其他通信函式更是如此。Beehttps://www.blogger.com/profile/03820211638232445760noreply@blogger.com