分類:工作閒談


__BEGIN_DECLS 及 __END_DECLS


最近看到下面這兩個,一時之間還搞不太懂…

  • __BEGIN_DECLS
  • __END_DECLS

後來 google 一下,才發現原來是在 bioniclibcincludesyscdefs.h

#if defined(__cplusplus)

#define __BEGIN_DECLS extern “C” {

#define __END_DECLS }

#define __static_cast(x,y) static_cast<x>(y)

#else

#define __BEGIN_DECLS

#define __END_DECLS

#define __static_cast(x,y) (x)y

#endif

給大家參考一下囉~

CTS verifier 已經移掉 audio quality test 測項


最近發現為什麼 CTS verifier 的 audio quality test 會不見,結果 google 了一下發現以下兩篇文章:

看起來都是 Google 的員工發表的,所以應該可信度很高.
主要是因為目前的測試可信度不高,所以就拿掉了… 之後才會再考慮加回來~

計算 RTC ppm 與實際誤差的時間


最近在跟 RTC (Real Time Clock) 纏鬥,因為客戶要求的時間是三天內不能慢五秒,但是要怎麼轉換成我們要的 ppm (Parts Per Million) 值呢?  或是我知道 ppm 值要怎麼看出來實際誤差的秒數呢?

http://www.maxim-ic.com/design/tools/calculators/product-design/rtc.cfm

上面這個網站就很好用啦,只要輸入了以後,就可以自動幫你轉換囉… 如下圖:

 

[Android] 在開機的時候,執行你想要的 shell script


雖然 init.rc 很好用,但還是有其缺陷… 像是我要 echo 某些字串到檔案時,他就做不到了 🙁

所以可以搭配一個 .sh 的檔案,讓他開機的時候去執行這個 .sh 即可。
建議修改方式:
[1] 在 AndroidBoard.mk 裡面將你的 .sh 包起去

file := $(TARGET_OUT)/etc/my.sh
ALL_PREBUILT += $(file)
$(file) : $(LOCAL_PATH)/my.sh | $(ACP)
$(transform-prebuilt-to-target)

[2] 在你想要加進去的 init.rc 中加入下面這段:

on boot
exec /system/bin/sh /system/etc/my.sh

 

這樣子就可以嚕 ^^  裡面用粗體紅字的就是要注意的地方囉

AT&T 對手機測試的要求


聽說 AT&T 是最難搞定的運營商了…
只要能夠把手機送進 AT&T 賣,就代表有一定實力

[長期招募] 誠徵 Android BSP / Linux kernel driver 的人才



誠徵 Android BSP / Linux kernel driver 的人才


資深人員薪資福利可談;剛畢業/退伍亦可~
有完整訓練課程及堅強支援後盾.


意者請把履歷寄給我:me@sunflier.com 感謝~

分、合、分


公司來了幾位新人,在新生訓練過後,就要讓他們自由的飛了 — 交付工作。

可能是研究所訓練的不夠扎實吧,給定該負責的工作內容後,卻沒辦法自行找到適當的資料及方向專研下去,以致多走了許多冤枉路。 這或許也是我們的錯,不該一開始就讓他自行摸索,看來還是必須指定教科書及文章,才會讓新人回歸正途。
在下藉此機會分享個人的讀書心得,供各位卓參。
「分、合、分」
– 在一開始時,大量的利用網路、相關書籍搜尋資料,分門別類的置放於不同的目錄。
例如我在看 Linux ALSA driver 時,除了 kernel documentation 外,我也會去看 QUALCOMM 的文件,利用 Google 搜尋所有相關的網頁 (可參考小弟於 2007 年寫的拙作 – Google搜尋小技巧) 且儘量用原文、學術單位、及較具權威的網站 (如 LWN)。
若有找到 “轉載” 文章的話,也要想辦法把源頭找出,裡頭必定有更大的寶庫。
– 在文件浩海中,找出最適合的文章。內容不需要包山包海,,但一定有頭有尾,該講該提的要有,這篇就可當作索引的文章,從此出發。
– 從前面的索引開始,將內文提到的 reference 一一翻出,並且試圖去證明文章中提到的任何說明。  Linux 隨著時代的遷移,必定有許多變化,這就要靠自己從 source code 大膽假設、小心求證。  切勿輕鬆略過不懂之處,因為將來必定變成自己的絆腳石!
這個方法在我求學、工作的階段都是這樣的,若想成為正港的 engineer 而不是似懂非懂的 programmer,請痛下苦功,未來必有美好的果實等著你採收!

搞 Linux 的<一個月>心得…


在原本的案子準備告一段落後,公司內部有兩個選擇,一個讓我做聯發科,一個讓我做 Linux。

那時候,為了讓新人有選擇的機會,所以我說都 OK;不過其實內心是想做 Linux 的,因為我覺得未來還有很大的發展空間 你知道我說的是什麼意思 ;p
後來被分配到聯發科的 team 做得也算開心,因為有機會接觸到不同的 Real-time OS,可以跟原本的 Qualcomm 平台評頭論足一番。不過因為 MTK 的 code 都把註解拔得乾乾淨淨,文件也有一堆問題,還是讓我吃足了苦頭。
但過沒幾個禮拜,大方向又轉換了,現在總算來做 Linux 了。
可是 Linux 的起步真的很難,如果用開車來說的話,簡直就是叫你直接要用 3 檔起步一樣難!
光是要架出來可以 build code 的 Ubuntu 就搞死一堆人了… 如果不知道 rm / cp / tar 這些指令的話,就只能夠照著 SOP 一步一步做,完全沒有可以深入理解的空間;trace code 又再去掉半條老命;記住 struct 的長像讓我 stack overflow… 🙁
但還好 Linux community 的人都很好,寫了很多文件及投影片出來,還有 open source 的書! 這也讓學習曲線不再這麼痛苦不堪,感謝前輩!
未來的路還很長,還需要好好學習,希望能讓自己的羽翼更豐厚些,飛得更高更遠。

我可以到這家外商嗎 XD 太屌了~~~


Marvell 在徵 compiler engineer,在下面的附註竟然是:

誠徵只賣腦,不賣肝,愛家庭,有生活,聰明且懶惰之軟體高手

我可以馬上應徵嗎…

你該怎麼成為會議中出色的人物?


在大大小小的會議中,無論是五人會議,或是上百人的會議,
我覺得要能夠在會議中成為一個表現傑出的角色,一定要會的技能就是:

「隨時在心中準備好一個要問講者的問題」

這個問題,可以是簡單,也可以是複雜,但是不要默默的進入會議室,然後又靜靜的離開。
在想問題時,其實你就是在注意講者的內容,進而能吸收並發問;
當然,也許你剛好有相關的問題想提出,這也是很好的機會,能夠教學相長。

下次別忘了這個好用的技巧喔!



彙整