驅動工程師看安卓源碼工具

A. 自己可以編譯安卓源碼嗎

用最新的Ubuntu 16.04,請首先確保自己已經安裝了Git.沒安裝的同學可以通過以下命令進行安裝:

sudo apt-get install git git config –global user.email 「[email protected]」 git config –global user.name 「test」

其中[email protected]為你自己的郵箱.

簡要說明

android源碼編譯的四個流程:1.源碼下載;2.構建編譯環境;3.編譯源碼;4運行.下文也將按照該流程講述.

源碼下載

由於某牆的原因,這里我們採用國內的鏡像源進行下載.
目前,可用的鏡像源一般是科大和清華的,具體使用差不多,這里我選擇清華大學鏡像進行說明.(參考:科大源,清華源)

repo工具下載及安裝

通過執行以下命令實現repo工具的下載和安裝

mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repochmod a+x ~/bin/repo

補充說明
這里,我來簡單的介紹下repo工具,我們知道AOSP項目由不同的子項目組成,為了方便進行管理,Google採用Git對AOSP項目進行多倉庫管理.在聊repo工具之前,我先帶你來聊聊多倉庫項目:

我們有個非常龐大的項目Pre,該項目由很多個子項目R1,R2,...Rn等組成,為了方便管理和協同開發,我們為每個子項目創立自己的倉庫,整個項目的結構如下:

這里寫圖片描述

執行完該命令後,再使用make命令繼續編譯.某些情況下,當你執行jack-admin kill-server時可能提示你命令不存在,此時去你去out/host/linux-x86/bin/目錄下會發現不存在jack-admin文件.如果我是你,我就會重新repo sync下,然後從頭來過.

錯誤三:使用emulator時,虛擬機停在黑屏界面,點擊無任何響應.此時,可能是kerner內核問題,解決方法如下:
執行如下命令:

通過使用kernel-qemu-armv7內核 解決模擬器等待黑屏問題.而-partition-size 1024 則是解決警告: system partion siez adjusted to match image file (163 MB >66 MB)

如果你一開始編譯的版本是aosp_arm-eng,使用上述命令仍然不能解決等待黑屏問題時,不妨編譯aosp_arm64-eng試試.

結束吧

到現在為止,你已經了解了整個android編譯的流程.除此之外,我也簡單的說明android源碼的多倉庫管理機制.下面,不妨自己動手嘗試一下.

B. Android BSP底層驅動工程師是做什麼的

BSP全稱 Board Support Package 介於主板硬體和操作系統中驅動層程序之間的一層，一般認為它屬於操作系統一部分，主要是實現對操作系統的支持，為上層的驅動程序提供訪問硬體設備寄存器的函數包，使之能夠更好的運行於硬體主板
以前的Windows Mobile及現在的Android都有BSP。均要進行驅動層的開發，以使操作系統能正常調用主板所有功能。一般的，可能會有 存儲驅動，顯示驅動，藍牙驅動，Wifi驅動，通訊模塊驅動，keypad驅動，電源管理驅動等等。

C. 如何系統的學習Linux驅動開發

在學習之前一直對驅動開發非常的陌生，感覺有點神秘。不知道驅動開發和普通的程序開發究竟有什麼不同；它的基本框架又是什麼樣的；他的開發環境有什麼特殊的地方；以及怎麼寫編寫一個簡單的字元設備驅動前編譯載入，下面我就對這些問題一個一個的介紹。

一、驅動的基本框架

1．那麼究竟什麼是驅動程序，它有什麼用呢:

l驅動是硬體設備與應用程序之間的一個中間軟體層

l它使得某個特定硬體能夠響應一個定義良好的內部編程介面，同時完全隱蔽了設備的工作細節

l用戶通過一組與具體設備無關的標准化的調用來完成相應的操作

l驅動程序的任務就是把這些標准化的系統調用映射到具體設備對於實際硬體的特定操作上

l驅動程序是內核的一部分，可以使用中斷、DMA等操作

l驅動程序在用戶態和內核態之間傳遞數據

2．Linux驅動的基本框架

3．Linux下設備驅動程序的一般可以分為以下三類

1)字元設備

a)所有能夠象位元組流一樣訪問的設備都通過字元設備來實現

b)它們被映射為文件系統中的節點，通常在/dev/目錄下面

c)一般要包含open read write close等系統調用的實現

2)塊設備

d)通常是指諸如磁碟、內存、Flash等可以容納文件系統的存儲設備。

e)塊設備也是通過文件系統來訪問，與字元設備的區別是：內核管理數據的方式不同

f)它允許象字元設備一樣以位元組流的方式來訪問，也可一次傳遞任意多的位元組。

3)網路介面設備

g)通常它指的是硬體設備，但有時也可能是一個軟體設備(如回環介面loopback)，它們由內核中網路子系統驅動，負責發送和接收數據包。

h)它們的數據傳送往往不是面向流的，因此很難將它們映射到一個文件系統的節點上。

二、怎麼搭建一個驅動的開發環境

因為驅動是要編譯進內核,在啟動內核時就會驅動此硬體設備；或者編譯生成一個.o文件,當應用程序需要時再動態載入進內核空間運行。因此編譯任何一個驅動程序都要鏈接到內核的源碼樹。所以搭建環境的第一步當然是建內核源碼樹

1.怎麼建內核源碼樹

a)首先看你的系統有沒有源碼樹，在你的/lib/ moles目錄下會有內核信息，比如我當前的系統里有兩個版本：

#ls /lib/ moles

2.6.15-rc72.6.21-1.3194.fc7

查看其源碼位置:

## ll /lib/moles/2.6.15-rc7/build

lrwxrwxrwx 1 root root 27 2008-04-28 19:19 /lib/moles/2.6.15-rc7/build -> /root/xkli/linux-2.6.15-rc7

發現build是一個鏈接文件，其所對應的目錄就是源碼樹的目錄。但現在這里目標目錄已經是無效的了。所以得自己重新下載

b)下載並編譯源碼樹

有很多網站上可以下載，但官方網址是：

http://www.kernel.org/pub/linux/kernel/v2.6/

下載完後當然就是解壓編譯了

# tar –xzvf linux-2.6.16.54.tar.gz

#cd linux-2.6.16.54

## make menuconfig (配置內核各選項,如果沒有配置就無法下一步編譯，這里可以不要改任何東西)

#make

…

如果編譯沒有出錯。那麼恭喜你。你的開發環境已經搭建好了

三、了解驅動的基本知識

1.設備號

1)什麼是設備號呢？我們進系統根據現有的設備來講解就清楚了：

#ls -l /dev/

crwxrwxrwx 1 root root1,3 2009-05-11 16:36 null

crw------- 1 root root4,0 2009-05-11 16:35 systty

crw-rw-rw- 1 root tty5,0 2009-05-11 16:36 tty

crw-rw---- 1 root tty4,0 2009-05-11 16:35 tty0

在日期前面的兩個數（如第一列就是1,3）就是表示的設備號，第一個是主設備號，第二個是從設備號

2)設備號有什麼用呢？

l傳統上,主編號標識設備相連的驅動.例如, /dev/null和/dev/zero都由驅動1來管理,而虛擬控制台和串口終端都由驅動4管理

l次編號被內核用來決定引用哪個設備.依據你的驅動是如何編寫的自己區別

3)設備號結構類型以及申請方式

l在內核中, dev_t類型(在中定義)用來持有設備編號,對於2.6.0內核, dev_t是32位的量, 12位用作主編號, 20位用作次編號.

l能獲得一個dev_t的主或者次編號方式：

MAJOR(dev_t dev); //主要

MINOR(dev_t dev);//次要

l但是如果你有主次編號,需要將其轉換為一個dev_t,使用: MKDEV(int major, int minor);

4)怎麼在程序中分配和釋放設備號

在建立一個字元驅動時需要做的第一件事是獲取一個或多個設備編號來使用.可以達到此功能的函數有兩個：

l一個是你自己事先知道設備號的

register_chrdev_region,在中聲明:

