手机开发感想篇

手机开发感想篇（连载）
首先我要说明的是，我对手机开发的了解还是很少，开发的时间也比较短，可是说还是入门阶段，但在从事在方面的工作过程中，个人确实有很多感想，现想拿出来给大家分享分享。如有不到之处，还请大侠们斧正啊！
我毕业有3年多了，早期主要是从事一些ＤＳＣ的开发，也就是ｆｉｒｅｗａｒｅ方面的开发了，直到去年七月份才真正走入手机开发这个行列中来。
对于第一次接触这个东东，确实有些茫然，但由于早期开发的经验和个人对研发产品的理解，我在第一阶段就对手机研发做了如下一些分解。
软件分解：
1、ｏｓ：（这是系统的ｋｅｒｎｅｌ，一般现在我们采用的ｏｓ还多数是国外的，由于
我对此不感兴趣，再者也没有机会接触到，所以就把他当成库来用。：））
2、ＭＭＩ：这个大家都知道了。后面在详细描述。
3、底层驱动：包括ｍｉｄｉ，ａｕｄｉｏ，ｌｃｄ，ｋｅｙｂｏａｒｄ等相关的驱动。
4、ｍｅｄｉａ　ｉｃ驱动。这主要是ｍｐ３，ｍｐｅｇ和ｄｓｃ的驱动。
5、短信：这个是手机不可少的。
6、输入法：嘿嘿，这个东有点难的。
7、电话本相关的管理：这个比较重要。
8、手机的一些其它服务：包括闹钟等相关附加功能。
9、ｗａｐ：主要是上网等功能。
硬件：
1、基带芯片：多半是ａｒｍ＋ＤＳＰ　ｓｏｃ　ｃｐｕ。
2、电源管理芯片：这个不可少的。
3、附加多媒体芯片：（如果用的不是ｍｔｋ平台的话，基本都要加吧）
4、ａｕｄｉｏ　芯片：不可少的哦，没它就每哟声音。
5、ｍｉｄｉ芯片：4和5这两宽目前有很多方案都能合成到一个芯片上了。
6、ｌｃｄ屏：没它，大家能看到什么：）
7、射频模块：用的都是集成的ｉｃ。且要ｂｂ支持。
还有就是键盘，基本也就这些了，其它的都是小模块。重要，但都可以划分到大模块中去。
真是不好意思，这些天太忙了，同时在开发4个项目啊，太累了。
现在我描述下当初我一开始在对软件和硬件做了简单的分类后，个人是如何在分类的基础上学习的。
由于我们所在公司用的是国外手机平台，所以在做任何事情前，首先得了解下这个平台的
运行机制。
对于平台的理解和学习我主要从下面3个方面着手：
1、编译原理和仿真原理；
2、平台的驱动架构；
3、平台的应用架构；
一个成功的平台，其必然有自己一套程序的软件仿真机制和一个ｄｏｗｎｌｏａｄ到手机
中的编译系统。在我们采用的平台中，软件仿真ＩＤＥ用的是.ｎｅｔ，这个东东，刚开始
我还不知道是什么东东呢，不过以我之前接触过嵌入式ＩＤＥ的经历，对它简单的应用上手
还是很快了，不就模拟用用，呵呵，简单啊！（这里有个误区，就是很多人在开始学习的时候，
是多么希望把整个系统搞的很熟很熟，她们认为这样才是学东西，可是我却不这么认为，因为整
个东西你是不可能学会的，你只需要选些你感兴趣并且是热门的知识点就可以了，其它的你只要了解下，
并能简单用用就可以了。把主要精力放在你爱学的方面，学专了，你就是专家，就不愁什么了啊：））
有信心就学会了，软件仿真花了2天时间从安装到模拟，嘿嘿，通过。接着是如何了解编译下载到手机中
的软件的机制；这方面，看了平台提供的手册，发现基本采用ｌｉｎｕｘ的ｍａｋｅｆｉｌｅ编译机制，
唯一不同的是，具体编译过程用的是ｔｃｃ、ＡＤＳ以及ｄｏｓ批处理，呵呵，这个我以前比较熟悉，
所以也没有费什么时间就搞定了，注意我所谓的搞定就是她们的运行原理，而不是理解他编译系统中设计
的所以ｄｓｏ批处理及相关的命令操作。对编译和仿真系统了解后，就开始学习真正的平台软件了。
（我之所以要重复走上面的路，是因为我来公司时候，公司对平台的培训早完成了，所以以后所有的学习都是我自学的！）

