驱动工程师看安卓源码工具

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需要销毁，