int register_chrdev_region(dev_t first, unsigned int count, char *name);

first是你要分配的起始設備編號. first的次編號部分常常是0,count是你請求的連續設備編號的總數. name是應當連接到這個編號范圍的設備的名子;它會出現在/proc/devices和sysfs中.

l第二個是動態動態分配設備編號

int alloc_chrdev_region(dev_t *dev, unsigned int firstminor, unsigned int count, char *name);

使用這個函數, dev是一個只輸出的參數,它在函數成功完成時持有你的分配范圍的第一個數. fisetminor應當是請求的第一個要用的次編號;它常常是0. count和name參數如同給request_chrdev_region的一樣.

5)設備編號的釋放使用

不管你是採用哪些方式分配的設備號。使用之後肯定是要釋放的，其方式如下：

void unregister_chrdev_region(dev_t first, unsigned int count);

6)

2.驅動程序的二個最重要數據結構

1)file_operation

倒如字元設備scull的一般定義如下：
struct file_operations scull_fops = {
.owner = THIS_MODULE,
.llseek = scull_llseek,
.read = scull_read,
.write = scull_write,
.ioctl = scull_ioctl,
.open = scull_open,
.release = scull_release,
};

file_operation也稱為設備驅動程序介面

定義在,是一個函數指針的集合.每個打開文件(內部用一個file結構來代表)與它自身的函數集合相關連(通過包含一個稱為f_op的成員,它指向一個file_operations結構).這些操作大部分負責實現系統調用,因此,命名為open, read,等等

2)File

定義位於include/fs.h

struct file結構與驅動相關的成員

lmode_t f_mode標識文件的讀寫許可權

lloff_t f_pos當前讀寫位置

lunsigned int_f_flag文件標志，主要進行阻塞/非阻塞型操作時檢查

lstruct file_operation * f_op文件操作的結構指針

lvoid * private_data驅動程序一般將它指向已經分配的數據

lstruct dentry* f_dentry文件對應的目錄項結構

3.字元設備注冊

1)內核在內部使用類型struct cdev的結構來代表字元設備.在內核調用你的設備操作前,必須編寫分配並注冊一個或幾個這些結構.有2種方法來分配和初始化一個這些結構.

l如果你想在運行時獲得一個獨立的cdev結構,可以這樣使用:

struct cdev *my_cdev = cdev_alloc();

my_cdev->ops = &my_fops;

l如果想將cdev結構嵌入一個你自己的設備特定的結構;你應當初始化你已經分配的結構,使用:

void cdev_init(struct cdev *cdev, struct file_operations *fops);

2)一旦cdev結構建立,最後的步驟是把它告訴內核,調用:

int cdev_add(struct cdev *dev, dev_t num, unsigned int count);

說明：dev是cdev結構, num是這個設備響應的第一個設備號, count是應當關聯到設備的設備號的數目.常常count是1,但是有多個設備號對應於一個特定的設備的情形.

3)為從系統去除一個字元設備,調用:

void cdev_del(struct cdev *dev);

4.open和release

D. Linux 內核和驅動開發工程師的發展前景怎麼樣

或許這樣的標題，應該是由像Linus或Greg KH這樣的大師級的高手才有資格寫的吧。但是作為我來說，也許我更想把這個標題作為一個疑問句來使用，整理一下自己的認識，用來勉勵自己，和大家一起努力實現這個目標。認識膚淺的地方，還請大家見諒。

從事嵌入式開發是當下比較熱門的一個領域，做職業規劃的時候，比較清晰的是有三條路可以走：
C1、嵌入式軟體開發工程師
C2、嵌入式硬體開發工程師
C3、嵌入式驅動開發工程師。

其中
C1是計算機相關專業的同學可以選擇的，因為學習的課程相對偏軟，平時在PC上編程比較多，做軟體開發會相對輕松。
C2是學習電子電路的同學可以考慮，對模擬電路比較熟悉，可以設計出質量好的電路板。
C3的難度比較大，需要同時熟悉軟體和硬體，真正的做到軟、硬相結合，搭建軟體和硬體互通的橋梁，當然了在業界的待遇也是相對來說比較高的。

我們可以去一些招聘網站查看相關企業的崗位要求，這樣學習的時候就有了一個比較明確的目標。今天看到一位前輩的博文，談究竟應該如何成為優秀的驅動開發工程師，很受鼓舞，在此與大家分享共勉。
--------------------------------------------------------------
何謂優秀的驅動開發工程師
首先要定義，我所認為的一個優秀的驅動開發工程師，應該具備什麼樣的能力，這里列一下按照從易到難的順序，個人認為應該會有幾個方面的要求吧：

能夠獨立完成驅動的功能開發任務
能夠分析和優化驅動的性能,針對特定硬體揚長避短
能夠充分了解模塊相關軟硬體能力、發展方向，輔助應用工程師最大化利用硬體能力
能夠輔助硬體工程師規劃硬體設計，預防問題，謀求功能模塊的最佳方案
能夠協助定義系統架構，合理規劃軟硬體，謀求產品實現的最佳方案

作為一個驅動工程師，很多時候不是完全從頭開發一個完整的子系統，而是針對特定硬體和平台移植驅動，增加功能，解決Bug等等，如果從這方面外在的表現來看：

解決問題的境界，大概會有這么幾個階段：

不知道哪裡存在BUG
不知道如何解決BUG
知道如何解決BUG
知道如何發現BUG
知道如何規劃BUG

知道如何發現BUG（而不是撞上BUG）其實並不簡單，需要你對系統有足夠的了解，能夠察覺可能出問題的地方。 而規劃Bug更難，需要你能對問題的輕重緩急做出准確的判斷。沒有的完美的世界，只有適當的取捨，規避和預防。

而從解決問題過程的角度來看，我認可以分為幾個階段：

BUG發生 -> 大量跟蹤調試代碼 -> 終於發現並解決BUG
BUG發生 -> 理論推測可能原因 -> 迅速定位並解決BUG
閱讀代碼 -> 預測可能出現的BUG -> 證實並解決BUG

---------------------------------------------------------------
應該具備怎樣的素質
那麼要達到上訴最佳境界，需要具備和發展哪些素質和能力呢？

一、足夠的硬體知識
能看簡單的原理圖，能夠分析硬體異常的可能原因，能夠使用常見的硬體調試工具，我想這是做為優秀的驅動工程師，區別與其它軟體工程師，所不可避免、必須具備的專業素質。當然取決於你具體從事的工作，對這方面的要求不盡相同。
對於驅動開發者來說，不了解所開發驅動外設的硬體原理和相關背景知識，也許很多時候，也能夠完成一些移植，修補的工作任務，但這就好比無源之水，無根之木，我相信是很難走遠的。

二、多多益善的操作系統知識
做驅動開發，特別是純粹的外設的驅動移植工作，剛開始的時候，也許你並不需要了解很多操作系統本身的知識（像內存管理，進程調度，鎖，各種內核子系統的原理框架等等），也能順利完成手頭的一些工作。
但是，如果一但需要優化驅動，需要完善軟體框架，或者是遇上疑難問題需要跟蹤解決，對操作系統，內核本身的了解，就體現出它的價值了。
對於Linux內核驅動開發者，尤其如此，首先，代碼是完全開源的，你有條件去了解背後的運行機制，其次，Linux內核和各個組成子系統總是在迅速的進化發展中，不進則退，你也有必要跟上時代發展的腳步。

三、強烈的好奇心，持續的熱情
如果驅動開發不僅僅是你的愛好，更是你養家糊口的途徑，我想，很多時候，你大概不會有機會專注於一兩個你最有經驗的模塊的開發和維護。隨著能力的成長，勢必會要求你接觸和掌握越來越多的各式各樣的驅動模塊的開發。
對於這件事，包括我自己，有時候大概都會有如下幾種反應：

哇，原來的工作做太久了，太乏味了，很高興能做不同的工作。
啊？又要做別的模塊啊？我手頭的工作已經太多了！
這個模塊沒意思，我不想做。

