還有。這裡其實有一種很狗屎的迷戀。

就是迷戀做上游,比如原廠。比如編譯器。

就好像做遊戲的人,好像不去做一下遊戲引擎就跟不好意思很low一樣。

我不是幹這行的,但我看過一些相關的東西——因為那時候我很關注遊戲類股票。

有一個說法是,國內很多遊戲公司都很喜歡自己做遊戲引擎,但這東西就像汽車發動機,哪那麼好做,哪能這麼快有用。

有人(我忘了是不是雲風)就說,做遊戲的都該好好去做好遊戲本身,一個遊戲不會因為你用了自製的引擎就牛逼。

其實單片機也是,你別看這東西圖裡吧唧,好像不值錢一樣。

但是你好好做,做好它,讓它用起來別讓我們這麼生氣。不至於想砸了它。這比你做什麼編譯器做什麼原廠固件都牛逼。

所以,這種鄙視鏈。說實話一開始看到評論我都懶得回復。

但想想,既然沒事刷知乎,我還是一吐為快。

還原廠是吧?

比如st,坦白說,我覺得它地底層寄存器映射做的很不錯,至少比ti曾經總得一套需要各種計算乘除映射的好的多

——違背了對指針不應該施行乘除運算這種目的不明確的操作。當然其實在這裡,我認為也不算目的不明。

只是,明明可以不這麼做的,為啥非要這麼做?

另外,包括我自己在內,最早那幾年必須說,是st的常式啟蒙了我們如何組織代碼。

但是,st庫,稍稍寫代碼的年頭長久一些,稍稍對c標準庫有更多一些的瞭解。

你的內心會各種吐槽st庫。

說實在話,不開玩笑。

這就是你們的原廠?

還有另一種極端。我曾經開發過da14580,對,就是小米手環用過的那款u,我當時也是在做手環。

那個代碼複雜的不像話,理解起來相當困難,廠商的fae自己也承認,並且不是一家這麼說,市面上很多用這款u的都這麼說。

當然這種複雜是有好處的,是為了更靈活。

簡單地說就是,他們的東西很通用很方便設置,配置。

但說實在的,一款mcu而已,而且還是flash ram那麼小的一款u——藍牙soc很多都那樣,直到後來m4成了它的新內核。

這種靈活帶來的複雜是否有必要,其實是很值得商榷的。

所以所謂原廠,有時候其實真的挺狗屎不如的。

只不過你以為他們很牛逼而已。

補充:

致所有認為2000行python一定比2000行c好寫而且更不燒腦筋的人。

你們是根本就不會寫東西,實際上我懷疑你們有沒有寫過2000行python的東西。

因為c的語句,單句本身都很簡單。

困難出在2000行組合出來的複雜度。

致所有認為只有寫編譯器或者什麼牛逼庫才牛逼的人。

那是因為你們從來就重視過業務邏輯。

只是迷戀名頭和權威。

恕我直言——我都懶得和你們說。

補充

有個評論說我怒了是的。我的確怒了!

因為寫一個2000行的模塊,其所需的腦力和辛苦,並不亞於用python寫一個2000行的代碼。

但前者很可能只是一個瑣碎的邏輯機制實現,後者卻極有可能已經是一個可以用的股票數據自動獲取並且完成自定義指標運算的半成品。

任誰都會說後者更牛逼,也更實用。

但前者是否就沒價值呢?並不是,只是它可能體現在在一個電機控制裏,它可以讓電機更平穩,更長壽。

所以這裡有一個事實

就是通常情況下,用c寫的東西通常比較多出現在大多數人都不會太注意的底層,遠不如python java那樣在人前招搖,所以論社會地位,c完敗。

然後顯然一個馬達驅動的價值,當然,除非他是發動機上用的,否則通常它也肯定比不上一個股票軟體。

所以註定我們拿的工資是肯定沒有他們多。

所以綜上所述,除非你是真愛,或者如我,深陷其中多年,又沒有人帶我脫離的機會,那麼,如果你想有錢又有面子……

媽的,滾出去!不要來我們這瞎雞巴顯擺!

淡定,淡定。

——————不淡定的下劃線————

其實是這樣的。

首先,搞mcu的通常要對硬體有相當程度的瞭解。

以至於他們經常和搞硬體的混到了一起。

本人不幸就是這樣,所以我改了,以前別人問我你幹啥的,以前我都說我寫軟體的,但後來我都說我搞電子設備的。

當然其實我從頭到尾是寫c的。

那我為什麼要說我是搞電子而不是搞設備的呢?

因為我想避免接下來那你一定工資很高吧?或者那你會不會寫個外掛或者手機app之類的問題。

因為以上的問題我都是

不會,或者並沒有。

他們信不信其實我是不在意的,反正信了又不是就會給我錢。

但是我個人覺得以我這種實際天天調板子寫應用邏輯的男人,實在不好意思說自己是做it的。

It者,information techonology

也許假以時日,物聯網真正落地,我等也加入了3c大軍,我還活著的話,我會驕傲的說我自己是搞it的,到時還請各位高薪大佬不要嫌棄。

最後我要補充一點。

很多時候搞linux搞windows甚至更牛逼的搞集羣搞大數據的,往往會很鄙視我們這種只會寫寫電子錶啊什麼的之類的 單片機老。

但我想引用一個大神說的話。