现在就开始主要讲具体的开发了，有些朋友好像等的不耐烦了啊：）
二、对于平台的驱动架构，我进行了几个分类：
1、ＤＩ的运行原理；
2、键盘的运行流程；
3、如果外扩ｍｅｄｉａ芯片，了解扩充机制；
4、ａｕｄｉｏ和ｍｉｄｉ的运行流程；
由于我刚进公司，老大就安排我先把公司ｄｅｍｏ显示搞定，呵呵，所以我就的先了解ＬＣＤ的驱动，以及我们平台的ｄｉ运行原理。
当时，我们ＬＣＭ是直接沿用公司早期开发手机ＬＣＭ模块，那个ｌｃｍ和ｌｏｇｉｃ（30万ｉｍａｇｅ处理ｃｈｉｐ）芯片组合在一起的；ｌｃｄ控制器是HD66773，65Ｋｃｏｌｏｒ；我们平台ｌｃｄ的设计采用的是ｂｙｐａｓｓ模式，ｌｃｄ是直接接在ｍｕｌｔｉｍｅｄｉａ芯片上（采用的是台湾芯片，具体型号不好说），ＢＢ通过Ａ2和Ａ3地址线来选通主副ｌｃｄ，ｌｃｄ的硬件复位直接与系统复位接在一起，ｂｙｐａｓｓ控制直接用ｂｂ一个ｇｐｉｏ口控制。刚开始是第一次接触这种彩色ｌｃｄ；所以花了2天时间来看厂商提供的ｌｃｄ驱动程序，看后觉得基本掌握了日系列的ｌｃｄ控制器的基本原理，她们的控制器能控制的寄存器也就40几个左右，主要分为：ｐｏｗｅｒ控制，ｒｅｓｅｔ控制，ｄｉｓｐｌａｙ控制，ａｒｅａ控制，ｇａｍｍａ控制等。掌握以上的控制流程，基本可以点亮ｌｃｄ了，当然，ｌｃｄ的效果调试比较难，需要细细研究，我到现在也不太会，虽然我调试了20几款ｌｃｄ。在对ＬＣＤ的驱动和硬件设计有个初步的了解并编写代码后，基本完成了ｌｃｄ的驱动级别设计，当然随后的工作最重要，就如何把这些驱动代码放到我们平台的驱动架构中去，接着就是必不可少的调试。在我们的平台当中，对ｌｃｄ驱动的初始化放在对ＡＲＭ做了最基本的初始化后，平台提供的源程序有ｌｃｄ驱动的程序，我没有花多少时间就找到了，然后就是用我的ｌｃｄ驱动替代它的ｌｃｄ驱动。这步做完后，我并没有马上去了解我们平台的ｄｉ刷新原理，因为我认为这个时候最重要的就是要把ｌｃｄ调亮，然后再去看系统ｄｉ机制。在具体调试ｌｃｄ的过程中，那简直不是人过的日子啊，我整整调试了1个多星期，最后才调试出来。之所以花这么多时间才调试成功，关键是我首先要了解ｍｕｌｔｉｍｅｄｉａ芯片的基本ｂｙｐａｓｓ原理，代ｉｍａｇｅ　ｃｐｕ　ｌｃｍ具体控制，以及硬件电路的正确否。最后在总结工作中发现，我主要花的时间在对带了ｉｍａｇｅ　ｃｐｕ　ｌｃｍ的控制上。因为ｌｃｍ上多了一个ｃｐｕ，所以我要通过ｉｍａｇｅ
ｃｐｕ来控制ｌｃｄ的控制器，当然，由于当初的ｌｃｄ硬件电路上和ｂｂ的ｂｕｓ时序还有些问题。（对于以上的具体我将不描述了，因为这种现象一般大家很难遇到啊！）在ｌｃｄ调试成功后，我得赶紧看我们平台的ｄｉ运行机制，这方面我请教了我们公司其它的员工，花了一天的时间，大概了解运行原理。在我们这个平台，把显示作为一个ｔａｓｋ来运行，当运行这个ｔａｓｋ的时候，就会调用ｌｃｄ的的刷新函数，把需要刷新的数据刷到ｌｃｄ上，当然，系统开了一个ｌｃｄ刷新数据的ｂｕｆｆｅｒ，用来存储ＭＭＩ层刷逻辑ｌｃｄ的数据。在ｌｃｄ驱动这块，就直接把这个ｂｕｆｆｅｒ刷到ｌｃｄ上。在完完全全走通上面的工程中，我花了2周多时间，同时对ＤＩ的运行原理有了一个比较系统，但是不是很详细的了解。