相信多數有志青年們都是第一種表現了，不過，有些時候，我發覺，很多人的這種熱情其實並不持久，一個新的模塊沒做多久，就再次厭倦了，是已經爐火純青了么，未必，或許只是修改了幾個BUG以後不甚其煩。很多時候，我面試前來求職的工程師時，發現簡歷上這個也做過，那個也做過，但是一旦問到解決了什麼問題，所做過的驅動，框架、流程、原理之類的問題的時候，就一問三不知了。

我覺得如果自己的目標是優秀，那麼最起碼的標准應該是對具體驅動模塊相關的子系統的整體工作流程，框架，具備足夠的好奇心，樂於去了解和學習，而不僅僅是為了完成任務而工作，否則的話，很難積累下扎實的經驗和技術。

四、清晰的邏輯思維能力
這一點，也許是個軟體開發人員都應該具備吧，不過，做為驅動開發工程師來說，有時候，大多數情況下，工作的硬體環境並不是完美的，遇到問題需要分析判斷錯誤的原因是硬體問題還是驅動Bug，這時候，清晰的邏輯思維能力尤其重要。

五、良好的工作習慣
大多數人都不是天才，要成為優秀的開發工程師，其一需要持續努力，其二需要時間積累經驗，而這過程中，很重要的一點，就是要有良好的工作習慣。譬如，注意設計文檔的維護，對工作中遇到的問題的記錄，過往經驗的及時記錄，適當的軟體開發流程等等。文檔工作，可能很多人很不願意去做，它的確很花費時間。不過，唉。。。老啦，好記性不如爛筆頭啊 。當然，其實設計文檔更多的是為你提供思考的機會，而過往經驗的總結，也可以起到和大家交流技術，共同進步的目的。

六、英語
這個也是必須的啦，沒有辦法，郵件列表，技術文檔，社區，精通英語肯定是很大的優勢，做開源項目尤其如此。閱讀各種Spec標准文檔之類的速度還是很重要的。閱讀無障礙是一回事，能和母語一樣一目十行，那才爽呀，唉，人生苦短，效率啊！光讀文檔，就不知道要比老外多花多少時間。

E. 內核方面的開發或驅動程序的開發工資待遇和一般的軟體開發相比怎麼樣

一、嵌入式系統的概念

著重理解「嵌入」的概念

主要從三個方面上來理解。
1、從硬體上，將基於CPU的處圍器件，整合到CPU晶元內部，比如早期基於X86體系結構下的計算機，CPU只是有運算器和累加器的功能，一切晶元要造外部橋路來擴展實現，象串口之類的都是靠外部的16C550/2的串口控制器晶元實現，而目前的這種串口控制器晶元早已集成到CPU內部，還有PC機有顯卡，而多數嵌入式處理器都帶有LCD控制器，但其種意義上就相當於顯卡。比較高端的ARM類Intel Xscale架構下的IXP網路處理器CPU內部集成PCI控制器（可配成支持4個PCI從設備或配成自身為CPI從設備）；還集成3個NPE網路處理器引擎，其中兩個對應於兩個MAC地址，可用於網關交換用，而另外一個NPE網路處理器引擎支持DSL，只要外面再加個PHY晶元即可以實現DSL上網功能。IXP系列最高主頻可以達到1.8G，支持2G內存，1G×10或10G×1的乙太網口或Febre channel的光通道。IXP系列應該是目標基於ARM體系統結構下由intel進行整合後成Xscale內核的最高的處理器了。
2、從軟體上前，就是在定製操作系統內核里將應用一並選入，編譯後將內核下載到ROM中。而在定製操作系統內核時所選擇的應用程序組件就是完成了軟體的「嵌入」，比如WinCE在內核定製時，會有相應選擇，其中就是wordpad,PDF,MediaPlay等等選擇，如果我們選擇了，在CE啟動後，就可以在界面中找到這些東西，如果是以前PC上將的windows操作系統，多半的東西都需要我們得新再裝。
3、把軟體內核或應用文件系統等東西燒到嵌入式系統硬體平台中的ROM中就實現了一個真正的「嵌入」。

以上的定義是我在6、7年前給嵌入式系統下自話側重於理解型的定義，書上的定義也有很多，但在這個領域范圍內，誰都不敢說自己的定義是十分確切的，包括那些專家學者們，歷為畢竟嵌入式系統是計算機范疇下的一門綜合性學科

二、嵌入式系統的分層與專業的分類。

嵌入式系統分為4層，硬體層、驅動層、操作系統層和應用層。

1、硬體層，是整個嵌入式系統的根本，如果現在單片機及介面這塊很熟悉，並且能用C和匯編語言來編程的話，從嵌入式系統的硬體層走起來相對容易，硬體層也是驅動層的基礎，一個優秀的驅動工程師是要能夠看懂硬體的電路圖和自行完成CPLD的邏輯設計的，同時還要對操作系統內核及其調度性相當的熟悉的。但硬體平台是基礎，增值還要靠軟體。
硬體層比較適合於，電子、通信、自動化、機電一體、信息工程類專業的人來搞，需要掌握的專業基礎知識有，單片機原理及介面技術、微機原理及介面技術、C語言。
2、驅動層，這部分比較難，驅動工程師不僅要能看懂電路圖還要能對操作系統內核十分的精通，以便其所寫的驅動程序在系統調用時，不會獨占操作系統時間片，而導至其它任務不能動行，不懂操作系統內核架構和實時調度性，沒有良好的驅動編寫風格，按大多數書上所說添加的驅動的方式，很多人都能做到，但可能連個初級的驅動工程師的水平都達不到，這樣所寫的驅動在應用調用時就如同windows下我們打開一個程序運行後，再打開一個程序時，要不就是中斷以前的程序，要不就是等上一會才能運行後來打開的程序。想做個好的驅動人員沒有三、四年功底，操作系統內核不研究上幾編，不是太容易成功的，但其工資在嵌入式系統四層中可是最高的。
驅動層比較適合於電子、通信、自動化、機電一體、信息工程類專業尤其是計算機偏體系結構類專業的人來搞，除硬體層所具備的基礎學科外，還要對數據結構與演算法、操作系統原理、編譯原理都要十分精通了解。

3、操作系統層，對於操作系統層目前可能只能說是簡單的移植，而很少有人來自已寫操作系統，或者寫出缺胳膊少腿的操作系統來，這部分工作大都由驅動工程師來完成。操作系統是負責系統任務的調試、磁碟和文件的管理，而嵌入式系統的實時性十分重要。據說，XP操作系統是微軟投入300人用兩年時間才搞定的，總時工時是600人年，中科院軟體所自己的女媧Hopen操作系統估計也得花遇幾百人年才能搞定。因此這部分工作相對來講沒有太大意義。

4、應用層，相對來講較為容易的，如果會在windows下如何進行編程介面函數調用，到操作系統下只是編譯和開發環境有相應的變化而已。如果涉及Jave方面的編程也是如此的。嵌入式系統中涉及演算法的由專業演算法的人來處理的，不必歸結到嵌入式系統范疇內。但如果涉及嵌入式系統下面嵌入式資料庫、基於嵌入式系統的網路編程和基於某此應用層面的協議應用開發（比如基於SIP、H.323、Astrisk）方面又較為復雜，並且有難度了。

三、目標與定位。

先有目標，再去定位。

學ARM，從硬體上講，一方面就是學習介面電路設計，另一方面就是學習匯編和C語言的板級編程。如果從軟體上講，就是要學習基於ARM處理器的操作系統層面的驅動、移植了。這些對於初學都來說必須明確,要麼從硬體著手開始學，要麼從操作系統的熟悉到應用開始學，但不管學什麼，只要不是純的操作系統級以上基於API的應用層的編程，硬體的寄存器類的東西還是要能看懂的，基於板級的匯編和C編程還是要會的。因此針對於嵌入式系統的硬體層和驅動程的人，ARM的介面電路設計、ARM的C語言和匯編語言編程及調試開發環境還是需要掌握的。
因此對於初學者必然要把握住方向，自己的目標是什麼，自己要在那一層面上走。然後再著手學習較好，與ARM相關的嵌入式系統的較為實際的兩個層面硬體層和驅動層，不管學好了那一層都會很有前途的。
如果想從嵌入式系統的應用層面的走的話，可能與ARM及其它體系相去較遠，要著重研究基嵌入式操作系統的環境應用與相應開發工具鏈，比如WinCe操作系統下的EVC應用開發（與windows下的VC相類似），如果想再有突破就往某些音視頻類的協議上靠，比如VOIP領域的基於SIP或H.323協議的應用層開發，或是基於嵌入式網路資料庫的開發等等。

