- 浏览: 720335 次
- 性别:
- 来自: 湖北
文章分类
最新评论
-
SE_XiaoFeng:
用mysqldump命令行导出。这个报错唉。错误提示信息如下: ...
linux下如何导入导出MySQL数据库 -
SE_XiaoFeng:
文章写的干脆了当,我喜欢!
linux下如何导入导出MySQL数据库 -
niky6688:
网站咋打不开呢
beckham herms birki ...
【原创】上周给公司新做了一个网站,请大家审阅! -
niky6688:
哈哈
new chanel bags 2012
burbe ...
今天我抢了一个咪咪??? -
ydsakyclguozi:
...
jsp资源管理器也可能是木马
一、 目的
来到这里近两月,更近距离的接近了MTK。身处基于MTK平台的产品开发浪潮之中,让我对MTK有更多的了解,不光是在平台技术本身。就技术上,从软件角度、系统角度,对MTK我应该能给出深度而全面的评价或看法。就产品上,我也有自己的一些见解和思考。总之,对于MTK我所产生的思考及结论,希望能在这里同大家分享。如果能抛砖引玉,引发大家更有意义及价值的思考,是我此文最大的愿望。
二、 适用范围
全体
三、 定义
无
四、 前言
MTK是一个伟大的公司。在舆论批评山寨,并间接批评MTK的时候,我们只能认为这是产业成功而引起的喧闹中的一种形式。 MTK在手机市场快速发展的时候,我投身所谓在振兴民族通信产业的TD领域。那时我经常提及MTK,MTK在01年起步,在04年面向市场,花了3年时间。在一个已经成熟的GSM网络,完成一个终端平台的商用,花了3年时间。而对于一个还处于实验室阶段的TD平台,它的成熟花个3年时间是起码的。这是我经常向别人解释为什么TD终端还不成熟的理由或者借口。在努力促使TD终端商用化的过程中,经受了3年各种各样的煎熬,有网络、平台、应用、项目、市场等方方面面,让我更感觉MTK方案设计有很多可取之处。下面,我就将我所了解到的与MTK平台有关的任何细节的东西,都一一列举出来,重点还是在软件部分。
五、 MTK方案
04年,多媒体手机开始兴起。MTK方案的技术核心就是基带芯片支持多媒体功能,降低了成本,加速了多媒体手机产品的上市时间。MTK方案的服务核心就是turnkey模式,一改ADI、infineon等方案那种“能在我的方案上做什么卖给用户”的思维方式,而是“我的方案能直接卖给什么用户”。
MTK在基带芯片中集成LCD控制器、CAMERA控制器、多媒体CODEC。这种方式,自然是外带多媒体协处理器从成本及开发周期上无法比拟的。ADI、infineon、agere、TI等方案的出局就成必然。但为什么这些欧美公司在方案上不做调整呢?可能的原因是,在失去技术核心竞争力以及领跑优势后,和中国公司站在同一起跑线竞争太难。中国人能吃苦,老外要渡假。
MTK将能做的功能,基本上都给客户做好。这大大缩短了客户的研发周期,也就是所谓的降低了技术门槛。从节约社会劳动力,提高社会整体效益的角度讲,MTK的方式是合理的。它避免了N个客户的重复劳动,重复的走弯路。从这个角度讲,TI方案最次,连BASIC MMI都没有,还停留在早期做GSM手机的模式。
MTK这种直面客户的模式,也最大力度的支持着手机终端生产者,花最大的精力在如何降低成本及创新去迎合消费者需求,提升他们本来就缺乏的核心竞争力。山寨机的存在,说明有这样一群消费者需要成本低廉、多样性的手机产品,并容忍产品的细节性缺陷。
六、 MTK软件平台
做过的手机平台有好几个,但都是Feature phone。目前做手机,可以说是在高科技产品光环下的系统集成,需要一定的技术实力,但更多的是平台积累的经验。特别是软件,平台之间的切换很麻烦。越是更多的依赖积累于某一平台的经验,切换到其他平台就更麻烦。越是做过多的平台具体工作,切换到其他平台就越麻烦。因此,我非常看好智能手机的前景,尽管现在市场存在问题,未来几年的市场仍然存在问题。在未来,支撑智能操作系统的硬件配置成本不再可怕的时候,智能手机必然是首选,是MTK turnkey模式发展方向的终极模式。
我了解MTK软件平台,主要是先看支撑软件平台的硬件方案。方案之间的差异化竞争,核心还是在硬件方案的差异化。但是所有的方案,从框架上来讲,都是大同小异。最大的同,都是基于同一个ARM核,可能有基于基带应用的不同,在PLL、CACHE、协处理器以及外围控制器上的小异。即使使用C166的infineon方案,性能虽然有差异,但从使用角度讲,原理是一样的。
针对MTK软件平台,我看过它的启动过程、内存分配机制、编译机制、GUI机制、RTOS、文件系统以及非常重要的基带芯片资料(主要是6225)。在阅读MTK方案的过程中,关键之处我都做了记录,一直就想找个机会对这些做一整理。
6.1 启动过程
MT6305上电给基带芯片供电,在一定时序条件后,给基带芯片复位信号,开始了ARM核的启动过程。要谈启动,我们必须熟悉Scatter file、基带资料的Memory mapping章节。Scatter file定义了load region和excecute region,我们要关心系统运行时代码、数据的地址分布。
Bootarm.s是一个重要的文件,与启动过程有关,其中的INT_Initialize函数是ARM启动开始执行的代码。BSP所做的事情主要包括:
1、配置PLL,配置基带芯片的EMI参数,以让系统能够以最大的速度读取外部存储设备数据,让CPU以最大速度运行,从而缩短启动过程。
2、做好runtime代码及数据的准备,确保excecute region的代码及数据到位。
3、配置好ARM七种异常模式的堆栈,进入RTOS nucleus的初始化。
4、nucleus留给客户的初始化函数Application_Initialize,做了平台该做的初始化工作,比如外部控制器的初始化等等。
6.2 RTOS
在分析系统问题,开发跨线程应用时,必须熟悉RTOS。目前使用的RTOS是nucleus,尽管在BSP中看到了它对ThreadX的支持。不同的RTOS,实际上也是大同小异,但是具体的API或者参数会有不同,因此我们需要下载nucleus的API文档,在需要了解细节时,可以翻阅此文档。同时,TRACE32支持基于RTOS级别的调试,因此对RTOS的了解,有助于提高调试能力。
有点特殊的是,nucleus有 LISR,HISR的概念,实际上它是一种给开发者的印象。它告诉开发者,中断处理函数LISR要尽量的耗时短,以确保其它中断能有机会及时响应。HISR再处理略为次要些的工作,但耗时也不能太长,因为HISR比任何TASK的优先级都高,我们应该让真正需要实时的工作获取CPU的机会。
Application_Initialize中的mainp函数,负责任务的创建。我们在代码中见不到任务创建的函数,只需要维护任务初始化参数数据结构。对于系统的那些task信息,都保存在sys_comp_config_tbl变量中,我们看不到。但是MTK提供给客户的custom_comp_config_tbl,客户是可以修改的,在这里用户可以定义自己的task。
关于任务,需要关心数据结构comptask_handler_struct。关于comptask_handler_struct成员的执行顺序,应该是:comp_init_func 在系统还未 schedule 即在Application_Initialize中完成,然后task schedule后执行comp_entry_func。comp_cfg_func、comp_reset_func、comp_end_func我认为无太多意义。
task和module有什么区别?可以肯定的是,task 是操作系统层面的概念,module是软件平台设计者因为某种需要而设计的,可能大家比我更清楚,但这种概念在具体工作中可能还是需要弄清楚。
到此,基于RTOS的各个TASK应该都已经调度起来。首先毫无疑问,idle task必须是优先级最低的task。按照常理,系统会从最高优先级的任务开始调度,至于如何跑到MMI显示LOGO界面,在必要时,我们可以去研究。
6.3 GUI机制
至于MMI framewok,我未做太多了解,但任何GUI系统面对的都是最终的LCD bufffer。但不同的是,MTK的基带芯片搞了个LCD控制器,并加了layer的概念,从硬件上支持2D function和加速LCD的刷屏。对于上层的GUI,要做的是选择哪个layer是active。
LCD控制器的刷屏机制。以6225为例,支持4 layer。MTK资料对LCD控制器未做详细的描述,如图1是其对LCD接口块图的描述。但通过LCD控制器驱动,我们可以对LCD控制器内部结构做更多的假设。图1中的Overlay,我们可以设想为一个专有的DMA控制器通道,目标地址为LCD,源地址是layer buffer。系统通过配置要刷哪几层,配置alpha值来控制2D效果。这一目的的达到,硬件上有它的考虑,我们也没有必要做太多确定性的假想。
图1 LCD接口块图
需要说明的是,仅仅是这样一张图,我们应该有更多的联想。Layer buffer都是从外部RAM开辟的内存空间,LCD的访问时序完全决定于如何配置LCD控制器。对Layer buffer的读写,需要占用系统总线,即使再做总线上的区域规划,外部RAM的数据总线是公共资源。对公共资源的访问,就意味着并发,意味着仲裁ARBITER。为什么在以前的项目中,出现一些关于LCD的莫名其妙的问题,不能说这里是根本原因,但我们应该从系统的角度去注意到这点。我对资源的占有,就意味着别人的失去。以往被掩盖的缺陷,可能会因为系统运行时的变化,暴露出来。这就是我认为,有些系统问题,不能从代码表面去分析,而要从ARM核的角度,从同cache,BUS,controller等外围设备之间的联系来系统的分析问题。
关注一下开机LOGO的显示,是在uem_poweron_timer_expiry_hdlr函数中,同时这里做了latch power的动作。还有潜力,提前显示出LOGO。
6.4 内存分配机制
在MTK的资料中,介绍了它的内存管理机制,有3种:ADM、Control buffer、System Memory。后两个是系统使用的,与上层应用无关。但是我对kal_system_alloc也做了初步分析。
sys_mem_ptr,其估计应该指向的是 System_Mem_Pool, debug_mem_ptr,其估计应该指向的是 debug_Mem_Pool。 经过初步分析,kal_system_alloc就是从System_Mem_Pool做简单的加法操作,sys_mem_left_size就是System_Mem_Pool还剩下多少。kal_system_alloc从sys_mem_ptr开始来计算要取的内存。ctrl_buf是通过kal_system_alloc的内存,然后再通过NU_Create_Partition_Pool创建POOL。系统的一些task stack.等也都是通过kal_system_alloc来分配的。
也就是说,Control buffer、System Memory用的都是System_Mem_Pool的空间。而System_Mem_Pool可以查到,是在custom_configmem函数中配置。
ADM就完全没有使用操作系统提供的内存管理算法,是平台自创了一套。开发者,可以自己开辟一个POOL,自己在这个池用ADM提供的内存管理API完成内存的动态管理。具体的分配算法,就没有再细看,跟一些通用的内存分配算法应该一致。但是在以前调试一个问题的时候,应该是可以断定,ADM在每一个alloc node前后都加了GAP调试区,来判断是否被overwrite。
至于系统中,到底是用了多少块内存用于ADM,各块内存又是让哪些应用在共享,开发者可能更清楚。在系统中是否建立了对内存动态分配的监控机制,比如查询内存泄漏、动态内存使用效率等等。
6.5 文件系统
文件系统用的是FAT格式,最关键的是如何MOUNT存储设备,如何匹配文件系统读写接口。MTK通过表格的形式来让客户选择支持的flash,真的是很方便,考虑太周到。
6.6 编译机制
MTK的makefile,写的很复杂,有perl脚本,也有make脚本,但框架结构很好。虽然我对makefile结构通读了一遍,但没有仔细花时间对此形成文档。
6.7 方案印象
MTK软件平台,接触了一年,总体感觉其底层代码写的很工整,结构很清晰。越到上层,代码就显的庞大凌乱,结构性和可读性都不强。如果把芯片设计也说上,我觉得MTK的基带芯片设计很智慧,针对特定的多媒体手机应用,设计出专门的控制器嵌入芯片内部。像uart控制virtrual fifo 和camera的resizer以及lcd controller,用低成本控制器来快速完成逻辑,从而减轻CPU的负担,提高芯片的整体性能。在其他多媒体处理器中,都是不多见的。
与业界认为从事MTK平台开发的技术含量低恰恰相反,我认为MTK方案技术含量非常高。MTK软件平台的代码开放程度也不低,MTK的技术支持也非常有力而迅速,以MTK平台为基础的终端承载了最丰富多样的应用。MTK方案给希望对手机平台有深入而全面了解的同事提供了机会。
七、 基于MTK平台的产品开发
有那么多的公司在做基于MTK平台的产品,竞争那么激烈,研发上如何在竞争中体现优势?硬件上,大家都一样。软件上,也是一样。你可以有,别人也可以有或者偷,别人可以有,我们也可以有或者偷。最多是差个把月,怎么办。一个中心两个基本点。以服务好客户为中心,保证两个基本点,一是要快,二是差异。
拉不到客户什么就不要做了。在大家都差不多的情况下,我们以客户为中心,快速的满足客户需求,提供产品。这样能拉住客户,让客户找不到离开的理由。第二是产品差异,是创新。如果有产品创新最好,要么降低了成本,要么吸引了消费者。但这两点中,还是快字最重要,这是可以通过团队专业实力和激情来保证的。但是创新,有运气的成分,需要研发同市场碰撞出火花。鼓励和激励创新,但不能只靠产品创新一定会出现。
总结起来,又回到管理二字上。依靠内部项目和质量管理保证产品研发速度、保证客户服务质量。
转至:http://www.rd3721.com/bbs/dispbbs.asp?BoardID=88&ID=21200
来到这里近两月,更近距离的接近了MTK。身处基于MTK平台的产品开发浪潮之中,让我对MTK有更多的了解,不光是在平台技术本身。就技术上,从软件角度、系统角度,对MTK我应该能给出深度而全面的评价或看法。就产品上,我也有自己的一些见解和思考。总之,对于MTK我所产生的思考及结论,希望能在这里同大家分享。如果能抛砖引玉,引发大家更有意义及价值的思考,是我此文最大的愿望。
二、 适用范围
全体
三、 定义
无
四、 前言
MTK是一个伟大的公司。在舆论批评山寨,并间接批评MTK的时候,我们只能认为这是产业成功而引起的喧闹中的一种形式。 MTK在手机市场快速发展的时候,我投身所谓在振兴民族通信产业的TD领域。那时我经常提及MTK,MTK在01年起步,在04年面向市场,花了3年时间。在一个已经成熟的GSM网络,完成一个终端平台的商用,花了3年时间。而对于一个还处于实验室阶段的TD平台,它的成熟花个3年时间是起码的。这是我经常向别人解释为什么TD终端还不成熟的理由或者借口。在努力促使TD终端商用化的过程中,经受了3年各种各样的煎熬,有网络、平台、应用、项目、市场等方方面面,让我更感觉MTK方案设计有很多可取之处。下面,我就将我所了解到的与MTK平台有关的任何细节的东西,都一一列举出来,重点还是在软件部分。
五、 MTK方案
04年,多媒体手机开始兴起。MTK方案的技术核心就是基带芯片支持多媒体功能,降低了成本,加速了多媒体手机产品的上市时间。MTK方案的服务核心就是turnkey模式,一改ADI、infineon等方案那种“能在我的方案上做什么卖给用户”的思维方式,而是“我的方案能直接卖给什么用户”。
MTK在基带芯片中集成LCD控制器、CAMERA控制器、多媒体CODEC。这种方式,自然是外带多媒体协处理器从成本及开发周期上无法比拟的。ADI、infineon、agere、TI等方案的出局就成必然。但为什么这些欧美公司在方案上不做调整呢?可能的原因是,在失去技术核心竞争力以及领跑优势后,和中国公司站在同一起跑线竞争太难。中国人能吃苦,老外要渡假。
MTK将能做的功能,基本上都给客户做好。这大大缩短了客户的研发周期,也就是所谓的降低了技术门槛。从节约社会劳动力,提高社会整体效益的角度讲,MTK的方式是合理的。它避免了N个客户的重复劳动,重复的走弯路。从这个角度讲,TI方案最次,连BASIC MMI都没有,还停留在早期做GSM手机的模式。
MTK这种直面客户的模式,也最大力度的支持着手机终端生产者,花最大的精力在如何降低成本及创新去迎合消费者需求,提升他们本来就缺乏的核心竞争力。山寨机的存在,说明有这样一群消费者需要成本低廉、多样性的手机产品,并容忍产品的细节性缺陷。
六、 MTK软件平台
做过的手机平台有好几个,但都是Feature phone。目前做手机,可以说是在高科技产品光环下的系统集成,需要一定的技术实力,但更多的是平台积累的经验。特别是软件,平台之间的切换很麻烦。越是更多的依赖积累于某一平台的经验,切换到其他平台就更麻烦。越是做过多的平台具体工作,切换到其他平台就越麻烦。因此,我非常看好智能手机的前景,尽管现在市场存在问题,未来几年的市场仍然存在问题。在未来,支撑智能操作系统的硬件配置成本不再可怕的时候,智能手机必然是首选,是MTK turnkey模式发展方向的终极模式。
我了解MTK软件平台,主要是先看支撑软件平台的硬件方案。方案之间的差异化竞争,核心还是在硬件方案的差异化。但是所有的方案,从框架上来讲,都是大同小异。最大的同,都是基于同一个ARM核,可能有基于基带应用的不同,在PLL、CACHE、协处理器以及外围控制器上的小异。即使使用C166的infineon方案,性能虽然有差异,但从使用角度讲,原理是一样的。
针对MTK软件平台,我看过它的启动过程、内存分配机制、编译机制、GUI机制、RTOS、文件系统以及非常重要的基带芯片资料(主要是6225)。在阅读MTK方案的过程中,关键之处我都做了记录,一直就想找个机会对这些做一整理。
6.1 启动过程
MT6305上电给基带芯片供电,在一定时序条件后,给基带芯片复位信号,开始了ARM核的启动过程。要谈启动,我们必须熟悉Scatter file、基带资料的Memory mapping章节。Scatter file定义了load region和excecute region,我们要关心系统运行时代码、数据的地址分布。
Bootarm.s是一个重要的文件,与启动过程有关,其中的INT_Initialize函数是ARM启动开始执行的代码。BSP所做的事情主要包括:
1、配置PLL,配置基带芯片的EMI参数,以让系统能够以最大的速度读取外部存储设备数据,让CPU以最大速度运行,从而缩短启动过程。
2、做好runtime代码及数据的准备,确保excecute region的代码及数据到位。
3、配置好ARM七种异常模式的堆栈,进入RTOS nucleus的初始化。
4、nucleus留给客户的初始化函数Application_Initialize,做了平台该做的初始化工作,比如外部控制器的初始化等等。
6.2 RTOS
在分析系统问题,开发跨线程应用时,必须熟悉RTOS。目前使用的RTOS是nucleus,尽管在BSP中看到了它对ThreadX的支持。不同的RTOS,实际上也是大同小异,但是具体的API或者参数会有不同,因此我们需要下载nucleus的API文档,在需要了解细节时,可以翻阅此文档。同时,TRACE32支持基于RTOS级别的调试,因此对RTOS的了解,有助于提高调试能力。
有点特殊的是,nucleus有 LISR,HISR的概念,实际上它是一种给开发者的印象。它告诉开发者,中断处理函数LISR要尽量的耗时短,以确保其它中断能有机会及时响应。HISR再处理略为次要些的工作,但耗时也不能太长,因为HISR比任何TASK的优先级都高,我们应该让真正需要实时的工作获取CPU的机会。
Application_Initialize中的mainp函数,负责任务的创建。我们在代码中见不到任务创建的函数,只需要维护任务初始化参数数据结构。对于系统的那些task信息,都保存在sys_comp_config_tbl变量中,我们看不到。但是MTK提供给客户的custom_comp_config_tbl,客户是可以修改的,在这里用户可以定义自己的task。
关于任务,需要关心数据结构comptask_handler_struct。关于comptask_handler_struct成员的执行顺序,应该是:comp_init_func 在系统还未 schedule 即在Application_Initialize中完成,然后task schedule后执行comp_entry_func。comp_cfg_func、comp_reset_func、comp_end_func我认为无太多意义。
task和module有什么区别?可以肯定的是,task 是操作系统层面的概念,module是软件平台设计者因为某种需要而设计的,可能大家比我更清楚,但这种概念在具体工作中可能还是需要弄清楚。
到此,基于RTOS的各个TASK应该都已经调度起来。首先毫无疑问,idle task必须是优先级最低的task。按照常理,系统会从最高优先级的任务开始调度,至于如何跑到MMI显示LOGO界面,在必要时,我们可以去研究。
6.3 GUI机制
至于MMI framewok,我未做太多了解,但任何GUI系统面对的都是最终的LCD bufffer。但不同的是,MTK的基带芯片搞了个LCD控制器,并加了layer的概念,从硬件上支持2D function和加速LCD的刷屏。对于上层的GUI,要做的是选择哪个layer是active。
LCD控制器的刷屏机制。以6225为例,支持4 layer。MTK资料对LCD控制器未做详细的描述,如图1是其对LCD接口块图的描述。但通过LCD控制器驱动,我们可以对LCD控制器内部结构做更多的假设。图1中的Overlay,我们可以设想为一个专有的DMA控制器通道,目标地址为LCD,源地址是layer buffer。系统通过配置要刷哪几层,配置alpha值来控制2D效果。这一目的的达到,硬件上有它的考虑,我们也没有必要做太多确定性的假想。
图1 LCD接口块图
需要说明的是,仅仅是这样一张图,我们应该有更多的联想。Layer buffer都是从外部RAM开辟的内存空间,LCD的访问时序完全决定于如何配置LCD控制器。对Layer buffer的读写,需要占用系统总线,即使再做总线上的区域规划,外部RAM的数据总线是公共资源。对公共资源的访问,就意味着并发,意味着仲裁ARBITER。为什么在以前的项目中,出现一些关于LCD的莫名其妙的问题,不能说这里是根本原因,但我们应该从系统的角度去注意到这点。我对资源的占有,就意味着别人的失去。以往被掩盖的缺陷,可能会因为系统运行时的变化,暴露出来。这就是我认为,有些系统问题,不能从代码表面去分析,而要从ARM核的角度,从同cache,BUS,controller等外围设备之间的联系来系统的分析问题。
关注一下开机LOGO的显示,是在uem_poweron_timer_expiry_hdlr函数中,同时这里做了latch power的动作。还有潜力,提前显示出LOGO。
6.4 内存分配机制
在MTK的资料中,介绍了它的内存管理机制,有3种:ADM、Control buffer、System Memory。后两个是系统使用的,与上层应用无关。但是我对kal_system_alloc也做了初步分析。
sys_mem_ptr,其估计应该指向的是 System_Mem_Pool, debug_mem_ptr,其估计应该指向的是 debug_Mem_Pool。 经过初步分析,kal_system_alloc就是从System_Mem_Pool做简单的加法操作,sys_mem_left_size就是System_Mem_Pool还剩下多少。kal_system_alloc从sys_mem_ptr开始来计算要取的内存。ctrl_buf是通过kal_system_alloc的内存,然后再通过NU_Create_Partition_Pool创建POOL。系统的一些task stack.等也都是通过kal_system_alloc来分配的。
也就是说,Control buffer、System Memory用的都是System_Mem_Pool的空间。而System_Mem_Pool可以查到,是在custom_configmem函数中配置。
ADM就完全没有使用操作系统提供的内存管理算法,是平台自创了一套。开发者,可以自己开辟一个POOL,自己在这个池用ADM提供的内存管理API完成内存的动态管理。具体的分配算法,就没有再细看,跟一些通用的内存分配算法应该一致。但是在以前调试一个问题的时候,应该是可以断定,ADM在每一个alloc node前后都加了GAP调试区,来判断是否被overwrite。
至于系统中,到底是用了多少块内存用于ADM,各块内存又是让哪些应用在共享,开发者可能更清楚。在系统中是否建立了对内存动态分配的监控机制,比如查询内存泄漏、动态内存使用效率等等。
6.5 文件系统
文件系统用的是FAT格式,最关键的是如何MOUNT存储设备,如何匹配文件系统读写接口。MTK通过表格的形式来让客户选择支持的flash,真的是很方便,考虑太周到。
6.6 编译机制
MTK的makefile,写的很复杂,有perl脚本,也有make脚本,但框架结构很好。虽然我对makefile结构通读了一遍,但没有仔细花时间对此形成文档。
6.7 方案印象
MTK软件平台,接触了一年,总体感觉其底层代码写的很工整,结构很清晰。越到上层,代码就显的庞大凌乱,结构性和可读性都不强。如果把芯片设计也说上,我觉得MTK的基带芯片设计很智慧,针对特定的多媒体手机应用,设计出专门的控制器嵌入芯片内部。像uart控制virtrual fifo 和camera的resizer以及lcd controller,用低成本控制器来快速完成逻辑,从而减轻CPU的负担,提高芯片的整体性能。在其他多媒体处理器中,都是不多见的。
与业界认为从事MTK平台开发的技术含量低恰恰相反,我认为MTK方案技术含量非常高。MTK软件平台的代码开放程度也不低,MTK的技术支持也非常有力而迅速,以MTK平台为基础的终端承载了最丰富多样的应用。MTK方案给希望对手机平台有深入而全面了解的同事提供了机会。
七、 基于MTK平台的产品开发
有那么多的公司在做基于MTK平台的产品,竞争那么激烈,研发上如何在竞争中体现优势?硬件上,大家都一样。软件上,也是一样。你可以有,别人也可以有或者偷,别人可以有,我们也可以有或者偷。最多是差个把月,怎么办。一个中心两个基本点。以服务好客户为中心,保证两个基本点,一是要快,二是差异。
拉不到客户什么就不要做了。在大家都差不多的情况下,我们以客户为中心,快速的满足客户需求,提供产品。这样能拉住客户,让客户找不到离开的理由。第二是产品差异,是创新。如果有产品创新最好,要么降低了成本,要么吸引了消费者。但这两点中,还是快字最重要,这是可以通过团队专业实力和激情来保证的。但是创新,有运气的成分,需要研发同市场碰撞出火花。鼓励和激励创新,但不能只靠产品创新一定会出现。
总结起来,又回到管理二字上。依靠内部项目和质量管理保证产品研发速度、保证客户服务质量。
转至:http://www.rd3721.com/bbs/dispbbs.asp?BoardID=88&ID=21200
发表评论
-
C中的库文件咋使用
2010-05-10 17:51 856C系统提供了丰富的 ... -
用C打印菱形星号
2010-05-10 15:53 2164总结了一下: //这是做简单的,不考虑任何算法,傻X ... -
什么ARM
2010-04-27 18:03 992ARM(Advanced RISC Machines)是微处理 ... -
经典 算法 回顾
2010-04-26 13:36 671=============================== ... -
【原创】C++ 中 extern "C" 用法小结
2010-04-22 22:03 1099昨天晚上翻《C++ Primer》偶尔看见介绍 extern ... -
【汇总】关于位 字节 的换算
2010-04-22 13:24 7751Byte = 8 Bit 1 KB = 1,024 Byte ... -
关于宏定义需要注意的几点
2010-04-22 10:03 2011对于宏定义还要说明以下几点: 1) 宏定义是用宏 ... -
C语言中的基本类型和构造类型以及指针类型还有空类型,它们之间有何区别
2010-04-21 15:31 12041. 基本数据类型:基本数据类型最主要的特点是,其值不可以再分 ... -
使用scanf函数还必须注意以下几点
2010-04-21 13:59 992使用scanf函数还必须注意以下几点: 1) s ... -
字符串常量和字符常量的区别
2010-04-21 11:15 2381字符串常量和字符常量 ... -
C语言中字符常量于字符串常量有什么区别
2010-04-20 13:41 2168单引号里一个字符为字符常量,如:‘A’ 字符常量可以保存在一个 ... -
C宏定义的简单总结
2010-04-19 15:48 880今天在网上突然发现了下面几个关于c代码中的宏定义的 ... -
C语言中如何使用宏
2010-04-19 14:07 1081C(和C++)中的宏(Macro ... -
C/C++基础知识:typedef用法小结
2010-04-17 20:01 990转至http://www.kuqin.com/language ... -
C语言中常见得错误汉语解释
2010-04-16 21:51 695详情见附件 -
【原创】C 经典 冒泡排序 算法
2010-04-16 16:58 928#include <stdio.h> //C ... -
【最全】完整ASCII码对照表
2010-04-14 20:36 1920见 附件
相关推荐
MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK MTK
MTK WIFI GPIO 配置 MTK5931
MTK 刷机工具 WWR WWR MTK v2.40
MTK 软件包MTK 软件包MTK 软件包
MTK刷机平台 MTK刷机平台 MTK刷机平台 MTK刷机平台 MTK刷机平台 MTK刷机平台 MTK刷机平台
联发科刷机win10驱动, MTK = "laurentiumihet.ro" MTK6218 = "MTK USB Port" MTK_COM = "MTK USB Modem Port" MTK_CAT = "MTK USB Debug Port" MTK_PRELOADER = "...
MTK-COM MTK方案串口读写软件2
MTK配置文件参数说明MTK配置文件参数说明 MTK配置文件参数说明MTK配置文件参数说明 MTK配置文件参数说明 MTK配置文件参数说明
MTK 刷机工具 WWR WWR MTK v2.30
MTK CVE-2020-0069 su文件 使用方式翻译和解释 add by https://blog.csdn.net/OneT1me 1.使用adb命令,将文件push到/data/local/tmp 目录下 2.给这个文件云心权限,具体是chmod +x mtk-su 3.运行mtk-su ./mtk-su 4....
MTK开发心得,MTK开发心得,MTK开发心得.
MTK驱动程序下载
适合mtk新手学习的文档、资料,里面有详细的事例教程,手把手教学,希望对想进入MTK的程序员有帮助。mtk相关开发资料比较少,这个是我很辛苦才找到的,分享一下。
MTK相关文档
MTK 刷机工具 WWR
MTK入门教程MTK入门教程MTK入门教程MTK入门教程
在以前写的一篇博文《OTA升级失败排查》和《rkflashkit的安装与使用》中有详细介绍过Rockchip平台下是如何将Android设备中 的各个分区导出来的。 最近在工作中,也遇到同样的需求,需要将一台OTA失败后开不了机的...
MTK平台移植camera的步骤,并对每一个步骤中的易错点,容易忽略点做了介绍。有助于初学者对MTK平台的理解! 以MTK6589移植camera为例!
文档为MTK双麦降噪调试说明,对MTK平台的音频调试做个参考
描述 MTKAndroid添加驱动模块,有利对 MTK认识和工作需要