四、
写得太慢了，让各位大侠等急了啊：）
上次讲了下关于我们手机平台的ＤＩ运行原理，如有不正之处，请大侠们指出来。这回我就讲讲键盘的运行流程；说到键盘，估计各位都或多或少的写过相关的程序，我在接触手机键盘之前，也写过一些嵌入式设备的简单键盘驱动程序，记得最复杂的一次键盘驱动是用ｃｐｌｄ写了一个20个键的键盘扫描驱动，ｃｐｌｄ把扫描到的键值通过ｂｕｓ传给51ｃｐｕ（当初我是用ｃ５１做主ｃｐｕ的：），当时的设计是把51外扩地址0ｘ7ｆｆｆ作为键盘值存放地址。），ｃｐｕ这边我是做了一个时间片轮系统，对于键盘的扫描是没20ｍｓ做一次，去抖2ｍｓ，当时用起来还算比较稳定，没有任何问题。可是如今我接触到我们手机平台的键盘处理，感觉自己以前的键盘处理简直是太笨了，想法太简单。我们目前ＢＢ端都有直接的键盘接口， 5Ｘ5的键盘，硬件只要把横竖5条线直接接到10　个键盘口上就可以了，至于当有按键的时候，键盘ｉｏ口有中断响应，上面我之所以说我们平台的手机键盘做的好，主要是说它的驱动做的好。从我对程序代码的理解，我们平台的键盘驱动主要由以下一些状态组成：
1、  键盘硬件中断：这块主要是键盘口有电压变化，从而触发键盘的中断，ＢＢ端ｃｐｕ就会进入中断处理程序块；
2、  中断程序入口：这块写的特别巧，所有的中断初始化，中断处理程序都统一放到一个具有回调功能的数组里处理，对编写程序的人员来说，整个系统中断管理清晰，代码简洁，关于其具体代码这里就不一一描述。
3、  中断服务程序：这段也做了一些特殊的处理，当键盘中断来了后，首先是通过上面的中断程序入口的回调直接到中断服务程序中去，中断服务程序首先是扫描中断过来的键码，在得到键码后，马上启动一个最高级别的定时器，其大概是20ｍｓ，在20ｍｓ的定时器到后，又来扫描这个时候的键盘键码，如果键码一样，就把这个键码发到应用处理层的ｔａｓｋ中去。如果在定时器还没有到的时候，有键盘中断来，那么前面一次的处理全部释放，定时器解除，直接处理下次中断。
4、  以上就是关于我们手机平台的底层键盘驱动的大致框架，个人认为这个框架对嵌入式的设备的键盘处理都有很好的借鉴作用。当然，关于上层键盘的应用处理也是十分关键的，不过底层的键盘处理时间短，那么整个系统对按键的响应比较快，对整个手机的菜单处理就越有利；
关于键盘的流程我就简单将将，因为这块我想了想，实在不好描述啊，如果是看过一些相关代码的话，对其理解就更好了，当然我不能直接移植代码到这里来，所以不太理解的地方，欢迎各位一起来探讨。
五、
关于aquasnake兄说的建议非常之好，不过我们平台确实可以在启动2０ＭＳ的定时器期间可以响应键盘中断，同时我说的最高级别定时器，其意义在于这个定时不在中断内，而是在系统最高定时器所在的ｔａｓｋ中运行。当时间到了之后，会回调定时器启动时候写入的回调函数。
外扩ｍｅｄｉａ芯片的问题。
其实我最主要的时间就是花在这块上，所以对于这块我将会详细讲讲，让大家和我一起分享下ｍｅｄｉａ中的乐趣。我们外扩ｍｅｄｉａ芯片用的是台湾ｓｕｎｐｌｕｓ公司的；相信各位对此都有些了解。ｓｕｎｐｌｕｓ的手机ｍｅｄｉａ芯片在目前的市场上，其性能只能算中等，与韩国一些芯片相当，比ｔｉ级别的要差些，但ｓｕｎｐｌｕｓ的价格还可以，在做中端手机选择ｓｕｎｐｌｕｓ还是有些优势，不过就是在运行ｍｐ3功能的时候，功耗偏大。闲话就不说了，回归到我刚开始接触这款ｍｅｄｉａ时候的情景吧。刚开始接触的时候，我以为我们公司会叫我负责ｍｅｄｉａ芯片功能的维护，谁知道，后来和ｓｕｎｐｌｕｓ沟通后，发现我们只是在ｂｂ端来调用ｓｕｎｐｌｕｓ已经做好的ａｐｉ，让后用这些ａｐｉ来实现类是于ｍｐ３，ｍｐ４等功能，乍一听做这些，感觉挺没有意思的，就是用用ａｐｉ，感觉太简单了，可是在后来的应用中发现，其难度还是很大的，尤其是做好，那难度还是非常之大啊。
前面讲过了ｌｃｄ的调试，其实在ＬＣＤ的调试过程中，就已经涉及到了ｍｅｄｉａ芯片的ｂｙｐａｓｓ功能，直接通过ｍｅｄｉａ芯片的ｂｙｐａｓｓ　ｈｉｇｈ功能把总线上的ｌｃｄ数据通过ｍｅｄｉａ芯片送到ｌｃｄ上，之所以要通过ｍｅｄｉａ芯片接ｌｃｄ，是因为，在后续的拍照。录像，ｌｃｄ的数据是直接由ｍｅｄｉａ送到ｌｃｄ上，而不是通过ｂｂ送到ｌｃｄ，提高刷屏速度，减少ｂｂ端ｃｐｕ的资源。
说到ｂｙｐａｓｓ功能，相信各位都很熟悉啊，我对此也上了解，谈不上深刻，不过ｂｙｐａｓｓ的功能于具体的ｍｅｄｉａ芯片有关系，如果ｍｅｄｉａ芯片做的好的话，ｂｙｐａｓｓ功能的高低切换基本不需要做什么延时，对于国内的ｃ625，我只是看过一些资料，但没有详细用过，不知道其ｂｙｐａｓｓ功能性能，但我调试过台湾两家其它小公司的ｍｅｄｉａ芯片，发现其ｂｙｐａｓｓ功能的切换时间比较长，需要延时，所以在调试过程中要特别注意。在理解了ｂｙｐａｓｓ功能之后，我就研究下ｍｅｄｉａ和ｂｂ端的通信协议，根据ｓｕｎｐｌｕｓ提供的一些上层代码，同时再听她们ＦＡＥ讲解了一些关于通信协议的问题，我基本了解了这种通信机制，这种通信机制硬件主要采用的是总线ｉ８６接法，软件能用的是ｍａｓｔｅｒ和ｓｌａｖｅ通信原理，ｂｂ是ｍａｓｔｅｒ，ｍｅｄｉａ是ｓｌａｖｅ，ｂｂ端下ｃｍｄ给ｍｅｄｉａ，然后查询ｃｍｄ是否发送成功已经ｍｅｄｉａ是否正确执行ｃｍｄ；这样的机制很简单，便于软件和硬件的连接和驱动，可是其由于简单的通信机制，会给ｂｂ对整个系统的可靠运行增加负担，比如说ｃｍｄ命令不成功，ｂｂ端将如何处理等问题。当然ｓｕｎｐｌｕｓ底层的软件跑的还是非常稳定。很少出现这样的问题。在理解了ｂｙｐａｓｓ和通信机制后，在ｂｂ做相应的驱动和应用ａｐｉ就简单多了。
_xyz