對於初學者來講，要量力而行，不要認為驅動層工資高就把它當成方向了，要結合自身特點，嵌入式系統四個層面上那個層面上來講都是有高人存在，當然高人也對應的高工資，我是做硬體層的，以前每月工資中個人所得稅要被扣上近3千大元，當然我一方面充當工程師的角色，一方面充當主管及人物的角色，兩個職位我一個人干，但上班時間就那些。硬體這方面上可能與我PK的人很少了，才讓我拿到那麼多的工資。

四、開發系統選擇。

很多ARM初學者都希望有一套自己能用的系統，但他們住住會產生一種錯誤認識就是認為處理器版本越高、性能越高越好，就象很多人認為ARM9與ARM7好，我想對於初學者在此方面以此入門還應該理智，開發系統的選擇最終要看自己往嵌入式系統的那個方向上走，是做驅動開發還是應用，還是做嵌入式系統硬體層設計與板級測試。如果想從操作系統層面或應用層面上走，不管是驅動還是應用，那當然處理器性能越高越好了，但這個東西自學，有十分大的困難，不是幾個月或半年或是一年二年能搞定的事。

在某種意義上請，ARM7與9的差別就是在某些功能指令集上豐富了些，主頻提高一些而已，就比如286和386。對於用戶來講可能覺查不到什麼，只能是感覺速度有些快而已。
ARM7比較適合於那些想從硬體層面上走的人，因為ARM7系列處理器內部帶MMU的很少，而且比較好控制，就比如S3C44B0來講，可以很容易將Cache關了，而且內部介面寄存器很容易看明白，各種介面對於用硬體程序控制或AXD單步命令行指令都可以控制起來，基於51單片機的思想很容易能把他搞懂，就當成個32位的單片機，從而消除很多51工程師想轉為嵌入式系統硬體ARM開發工程師的困惑，從而不會被業界某此不是真正懂嵌入式爛公司帶到操作系統層面上去，讓他們望而失畏，讓業界更加缺少這方面的人才。

而嵌入式系統不管硬體設計還是軟體驅動方面都是十分注重介面這部分的，選擇平台還要考察一個處理器的外部資源，你接觸外部資源越多，越熟悉他們那你以後就業成功的機率就越高，這就是招聘時所說的有無「相關技能」，因為一個人不可能在短短幾年內把所有的處理器都接觸一遍，而招聘單位所用的處理器就可能是我們完全沒有見過的，就拿台灣數十家小公司（市價幾千萬）的公司生產的ARM類處理器，也很好用，但這些東西通用性太差，用這些處理器的公司就只能招有相關工作經驗的人了，那什麼是相關工作經驗，在硬體上講的是外圍介面設計，在軟體上講是操作系統方面相關介面驅動及應用開發經驗。我從業近十年，2000年ARM出現，我一天始做ARM7,然後直接跑到了Xscale（這個板本在ARM10-11之間），一做就是五年，招人面試都不下數百人，在這些方面還是深有體會的。

我個人認為三星的S3C44b0對初學者來說比較合適，為什麼這么說哪？因為介面資源比較豐富，技術成熟，資料較多，應該十分適合於初學者，有問題可能很容易找人幫且解決，因為大多數人都很熟悉，就如同51類的單片機，有N多位專家級的人物可以給你幫忙，相關問題得以很快解答，所然業界認為這款ARM都做用得爛了，但對於初學者來，就卻是件好事。
因此開發系統的選擇，要看自己的未來從來目標方向、要看開發板介面資源、還要看業界的通用性。

五、如何看待培訓。

首先說說我自己，我目前從業近十年，與國內嵌入式系統行業共同起步，一直站在嵌入式系統行業前沿，設計過多款高端嵌入式系統平台產品並為眾多公司提供過解決方案，離職前為從事VOIP的美資公司設計IP-PBX，歷任項目經理、項目主管、技術總監、部門經理，積累眾多人脈，並集多年經驗所得，考慮到學生就業與公司招人的不相匹配，公司想招人招不到，而學生和剛畢業的工程師想找份工作也不太容易，於此力創知天行科技有限公司，開展嵌入式系統教育培訓。
因一線的科研人員和一線的教師不相接觸，導至國內嵌入式人才缺乏，國外高校的技術超前於業界公司，而國內情況是業界公司方面的嵌入式系統技術要遠遠領先於高校。為架構業界與高校溝通的橋梁，把先進技能帶給高校學子，為學生在就業競爭中打造一張王牌，並為業界工程師快速提升實現自我創造機遇，我就這樣辭去了外企年薪20多萬的職位，做嵌入式系統方面的培訓了。
對於培訓來講，是花錢來買時間，很多工程師都喜歡自己學，認為培訓不值，這也是有可能的，純為賺錢的培訓當然不會太有價值，但對於實力型的培訓他們可能就虧大了，有這樣一筆帳不知他們算過沒有，如果一個一周的培訓，能帶給他們自學兩年後才能掌握的知識，在培訓完後他們用三個月到半年時間消化培訓內容，這樣他會省約至少一年半的時間來學其它的或重新站在另一個高度上工作，那麼他將最遲一年後會拿到他兩年後水平所對應的工資，就是在工資與水平對應的關繫上比同批人縮短一年，每月按最少1千計，再減去培訓費用至少多1.0萬，同時也省了一年時間，不管是休閑也好，再繼續提高也好，總之是跑到了隊伍的前面了。
另一層面上講，對於新人的培訓相當於他們為自己提前買了份失業保險，有師傅會帶領他們入道，我今年暑假時班裡最年輕的一個學生是大二的，今年才上大三，這學期才剛學單片機，但現在ARM方面的編程工作已經搞得有聲有色了，再過一年多畢業，他還會失業嗎？
再者通過培訓，你可以知道很多業界不為常人所知的事，同時也為自己找了個師傅，就比如說，兩個工程師分別用S3C2410和PXA255來做手持設備，同樣兩人都工作四年，再出去找工作，兩人工資可能最多可相差一倍，為什麼？這就是業界不為常人所知的規則，2410屬於民品，被業界用爛了，做產品時成本特敏感，當然也對人才成本敏感了，PXA255是intel的東西，一個255 CPU能買三個2410，一直被業界定義為貴族產品，用的公司都是大公司或為軍方服務的公司，不會在乎成本，只要把東西做好，一切都好說，但這方面做的人也少啊，因為開發系統貴啊。
對於說為自已找了個好師傅，我想是這樣的，因為同級工程師間存在著某此潛在的競爭關系，有很多人不願意把自己知道的東西教給別人，這意味著他將要失業，就是所說的教會徒弟，餓死師傅，但對於我們這些人就不存在這樣的關系了，我是在嵌入式系統平台設計上走到了一定程序，目前在國內這塊的技術上已經是自己很難再突破自己，因此很多東西我對大家都是OPEN的，就比如說下面那部分關於介面設計中所提到的時序介面東西，我要是不講，卻使是高級硬體工程師我想也幾乎只有10%的人能知道吧。

六、成為高級嵌入式系統硬體工程師要具備的技能。