大神為了衡量軟體的複雜度,它以三大基本結構中的條件為例,他說,它會以if while等帶條件的語句數量為計量單位,作為複雜度的值。

當然,更通常的做法是,以代碼有效行數來衡量。

當然,類似linux號稱三百萬行代碼,然則大部分為驅動不算,我想,linux kernel就算了。

所以通常來說,一個10萬到20萬行的c代碼項目,其複雜度已經可以稱之為中等規模。

至於一個75萬行的c代碼,據說,其價值可以與一棟寫字樓相比。

而我自己的個人經驗,我寫過的一個遊戲面板,且包括了所有遊戲邏輯,其規模是1到2萬行——因為我認為還有很多細節要處理,當時的規模是1.5萬行。

另外說一下,我自己寫的一個帶有事件驅動的簡單圖形界面,因為單片機所以不搞什麼酷炫的效果,僅僅是一個交互邏輯,已經相當完備,其代碼規模不過2000行上下。

再以我用過的一個專業的圖形庫,軟解的,agg,cpp寫的,不過五萬行左右……

所以——

如果你們這些搞什麼高大上linux的王八蛋,自己寫的代碼行數不過2000行就足以構建一個項目的就都給我閉嘴,鄙視個雞蛋啊!

當然你們會羨慕少寫代碼多幹活很牛逼。

但現在我們是碼農,比的是寫代碼的本事好嘛?!

當然,請讓我冷靜下來,如今,搞java的賺錢比c多的多的已經是事實,搞python又比搞java有錢也是不爭的事實。

但那是建立在具有對具體業務邏輯的深入瞭解和優勢,否則,鬼才信你很牛逼哦。


不是 mcu 開發沒意思,而是他們沒有考慮到有意思的點子,很多有意思的項目都是 mcu 開發實現的,mcu 開發中也能找到樂趣


先不說錢,單從功能及興趣角度說,一步一步引導你向更高級的系統開發。

MCU處理能力弱,代碼結構主要是外設驅動,核心業務邏輯不大,也不會作運算量大的處理,通常只是完成一些簡單的任務。有時候在系統資源緊缺的時候,甚至會犧牲代碼結構,把邏輯揉在一起,完全不考慮代碼的可重用性。當然現在MCU也越來越強,各種庫,協議棧都能跑,也慢慢規範起來了。這裡分享一個MCU跑簡單神經網路的例子,相信能激起很多人的興趣。

https://blog.hackster.io/simple-neural-network-on-mcus-a7cbd3dc108c?

blog.hackster.io

當隨著你碰到的應用越來越複雜,比如MCU能處理一維的音頻信號,但是到了二維的圖像處理,單片機這個小系統似乎就很喫力了。這個時候你就需要更強大的處理器。應用級別的處理器,帶豐富外設介面,信號吞吐能力更強,功能複雜。

為構造一個強大的系統,需要規範的代碼結構,統一的驅動介面,通用的操作系統介面,由操作系統去調動外設,用戶只需要在用戶層實現自己的業務邏輯即可。讓眾多開發者可以分工合作,很快的把這個系統搭建起來,並且在不同的處理器上可以很快的移植。這應該是當精通完MCU開發之後,你所期望的需要這樣一個規範而強大的系統來拯救這個世界。而嵌入式Linux 正是這樣的一個陣營。因為處理器能力足夠強,它把原來MCU上不規範的驅動規範化,讓操作系統可以調用,而應用開發者只需在操作系統的應用層實現它的APP即可。

隨著需求的進一步加深,你的應用需要做大量的運算,而這些運算光由CPU算起來要消耗很長時間,比如圖像處理、編解碼、挖礦、跑深度神經網路等等。這時候怎麼辦,你需要專用的處理單元來做這種運算,於是這各硬體加速器就出現了,像GPU、挖礦ASIC,神經網路加速棒之類的。隨之而來的是OpenCL這種面向異構平臺的並行化的編程語言的出現,編程範圍將不僅限於CPU。而且Linux 將不再是關注的焦點,只做為解決方案中的一個component存在。

下面這個參考設計可以很好的詮釋一個軟硬體結合的系統各個單元是怎麼分工的。

https://www.xilinx.com/support/documentation/boards_and_kits/zcu102/2018_2/ug1221-zcu102-base-trd.pdf?

www.xilinx.com

我要表達意思就是工程師本來就是在不斷解決問題的道路上越走越遠的人。

當然這一切離不開錢的驅使,如果開發MCU能拿到很高工資的話,也就不會有人說MCU開發沒意思了!


我就是這麼認為的,我感覺mcu做了2-3年後,就會發現不過是uart spi各種外設,其他各種外接晶元。就算給一個新的晶元,熟悉最多也就幾個禮拜,RTOS之類的其實也沒什麼神祕的,無非是任務事件之類的。

想要走的更深入,似乎只有走演算法一路。很迷茫。


這是一種食物鏈鄙視相關的東西~

做MCU開發的工資可以自行到招聘網站上看看,絕對沒有Linux系統開發工資高,

主要是做Linux需要的知識更多,系統複雜度更大,這話中的沒什麼意思也說明瞭工資低和難度小的意思。

不過反過來說,MCU開發厲害的拿到高薪的也是非常多的,但是整體上還是比不上Linux系統開發的。


推薦閱讀:
相關文章