首先我聲明，我是基於嵌入式系統平台級設計的，硬體這個方向我相對來講比較有發言權，如果是其它方面所要具備的基本技能還要和我們培訓中心其它專業級講師溝通，或去網站看看。他們的方面上我只能說是知道些，但不是太多，初級的問題也可以問我。
對於硬體來講有幾個方向，就單純信號來分為數字和模擬，模擬比較難搞，一般需要很長的經驗積累，單單一個阻值或容值的精度不夠就可能使信號偏差很大。因此年輕人搞的較少，隨著技術的發展，出現了模擬電路數字化，比如手機的Modem射頻模塊，都採用成熟的套片，而當年國際上只有兩家公司有此技術，自我感覺模擬功能不太強的人，不太適合搞這個，如果真能搞定到手機的射頻模塊，只要達到一般程度可能月薪都在15K以上。
另一類就是數字部分了，在大方向上又可分為51/ARM的單片機類，dsp類，FPGA類，國內FPGA的工程師大多是在IC設計公司從事IP核的前端驗證，這部分不搞到門級，前途不太明朗，即使做個IC前端驗證工程師，也要搞上幾年才能勝任。dsp硬體介面比較定型，如果不向驅動或是演算法上靠攏，前途也不會太大。而ARM單片機類的內容就較多，業界產品佔用量大，應用人群廣，因此就業空間極大，而硬體設計最體現水平和水準的就是介面設計這塊，這是各個高級硬體工程師相互PK，判定水平高低的依據。而介面設計這塊最關鍵的是看時序，而不是簡單的連接，比如PXA255處理器I2C要求速度在100Kbps，如果把一個I2C外圍器件，最高還達不到100kbps的與它相接，必然要導致設計的失敗。這樣的情況有很多，比如51單片機可以在匯流排接LCD，但為什麼這種LCD就不能掛在ARM的匯流排上，還有ARM7匯流排上可以外接個Winband的SD卡控制器，但為什麼這種控制器接不到ARM9或是Xscale處理器上，這些都是問題。因此介面並不是一種簡單的連接，要看時序，要看參數。 一個優秀的硬體工程師應該能夠在沒有參考方案的前提下設計出一個在成本和性能上更加優秀的產品，靠現有的方案，也要進行適當的可行性裁剪，但不是胡亂的來，我遇到一個工程師把方案中的5V變1.8V的DC晶元，直接更換成LDO，有時就會把CPU燒上幾個。前幾天還有人希望我幫忙把他們以前基於PXA255平台的手持GPS設備做下程序優化，我問了一下情況，地圖是存在SD卡中的，而SD卡與PXA255的MMC控制器間採用的SPI介面，因此導致地圖讀取速度十分的慢，這種情況是設計中嚴重的缺陷，而不是程序的問題，因此我提了幾條建議，讓他們更新試下再說。因此想成為一個優秀的工程師，需要對系統整體性的把握和對已有電路的理解，換句話說，給你一套電路圖你終究能看明白多少，看不明白80%以上的話，說明你離優秀的工程師還差得遠哪。其次是電路的調試能力和審圖能力，但最最基本的能力還是原理圖設計PCB繪制，邏輯設計這塊。這是指的硬體設計工程師，從上面的硬體設計工程師中還可以分出ECAD工程師，就是專業的畫PCB板的工程師，和EMC設計工程師，幫人家解決EMC的問題。硬體工程師再往上就是板級測試工程師，就是C語功底很好的硬體工程師，在電路板調試過程中能通過自已編寫的測試程序對硬體功能進行驗證。然後再交給基於操作系統級的驅動開發人員。

總之，硬體的內容很多很雜，硬體那方面練成了都會成為一個高手，我時常會給人家做下方案評估，很多高級硬體工程師設計的東西，經常被我一句話否定，因此工程師做到我這種地步，也會得罪些人，但硬體的確會有很多不為人知的東西，讓很多高級硬體工程師也摸不到頭腦。

那麼高級硬體件工程師技術技能都要具備那些東西哪，首先要掌握EDA設計的輔助工具類如Protel\ORCAD\PowperPCB\Maplux2\ISE、VDHL語言，要能用到這些工具畫圖畫板做邏輯設計，再有就是介面設計審圖能力，再者就是調試能力，如果能走到總體方案設計這塊，那就基本上快成為資深工程師了。

硬體是要靠經驗，也要靠積累的，十年磨一劍，百年磨一針。

F. 驅動如何調試

驅動程序開發的一個重大難點就是不易調試。本文目的就是介紹驅動開發中常用的幾種直接和間接的調試手段，它們是：
1、利用printk
2、查看OOP消息
3、利用strace
4、利用內核內置的hacking選項
5、利用ioctl方法
6、利用/proc 文件系統
7、使用kgdb
前兩種如下：
一、利用printk
這是驅動開發中最朴實無華，同時也是最常用和有效的手段。scull驅動的main.c第338行如下，就是使用printk進行調試的例子，這樣的例子相信大家在閱讀驅動源碼時隨處可見。
338 // printk(KERN_ALERT "wakeup by signal in process %d\n", current->pid);
printk的功能與我們經常在應用程序中使用的printf是一樣的，不同之處在於printk可以在列印字元串前面加上內核定義的宏，例如上面例子中的KERN_ALERT（注意：宏與字元串之間沒有逗號）。
#define KERN_EMERG "<0>"
#define KERN_ALERT "<1>"
#define KERN_CRIT "<2>"
#define KERN_ERR "<3>"
#define KERN_WARNING "<4>"
#define KERN_NOTICE "<5>"
#define KERN_INFO "<6>"
#define KERN_DEBUG "<7>"
#define DEFAULT_CONSOLE_LOGLEVEL 7


這個宏是用來定義需要列印的字元串的級別。值越小，級別越高。內核中有個參數用來控制是否將printk列印的字元串輸出到控制台（屏幕或者/sys/log/syslog日誌文件）
# cat /proc/sys/kernel/printk
6 4 1 7
第一個6表示級別高於（小於）6的消息才會被輸出到控制台，第二個4表示如果調用printk時沒有指定消息級別（宏）則消息的級別為4，第三個1表示接受的最高（最小）級別是1，第四個7表示系統啟動時第一個6原來的初值是7。
因此，如果你發現在控制台上看不到你程序中某些printk的輸出，請使用echo 8 > /proc/sys/kernel/printk來解決。
在復雜驅動的開發過程中，為了調試會在源碼中加入成百上千的printk語句。而當調試完畢形成最終產品的時候必然會將這些printk語句刪除想想驅動的使用者而不是開發者吧。記住：己所不欲，勿施於人），這個工作量是不小的。最要命的是，如果我們將調試用的printk語句刪除後，用戶又報告驅動有bug，所以我們又不得不手工將這些上千條的printk語句再重新加上。oh，my god，殺了我吧。所以，我們需要一種能方便地打開和關閉調試信息的手段。哪裡能找到這種手段呢？哈哈，遠在天邊，近在眼前。看看scull驅動或者leds驅動的源代碼吧！
#define LEDS_DEBUG
#undef PDEBUG
#ifdef LEDS_DEBUG
#ifdef __KERNEL__

#define PDEBUG(fmt, args…) printk( KERN_EMERG "leds: " fmt, ## args)
#else

#define PDEBUG(fmt, args…) fprintf(stderr, fmt, ## args)
#endif
#else
#define PDEBUG(fmt, args…)
#endif
#undef PDEBUGG
#define PDEBUGG(fmt, args…)
這樣一來，在開發驅動的過程中，如果想列印調試消息，我們就可以用PDEBUG("address of i_cdev is %p\n", inode->i_cdev);，如果不想看到該調試消息，就只需要簡單的將PDEBUG改為PDEBUGG即可。而當我們調試完畢形成最終產品時，只需要簡單地將第1行注釋掉即可。
上邊那一段代碼中的__KERNEL__是內核中定義的宏，當我們編譯內核（包括模塊）時，它會被定義。當然如果你不明白代碼中的…和##是什麼意思的話，就請認真查閱一下gcc關於預處理部分的資料吧！如果你實在太懶不願意去查閱的話，那就充當VC工程師把上面的代碼到你的代碼中去吧。
二、查看OOP消息
OOP意為驚訝。當你的驅動有問題，內核不驚訝才怪：嘿！小子，你干嗎亂來！好吧，就讓我們來看看內核是如何驚訝的。
根據faulty.c（單擊下載）編譯出faulty.ko，並 insmod faulty.ko。執行echo yang >/dev/faulty，結果內核就驚訝了。內核為什麼會驚訝呢？因為faulty驅動的write函數執行了*(int *)0 = 0，向內存0地址寫入，這是內核絕對不會容許的。
52 ssize_t faulty_write (struct file *filp, const char __user *buf, size_t count,
53 loff_t *pos)
54 {
55
56 *(int *)0 = 0;
57 return 0;
58 }
1 Unable to handle kernel NULL pointer dereference at virtual address 00000000
2 pgd = c3894000
3 [00000000] *pgd=33830031, *pte=00000000, *ppte=00000000
4 Internal error: Oops: 817 [#1] PREEMPT
5 Moles linked in: faulty scull
6 CPU: 0 Not tainted (2.6.22.6 #4)
7 PC is at faulty_write+0×10/0×18 [faulty]
8 LR is at vfs_write+0xc4/0×148
9 pc : [] lr : [] psr: a0000013
10 sp : c3871f44 ip : c3871f54 fp : c3871f50
11 r10: 4021765c r9 : c3870000 r8 : 00000000
12 r7 : 00000004 r6 : c3871f78 r5 : 40016000 r4 : c38e5160
13 r3 : c3871f78 r2 : 00000004 r1 : 40016000 r0 : 00000000
14 Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment user
15 Control: c000717f Table: 33894000 DAC: 00000015
16 Process sh (pid: 745, stack limit = 0xc3870258)
17 Stack: (0xc3871f44 to 0xc3872000)
18 1f40: c3871f74 c3871f54 c0088eb8 bf00608c 00000004 c38e5180 c38e5160
19 1f60: c3871f78 00000000 c3871fa4 c3871f78 c0088ffc c0088e04 00000000 00000000
20 1f80: 00000000 00000004 40016000 40215730 00000004 c002c0e4 00000000 c3871fa8
21 1fa0: c002bf40 c0088fc0 00000004 40016000 00000001 40016000 00000004 00000000
22 1fc0: 00000004 40016000 40215730 00000004 00000001 00000000 4021765c 00000000
23 1fe0: 00000000 bea60964 0000266c 401adb40 60000010 00000001 00000000 00000000
24 Backtrace:
25 [] (faulty_write+0×0/0×18 [faulty]) from [] (vfs_write+0xc4/0×148)
26 [] (vfs_write+0×0/0×148) from [] (sys_write+0x4c/0×74)
27 r7:00000000 r6:c3871f78 r5:c38e5160 r4:c38e5180
28 [] (sys_write+0×0/0×74) from [] (ret_fast_syscall+0×0/0x2c)
29 r8:c002c0e4 r7:00000004 r6:40215730 r5:40016000 r4:00000004
30 Code: e1a0c00d e92dd800 e24cb004 e3a00000 (e5800000)
1行驚訝的原因，也就是報告出錯的原因；
2-4行是OOP信息序號；
5行是出錯時內核已載入模塊；
6行是發生錯誤的CPU序號；
7-15行是發生錯誤的位置，以及當時CPU各個寄存器的值，這最有利於我們找出問題所在地；
16行是當前進程的名字及進程ID
17-23行是出錯時，棧內的內容
24-29行是棧回溯信息，可看出直到出錯時的函數遞進調用關系（確保CONFIG_FRAME_POINTER被定義）
30行是出錯指令及其附近指令的機器碼，出錯指令本身在小括弧中


反匯編faulty.ko（ arm-linux-objmp -D faulty.ko > faulty.dis ；cat faulty.dis）可以看到如下的語句如下：
0000007c :
7c: e1a0c00d mov ip, sp
80: e92dd800 stmdb sp!, {fp, ip, lr, pc}
84: e24cb004 sub fp, ip, #4 ; 0×4
88: e3a00000 mov r0, #0 ; 0×0
8c: e5800000 str r0, [r0]
90: e89da800 ldmia sp, {fp, sp, pc}
定位出錯位置以及獲取相關信息的過程：
9 pc : [] lr : [] psr: a0000013

25 [] (faulty_write+0×0/0×18 [faulty]) from [] (vfs_write+0xc4/0×148)
26 [] (vfs_write+0×0/0×148) from [] (sys_write+0x4c/0×74)
出錯代碼是faulty_write函數中的第5條指令（(0xbf00608c-0xbf00607c)/4+1=5），該函數的首地址是0xbf00607c，該函數總共6條指令（0×18），該函數是被0xc0088eb8的前一條指令調用的（即：函數返回地址是0xc0088eb8。這一點可以從出錯時lr的值正好等於0xc0088eb8得到印證）。調用該函數的指令是vfs_write的第49條（0xc4/4=49）指令。
達到出錯處的函數調用流程是：write(用戶空間的系統調用)–>sys_write–>vfs_write–>faulty_write
OOP消息不僅讓我定位了出錯的地方，更讓我驚喜的是，它讓我知道了一些秘密：1、gcc中fp到底有何用處？2、為什麼gcc編譯任何函數的時候，總是要把3條看上去傻傻的指令放在整個函數的最開始？3、內核和gdb是如何知道函數調用棧順序，並使用函數的名字而不是地址？ 4、我如何才能知道各個函數入棧的內容？哈哈，我漸漸喜歡上了讓內核驚訝，那就再看一次內核驚訝吧。
執行 cat /dev/faulty，內核又再一次驚訝！
1 Unable to handle kernel NULL pointer dereference at virtual address 0000000b
2 pgd = c3a88000
3 [0000000b] *pgd=33a79031, *pte=00000000, *ppte=00000000
4 Internal error: Oops: 13 [#2] PREEMPT
5 Moles linked in: faulty
6 CPU: 0 Not tainted (2.6.22.6 #4)
7 PC is at vfs_read+0xe0/0×140
8 LR is at 0xffffffff
9 pc : [] lr : [] psr: 20000013
10 sp : c38d9f54 ip : 0000001c fp : ffffffff
11 r10: 00000001 r9 : c38d8000 r8 : 00000000
12 r7 : 00000004 r6 : ffffffff r5 : ffffffff r4 : ffffffff
13 r3 : ffffffff r2 : 00000000 r1 : c38d9f38 r0 : 00000004
14 Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user
15 Control: c000717f Table: 33a88000 DAC: 00000015
16 Process cat (pid: 767, stack limit = 0xc38d8258)
17 Stack: (0xc38d9f54 to 0xc38da000)
18 9f40: 00002000 c3c105a0 c3c10580
19 9f60: c38d9f78 00000000 c38d9fa4 c38d9f78 c0088f88 c0088bb4 00000000 00000000
20 9f80: 00000000 00002000 bef07c80 00000003 00000003 c002c0e4 00000000 c38d9fa8
21 9fa0: c002bf40 c0088f4c 00002000 bef07c80 00000003 bef07c80 00002000 00000000
22 9fc0: 00002000 bef07c80 00000003 00000000 00000000 00000001 00000001 00000003
23 9fe0: 00000000 bef07c6c 0000266c 401adab0 60000010 00000003 00000000 00000000
24 Backtrace: invalid frame pointer 0xffffffff
25 Code: ebffff86 e3500000 e1a07000 da000015 (e594500c)
26 Segmentation fault
不過這次驚訝卻令人大為不解。OOP竟然說出錯的地方在vfs_read（要知道它可是大拿們千錘百煉的內核代碼），這怎麼可能？哈哈，萬能的內核也不能追蹤函數調用棧了，這是為什麼？其實問題出在faulty_read的43行，它導致入棧的r4、r5、r6、fp全部變為了0xffffffff，ip、lr的值未變，這樣一來faulty_read函數能夠成功返回到它的調用者——vfs_read。但是可憐的vfs_read（忠實的APTCS規則遵守者）並不知道它的r4、r5、r6已經被萬惡的faulty_read改變，這樣下去vfs_read命運就可想而知了——必死無疑！雖然內核很有能力，但缺少了正確的fp的幫助，它也無法追蹤函數調用棧。
36 ssize_t faulty_read(struct file *filp, char __user *buf,
37 size_t count, loff_t *pos)
38 {
39 int ret;
40 char stack_buf[4];
41
42
43 memset(stack_buf, 0xff, 20);
44 if (count > 4)
45 count = 4;
46 ret = _to_user(buf, stack_buf, count);
47 if (!ret)
48 return count;
49 return ret;
50 }
00000000 :
0: e1a0c00d mov ip, sp
4: e92dd870 stmdb sp!, {r4, r5, r6, fp, ip, lr, pc}
8: e24cb004 sub fp, ip, #4 ; 0×4
c: e24dd004 sub sp, sp, #4 ; 0×4，這里為stack_buf[]在棧上分配1個字的空間，局部變數ret使用寄存器存儲，因此就不在棧上分配空間了
10: e24b501c sub r5, fp, #28 ; 0x1c
14: e1a04001 mov r4, r1
18: e1a06002 mov r6, r2
1c: e3a010ff mov r1, #255 ; 0xff
20: e3a02014 mov r2, #20 ; 0×14
24: e1a00005 mov r0, r5
28: ebfffffe bl 28 //這里在調用memset
78: e89da878 ldmia sp, {r3, r4, r5, r6, fp, sp, pc}
這次OOP，深刻地認識到：
內核能力超強，但它不是，也不可能是萬能的。所以即使你能力再強，也要和你的team member搞好關系，否則在關鍵時候你會倒霉的；
出錯的是faulty_read，vfs_read卻做了替罪羊。所以人不要被表面現象所迷惑，要深入看本質；
內核本來超級健壯，可是你寫的驅動是內核的組成部分，由於它出錯，結果整體崩盤。所以當你加入一個團隊的時候一定要告誡自己，雖然你的角色也許並不重要，但你的疏忽大意將足以令整個非常牛X的團隊崩盤。反過來說，當你是team leader的時候，在選團隊成員的時候一定要慎重、慎重、再慎重，即使他只是一個小角色。
千萬別惹堆棧，它一旦出問題，定位錯誤將會是一件非常困難的事情。所以，千萬別惹你的領導，否則將死得很難看。

G. 學嵌入式linux需要先學什麼

剛入門的時候，淘寶買一塊cortex m3開發板即可入手，通過項目，你需要了解：任務調度、進程間通信、內存管理、設備驅動、文件系統、TCP/IP協議棧、同步非同步、中斷、軟體架構插件化等等基本原理，這些對你後面轉Linux應用開發，安卓開發，後台開發大有好處。

到這一步，就看自己職業方向想往哪裡發展，如果是想深入IOT物聯網做端雲連接，那麼可以把幾種基本匯流排驅動，I2C、SPI、USART理解透，如果是想擁抱互聯網轉入應用開發，那麼可以把基礎組件，如協議棧、文件系統吃透，BAT面試不是很難，問的都是這些基礎。

順便說一下，學東西就要學對市場有用的，不要過於學習屠龍之術，炫技給個人帶來不了財富，公司需要的是能幹活的人。

不準備講過於偏硬體的知識如Cortex-M3的多種中斷模式，操作寄存器組，晶元降噪等內容，而是專注於操作系統基本知識和項目經驗，這些對於開發者後面接觸Linux系統大有脾益，這些軟體開發經驗也是去互聯網公司看重的能力。如有需要學習Linux命令請如下查找：

H. 如何查看Android SDK源碼版本

1. 點擊菜單欄Tools-Android-SDK Manager
   

   I. 目前熱招的Android技術崗位有哪些

   學Android開發可以任職哪些崗位？Android熱門就業崗位總結:

   Android手機軟體研發工程師、Android手機游戲開發工程師、Android手機游戲策劃師、Android手機游戲移植工程師、Android測試工程師 、Android架構師、Android主要應用方向、Android應用軟體開發 、跨平台移動軟體開發、手機游戲開發軟體移植。

   1.Android開發工程師

   崗位職責：

   1、Android智能手機平台應用軟體的分析、設計、編碼和測試

   2、智能手機應用相關的技術研究

   3、從事與商品化相關的技術支持

   任職資格：

   1、計算機、通信、電子等相關專業本科以上學歷，一年以上工作經驗

   2、熟悉Linux操作系統

   3、具有J2ME或Java開發經驗，熟悉ANDROID手機軟體架構，熟悉Android平台MMI軟體開發

   4、了解基本軟體開發流程，了解Clear Case/Clear Quest/UML等開發工具

   5、具有良好的英文文檔編寫能力

   符合以下條件者優先：

   - 有智能手機開發經驗者優先

   - 有Linux手機平台開發經驗者優先

   1、計算機相關專業畢業。

   2、兩年以上嵌入式系統開發經驗，一年以上的ANDROID手機平台經驗。

   3、要求熟悉ANDROID手機軟體架構，精通ANDROID平台MMI軟體開發，能獨立進行應用程序開發和移植。

   4、要求熟悉基本無線協議（如：GSM/GPRS/CDMA和SDL）。

   5、喜歡挑戰高難度項目。

   6、有較好的學習能力、溝通能力，能承受一定的工作壓力。

   7、具備良好合作態度及團隊精神，並富有工作激情、創新力和責任感。

   2.Android軟體開發工程師

   崗位職責：

   1.Android手機應用軟體設計；

   2.Android手機應用軟體開發；

   3.Android手機軟體功能測試與驗證；

   任職要求：

   1.掌握Android平台應用軟體開發技術；

   2.熟悉Adodb AIR編程技術者優先考慮；

   3.熟悉c++/Java編程技術；

   4.掌握Android系統網路編程能力；

   5.Android系統軟體開發一年以上工作經驗者優先考慮;

   6.工作積極、認真、刻苦，具有良好的團隊合作精神。

   3.Android應用開發工程師

   職位描述:

   負責Android平台下應用的開發。

   職位要求：

   1、計算機或相關技術專業的本科及以上學位（或同等學歷）；

   2、豐富的C，C++或Java的編碼技能；

   3、對軟體產品有強烈的責任心；

   4、熱愛設計編寫程序，對IT行業充滿激情，有獨立的用代碼解決問題的能力；

   5、熟悉Android應用開發框架，能獨立開發高性能的Android應用；

   6、熟悉Android平台架構，有Android源碼二次開發經驗者優先；

   7、有APP作品者優先。

   4.Android手機游戲開發工程師

   主要職責：

   1.對游戲有高度熱忱，工作態度積極，重視團隊合作與溝通。

   2.系統學習過軟體開發，熟悉J2ME/J2SE程序設計，Java編程基礎扎實

   3.對數據結構、圖形學、游戲演算法有一定心得

   4.對C / C++有良好的教育背景和了解

   5.精通基於Android SDK的應用程序開發，能獨立進行各種應用程序開發和移植。

   6.有一年以上手機游戲開發經驗。

   7.思維敏捷，邏輯清楚，學習能力強

   8.本科計算機軟體相關專業優先考慮；有完整手機游戲開發經歷者優先考慮；有Android游戲移植經驗者優先

   5.Android中間層開發工程師

   工作職責：

   1. 能獨立設計優化和移植HAL層外設模塊，如Camera、Gsensor、WiFi、藍牙等模塊

   任職資格：

   1. 熟悉JAVA/J2ME語言

   2. 精通C/C++編程，具有良好的編碼規范；

   3. 熟悉嵌入式Linux操作系統，Linux驅動開發；

   4. 熟悉Android的架構層次、代碼結構；

   6.Android人機交互分析工程師

   工作職責：

   1. 負責分析Android產品人機交互響應時間和影響因素，如按鍵響應，虛擬鍵盤響應，觸控響應，打開/關閉程序響應，上網響 應，開關機響應；

   任職資格：

   1. 熟悉JAVA/J2ME語言；

   2. 熟悉C/C++語言；

   3. 精通Android開發平台及Framework框架原理

   4. 有較強的獨立分析能力和創新意識；

   7.Android系統工程師

   崗位職責描述：

   1. 與驅動工程師配合，將Android系統移植到特定硬體平台上；

   2. 與UI軟體開發工程師配合，設計和修改相關軟體，給上層UI開發提供支持；

   3. 與測試部門溝通，解決相關Bug；<br>4.根據項目計劃，發布整合好的軟體版本；

   職位需求：

   1. 計算機或相關專業本科及以上學歷，

   2. 年以上實際工作經驗；<br>2.熟悉Java/C/C++,熟悉Linux；

   3. 有Android相關開發經驗的優先考慮；

   4. 有較強的學習能力，分析和解決問題的能力，有較強的的代碼閱讀及分析能力；

   5. .誠實正直，任勞任怨，工作積極主動，有良好的團隊合作意識和溝通能力。

   以上是我們為大家總結的關於Android開發行業的幾類具體崗位職責及職位需求，希望能夠對那些剛剛想從事Android開發的人能有些參考建議。

   J. Android 重學系列 ion驅動源碼淺析

   上一篇文章，在解析初始化GraphicBuffer中，遇到一個ion驅動，對圖元進行管理。首先看看ion是怎麼使用的：
   
   我們按照這個流程分析ion的源碼。
   
   如果對ion使用感興趣，可以去這篇文章下面看 https://blog.csdn.net/hexiaolong2009/article/details/102596744
   
   本文基於Android的Linux內核版本3.1.8
   
   遇到什麼問題歡迎來本文討論 https://www.jianshu.com/p/5fe57566691f
   
   什麼是ion？如果是音視頻，Camera的工程師會對這個驅動比較熟悉。最早的GPU和其他驅動協作申請一塊內存進行繪制是使用比較粗暴的共享內存。在Android系統中使用的是匿名內存。最早由三星實現了一個Display和Camera共享內存的問題，曾經在Linux社區掀起過一段時間。之後各路大牛不斷的改進之下，就成為了dma_buf驅動。並在 Linux-3.3 主線版本合入主線。現在已經廣泛的運用到各大多媒體開發中。
   
   首先介紹dma_buf的2個角色，importer和exporter。importer是dma_buf驅動中的圖元消費者，exporter是dma_buf驅動中的圖元生產者。
   
   這里借用大佬的圖片：
   
   ion是基於dma_buf設計完成的。經過閱讀源碼，其實不少思路和Android的匿名內存有點相似。閱讀本文之前就算不知道dma_buf的設計思想也沒關系，我不會仔細到每一行，我會注重其在gralloc服務中的申請流程，看看ion是如何管理共享內存，為什麼要拋棄ashmem。
   
   我們先來看看ion的file_operation:
   
   只有一個open和ioctl函數。但是沒有mmap映射。因此mmap映射的時候一定其他對象在工作。
   
   我們關注顯卡英偉達的初始化模塊。
   文件：/ drivers / staging / android / ion / tegra / tegra_ion.c
   
   mole_platform_driver實際上就是我之前經常提到過的mole_init的一個宏,多了一個register注冊到對應名字的平台中的步驟。在這裡面注冊了一個probe方法指針，probe指向的tegra_ion_probe是載入內核模塊注冊的時候調用。
   
   先來看看對應的結構體：
   
   再來看看對應ion內的堆結構體：
   
   完成的事情如下幾個步驟：
   
   我們不關注debug模式。其實整個就是我們分析了很多次的方法。把這個對象注冊miscdevice中。等到insmod就會把整個整個內核模塊從dev_t的map中關聯出來。
   
   我們來看看這個驅動結構體：
   
   文件：/ drivers / staging / android / ion / ion_heap.c
   
   這里有四個不同堆會申請出來，我們主要來看看默認的ION_HEAP_TYPE_SYSTEM對應的heap流程。
   
   其實真正象徵ion的內存堆是下面這個結構體
   
   不管原來的那個heap，會新建3個ion_system_heap，分別order為8，4，0,大於4為大內存。意思就是這個heap中持有一個ion_page_pool 頁資源池子，裡面只有對應order的2的次冪，內存塊。其實就和夥伴系統有點相似。
   
   還會設置flag為ION_HEAP_FLAG_DEFER_FREE，這個標志位後面會用到。
   
   文件：/ drivers / staging / android / ion / ion_page_pool.c
   
   在pool中分為2個鏈表一個是high_items，另一個是low_items。他們之間的區分在此時就是以2為底4的次冪為分界線。
   
   文件：/ drivers / staging / android / ion / ion.c
   
   因為打開了標志位ION_HEAP_FLAG_DEFER_FREE和heap存在shrink方法。因此會初始化兩個回收函數。
   
   文件：/ drivers / staging / android / ion / ion_heap.c
   
   此時會創建一個內核線程，調用ion_heap_deferred_free內核不斷的循環處理。不過由於這個線程設置的是SCHED_IDLE，這是最低等級的時間片輪轉搶占。和Handler那個adle一樣的處理規則，就是閑時處理。
   
   在這個循環中，不斷的循環銷毀處理heap的free_list裡面已經沒有用的ion_buffer緩沖對象。
   
   文件：/ drivers / staging / android / ion / ion_system_heap.c
   
   注冊了heap的銷毀內存的方法。當系統需要銷毀頁的時候，就會調用通過register_shrinker注冊進來的函數。
   
   文件：/ drivers / staging / android / ion / ion_page_pool.c
   
   整個流程很簡單，其實就是遍歷循環需要銷毀的頁面數量，接著如果是8的次冪就是移除high_items中的page緩存。4和0則銷毀low_items中的page緩存。至於為什麼是2的次冪其實很簡單，為了銷毀和申請簡單。__free_pages能夠整頁的銷毀。
   
   文件：/ drivers / staging / android / ion / ion.c
   
   主要就是初始化ion_client各個參數，最後把ion_client插入到ion_device的clients。來看看ion_client結構體：
   
   核心還是調用ion_alloc申請一個ion緩沖區的句柄。最後把數據拷貝會用戶空間。
   
   這個實際上就是找到最小能承載的大小，去申請內存。如果8kb申請內存，就會拆分積分在0-4kb，4kb-16kb，16kb-128kb區間找。剛好dma也是在128kb之內才能申請。超過這個數字就禁止申請。8kb就會拆成2個4kb保存在第一個pool中。
   
   最後所有的申請的page都添加到pages集合中。
   
   文件：/ drivers / staging / android / ion / ion_page_pool.c
   
   能看到此時會從 ion_page_pool沖取出對應大小區域的空閑頁返回上層，如果最早的時候沒有則會調用ion_page_pool_alloc_pages申請一個新的page。由於引用最終來自ion_page_pool中，因此之後申請之後還是在ion_page_pool中。
   
   這里的處理就是為了避免DMA直接內存造成的緩存差異(一般的申請，默認會帶一個DMA標志位)。換句話說，是否打開cache其實就是，關閉了則使用pool的cache，打開了則不使用pool緩存，只依賴DMA的緩存。
   
   我們可以看另一個dma的heap，它是怎麼做到dma內存的一致性.
   文件： drivers / staging / android / ion / ion_cma_heap.c
   
   能看到它為了能辦到dma緩存的一致性，使用了dma_alloc_coherent創建了一個所有強制同步的地址，也就是沒有DMA緩存的地址。
   
   這里出現了幾個新的結構體，sg_table和scatterlist
   
   文件：/ lib / scatterlist.c
   
   這裡面實際上做的事情就是一件：初始化sg_table.
   sg_table中有一個核心的對象scatterlist鏈表。如果pages申請的對象數量<PAGE_SIZE/sizeof(scatterlist),每一項sg_table只有一個scatterlist。但是超出這個數字就會增加一個scatterlist。
   
   用公式來說：
   
   換句話說，每一次生成scatterlist的鏈表就會直接盡可能占滿一頁，讓內存更好管理。
   
   返回了sg_table。
   
   初始化ion_handle，並且記錄對應的ion_client是當前打開文件的進程，並且設置ion_buffer到handle中。使得句柄能夠和buffer關聯起來。
   
   每當ion_buffer需要銷毀，