展讯平台令我欲哭无泪（连载－－个人观点）

aquasnake

以下是引用talisker在2012-4-9 9:59:00的发言：
%


呵呵，他不在展讯了 。。。

现在展讯的代码，库封装太多，导致复用性很差，make file控制连结库判断脚本复杂，耦合太强，make file出版本容易造成翘翘板效应（就是一个make file调顺了，其他的make file又有问题了，其他调好了，这个又冲突了，出版本相当苦恼与浪费校验时间），而且perl解析正则表达式语句复杂造成递归太深，严重影响解析速度（现在总build速度都已经非常慢了，根MTK差不多了，原来展讯是一直遍起来很快的）

耦合弱的一些多媒体音频，视频codec算法，一些layer1,DSPlayer等底层，一些tcpip协议，atc等有必要封装，但其他的与rtos或者与其他模块耦合强的全局接口，能尽可能opensource就open出来，这样代码包体积可以缩小，版本维护也会更省力。

szbailian

苹果4S软件1比1的中文语音助理Siri
1通过语音命令实现日常需求
2打电话，发短信，打开各种应用
3听音乐，看视频
4听笑话，讲故事，，，，
QQ1748268304
【文件名】:12226@52RD_语音助理2[1][1].0版产品介绍.ppt
【格　式】:ppt
【大　小】:4171K
【简　介】:
【目　录】:

点击浏览该文件

talisker

以下是引用aquasnake在2012-4-12 14:48:00的发言：

现在展讯的代码，库封装太多，导致复用性很差，make file控制连结库判断脚本复杂，耦合太强，make file出版本容易造成翘翘板效应（就是一个make file调顺了，其他的make file又有问题了，其他调好了，这个又冲突了，出版本相当苦恼与浪费校验时间），而且perl解析正则表达式语句复杂造成递归太深，严重影响解析速度（现在总build速度都已经非常慢了，根MTK差不多了，原来展讯是一直遍起来很快的）

耦合弱的一些多媒体音频，视频codec算法，一些layer1,DSPlayer等底层，一些tcpip协议，atc等有必要封装，但其他的与rtos或者与其他模块耦合强的全局接口，能尽可能opensource就open出来，这样代码包体积可以缩小，版本维护也会更省力。

好久不看了，就不多说了，不调查是没有发言权的，呵呵 [em02]

talisker

以下是引用aquasnake在2012-4-4 22:53:00的发言：
。
PS:我们现在已经把6620的09A_W11.16_P13版本改成了只有两套库(一套对应6610的16Mb RAM,一套对应6620的32Mb RAM)的lib结构,并且恢复了一些展讯原本disable掉的宏功能(我相信展讯是因为版本ROM/RAM size超标的原因而关闭)在小版本6610上开放出来(我们当然逆向工程了库,并且尽可能多地还原成sourcecode,并不会对编译后的代码以及系统有任何不良负作用,有且仅有功能的提升).有想技术切磋的我可以专门开一个专题探讨研究.

这个有意思，开个专题一起探讨吧，贴些不良代码或者脚本的片段来，
如果不方便贴出来，那我们找个方式私自交流，行不 ？ 我的邮箱短信你了。[em01]

mikal

以下是引用aquasnake在2012-4-4 22:53:00的发言：
。
这几天我跟我朋友研究了一下展讯的库,发现某些东西实际上是开源代码来的,不过展讯是做了二次开发,比如lzma.a,应该很容易就把它反向工程了.

展讯的代码,mikal在08年以前作6600D应该还不是mocor平台,那个时候是用codeworrior IDE,用mcp工程文件去组织整个编译控制的,那个时候的特征是编译非常快(直接mcp调用arm cc与link),Bin code的ROM空间很优化,动态消息窗口判断的机制,都是在RAM中执行,很少静态的结构体,代码比较容易阅读,上手比较快;缺点是MMI执行比较慢,比MTK那种静态结构体组织的MMI模块模块方式要慢的多,同样ARM7 78Mhz下效率不如MTK.

在08年以后,特别是到10年,展讯在ARM7平台上的代码进入了一个完善阶段,平台换成MOCOR,利用perl解析make文件控制编译的方式,已经非常接近MTK的开发方式了,优点是各模块编译控制灵活,缺点是编译速度变慢,perl语言解释执行还是不如ADS的IDE上.mcp工程设置.但用make file控制编译宏,用perl脚本控制编译参数与调用编译/开发工具是大趋势,随着工程代码的增加,项目的扩展,你必须用这种组织工程开发模式.当时展讯的代码非常好上手,MTK的软件工程湿去转展讯平台都很容易.

在11年以后,展讯6620代码释放后,软件版本质量又走下坡路了,倒不是因为BUG,而是整个工程代码的控制,由于展讯一直对库比较封锁,所以必须出很多套库来对应各种make模板,由于不开源,导致了版本内部错误的增加,每一个子模块make file的宏不同,所产生的库是不同的,由于这种问题带来的版本维护与二次开发中导致的冲突增多.但其实这种情况是可以避免的,出版本的人也许根本不了解一些API的调用与工程组织结构,如果定义一套完整的API接口,所有工程模板都可以调用,只不过小功能版是全功能版本的子集(如6610_3216<6610_6416<6620_3232<6620_6432<6620_128_32).这限制了平台上二次开发的门槛,因为库封装的原因,有时候你必须逆向工程恢复出原始代码并统一成尽可能少的库函数调用.

PS:我们现在已经把6620的09A_W11.16_P13版本改成了只有两套库(一套对应6610的16Mb RAM,一套对应6620的32Mb RAM)的lib结构,并且恢复了一些展讯原本disable掉的宏功能(我相信展讯是因为版本ROM/RAM size超标的原因而关闭)在小版本6610上开放出来(我们当然逆向工程了库,并且尽可能多地还原成sourcecode,并不会对编译后的代码以及系统有任何不良负作用,有且仅有功能的提升).有想技术切磋的我可以专门开一个专题探讨研究.

好多年不上来了，今天有点空，上来猫猫，本想找点人，鬼使神差就看到这里，又勾起了我对以前手机代码的回忆。哈哈！
针对编译原理，没有太深究过，不过有些自己的看法：
1、如今ARM 公司出品的cpu，所有IDE或者 makefile 方式采用的都是 ARM的编译工具如ARMCC，链接工具如，ARMlink，至于GCCforARM应该
   在feather phone领域比较少吧？当然基于linux的可能会用到gcc，没有做过安卓，不了解，所以不确定；针对aquasnake提出的
   原来采用IDE codewarrie 和如今采用 makefile，在编译这块，如果编译器相同，编译效率应该是一样的，但是针对link这段，IDE
   codewarrie也支持强大的link脚本，所以只要link脚本一样，那么IDE出来的和makefile出来的文件在优化和执行时间是一样的。但是
   区别在于编译的体现方式方面，灵活度方面，makefile 貌似会简洁，但是如果对makefile深入了解，会发现IDE和makefile是一样的。
   IDE仅仅是封装了makefile，而我们现在的makefile是全裸的罢了。所以，有时候不要迷恋linux所谓的cmd的makefile一方独大：）

2、aquasnake 提到的逆向工程（我一直喜欢说盗版：）），针对编译过的lib，如果没有enable的宏，在lib中还可见，这个我真不知道
   希望学习下，我一直以为宏是在CC阶段处理的，但是按照您的意思可能是在link阶段处理的。我现在很懒惰了，都不太喜欢查资料。
   希望 aquasnake 来扫扫盲。

3、aquasnake 提到的整合lib，并实施了，这是一个进步，说明您公司在你的带来下，还是很有深度的研究。希望aquasnake 多多
   培养这样的人才，不仅仅是为公司，也是为社会。

aquasnake

以下是引用talisker在2012-4-16 9:17:00的发言：
.


这个有意思，开个专题一起探讨吧，贴些不良代码或者脚本的片段来，
如果不方便贴出来，那我们找个方式私自交流，行不 ？ 我的邮箱短信你了。[em01]

有一个bug,在6620 mocor 09a_w11.16_p13版本或者之前一直都遗留的，就是auto pac生成pac的脚本写的太罗嗦了，我们合并了一部分中间过程，缩短了build时间。build对文件夹路径的深度有很大关系，现在的版本，路径最深的大概就在mmi resource的一些图片，而perl在copy以及用resgen产生资源bin的时候就很慢了，对越是路径深的文件操作的脚本优化，效果越明显。

mikal的说法是IDE调用的arm cc与arm link时间上与make file组织理论上应该一样，但其实make file用active prel环境下本身就是一个命令行的解释语言脚本的批处理，由于perl这种套用正则表达式展开会很浪费RAM以及解析时间，看写脚本的人的水平了，不同的人写出来的脚本，最终build时间可能差异很大。

这些其实问题不大，最大的问题还在于库，如果展讯还是这么封闭，那么出问题是自找的，参考代码的make file将会死的一动不动。一套代码里面有10多套库，这简直就是在制造混乱。

aquasnake

以下是引用mikal在2012-5-14 10:38:00的发言：
.

2、aquasnake 提到的逆向工程（我一直喜欢说盗版：）），针对编译过的lib，如果没有enable的宏，在lib中还可见，这个我真不知道
                 希望学习下，我一直以为宏是在CC阶段处理的，但是按照您的意思可能是在link阶段处理的。我现在很懒惰了，都不太喜欢查资料。
                 希望 aquasnake 来扫扫盲。

库是已经编译后的二进制机器码了（等同于汇编，但跳转行号标记不具有可读性，是编译器自动产生的数字），然后不同的版本链接不同的库，由make file中指定库路径。

写的好的库，其中的代码组织是由不同的函数名实现组织，并不需要用宏控制，小功能版本调用小规模的函数，全功能版本可以调用所有函数。写的不好，用宏去让编译器产生分支代码的话，就有麻烦，各种库不能复用。

所以我一直禁止在生成库的模块原代码中用ifdef等条件预编译语句的做法。宁愿传递一个全局的布尔变量或者枚举变量。把封闭的库与可见的部分代码独立出来，降低代码耦合。

mikal

以下是引用aquasnake在2012-5-18 14:35:00的发言：
]
有一个bug,在6620 mocor 09a_w11.16_p13版本或者之前一直都遗留的，就是auto pac生成pac的脚本写的太罗嗦了，我们合并了一部分中间过程，缩短了build时间。build对文件夹路径的深度有很大关系，现在的版本，路径最深的大概就在mmi resource的一些图片，而perl在copy以及用resgen产生资源bin的时候就很慢了，对越是路径深的文件操作的脚本优化，效果越明显。

mikal的说法是IDE调用的arm cc与arm link时间上与make file组织理论上应该一样，但其实make file用active prel环境下本身就是一个命令行的解释语言脚本的批处理，由于perl这种套用正则表达式展开会很浪费RAM以及解析时间，看写脚本的人的水平了，不同的人写出来的脚本，最终build时间可能差异很大。

这些其实问题不大，最大的问题还在于库，如果展讯还是这么封闭，那么出问题是自找的，参考代码的make file将会死的一动不动。一套代码里面有10多套库，这简直就是在制造混乱。

aquasnake 提高的速度慢在于关于makefile文件解析过程中使用了类似perl这些高级脚本语言，让编译系统慢，这个表示赞同。不过如果不全编译，这样的问题可能会少点。如果全编译，那么采用联合编译，速度会加快，其实，现在很多大型软件开发，即使不用perl来做，完全是文件编译，上万的文件，那编译也是海量时间，所以多机联合编译早已经是业内不二的选择了。

mikal

以下是引用aquasnake在2012-5-18 15:07:00的发言：


库是已经编译后的二进制机器码了（等同于汇编，但跳转行号标记不具有可读性，是编译器自动产生的数字），然后不同的版本链接不同的库，由make file中指定库路径。

写的好的库，其中的代码组织是由不同的函数名实现组织，并不需要用宏控制，小功能版本调用小规模的函数，全功能版本可以调用所有函数。写的不好，用宏去让编译器产生分支代码的话，就有麻烦，各种库不能复用。

所以我一直禁止在生成库的模块原代码中用ifdef等条件预编译语句的做法。宁愿传递一个全局的布尔变量或者枚举变量。把封闭的库与可见的部分代码独立出来，降低代码耦合。

这里我发表下我自己不同的观点。所以预处理命令在经过编译间阶段后生产目标文件，其预处理的生命
周期也结束了，如果这个阶段反汇编，还原后的代码都是唯一性的，没有预处理的选择性。
另外，预处理的最大用处其实就是代码的统一管理，另外库函数要做到尽量精简，基于这样的思路，我们可以看到很多库函数采用大量的#if宏，其无非就是希望代码统一管理，执行效率提高。作为展讯这样的
方案公司，采用这样的方法是合理，而且科学的。作为aquasnake 这样的公司，你们的做法也是科学合理的。由于公司规模，性质不同，那么就采用种不同的方法。至于aquasnake说道小规模函数和所有函数，我想理解上可能有些不同，库中肯定有同名但不同功能的函数，这个时候就必须用宏控制，如果不用宏
，那么必须产生条件执行，就必须产生不必要的代码，由此，效率低，空间大。当然，一个平台库太多
也是一个问题，起码系统工程没有做好，如果一个平台只有1个库那也是问题。
备注：我感兴趣的是您提到的lib中的disable的宏的功能怎么恢复的？

aquasnake

其实是这样的，我调用的是最全功能的库，库里面不做任何条件预编译控制，在开源的接口上做dummy封装。库是同一个。你小版本需要disable的函数我就dummy做个空壳。保证库的唯一性。
这样就不需要把库做的很多分支。
我一直反感用条件编译去产生闭源的库的做法。

taylertang

不明觉厉。

Suki

现在有两个前同事在展讯[em11]

2811162367

出现货：MT6582V/E,MT6582V/F,MT6575MA,MT6575A,MT6589TMK,MT6620P,MT6168A,AST3001A,MT6163N,AK8975C,KXTIK-1004,GT818,MC3410,YAS530B,KXUD9-1050,RF7168TR13,RF3234,SD25-0836R9UBM1等等，有需要的请联系。
另外：长期回收一切手机平板呆滞电子物料，专业处理库存，有需要处理的公司或朋友麻烦联系我，中介有酬。手机：18902442242，QQ2811162367，邮件：18902442242@163.com

Xiangxuzheng

知耻而后勇，智

calvin_kim

展讯太差了，还是用MTK吧。

ap06043

讨论这么激烈，好贴

betterlife

新三板即将上市公司招聘AE和工艺，有股票
贝特莱公司介绍：
   深圳贝特莱电子科技有限公司（Betterlife Corporation）于2011 年7 月成立，是一家高端集成电路设计企业，致力于开发具有自主知识产权的核心技术，专注于消费类电子的IC设计，在触控、AMOLED驱动、指纹识别及生命感知产品领域卓有建树。
    公司由美国加州大学终身教授、中组部“千人计划”获得者谭向东博士作为首席科学家领衔，以在国内外知名半导体公司有6-15年IC设计经验的技术专家为研发骨干，以领先国内同行的前沿技术，迅速开发出具有核心竞争力的产品。
    2014年公司被工信部评为“5大最具发展潜力的中国IC设计公司”，国务院副总理马凯曾到公司考察。
　   贝特莱是国内首家推出小面阵指纹识别传感器，并量产的企业。
职位:指纹识别应用工程师

职能描述
1、负责指纹识别芯片的驱动软件和演示程序的开发、维护与应用;
2、负责指纹识别芯片与手机、平板系统的导入、调试;

任职要求
1、电子工程或计算机专业
2、在指纹识别应用方面的经验优先；有过芯片原厂FAE或者手机公司软件开发经验优先；
3、精通 C/C++，Linux,Kernel和 Android,framework；
4、熟悉APK开发和java 语言；
5、爱岗敬业，态度积极，有责任心，有客户服务意识，吃苦耐劳，愿意出差；
6、良好的团队合作精神，良好的沟通能力。

待遇
行业平均薪资(具体面议)，年终奖金，股票期权

职位:指纹识别模组工程师

职能描述
1、负责与封装厂和模组厂沟通合作，进行指纹封装方案以及指纹模组方案的设计以及确认。
2、负责新产品导入晶圆级封装工厂的技术，进度管控、品质及异常处理；对生产数据和良率分析，提高生产良率。
3、在工艺方面支持手机、平板等客户，完成指纹模组的导入，顺利量产。

任职要求
1、物理、化学、材料、光电或电子相关专业，有PCB、FPC等Layout经验者优先；
2、了解芯片封装的工艺流程，有QFN\QFP\SOP\LGA\BGA其中几种封装经验，熟悉Trench\TSV\CSP等封装技术者优先；
3、了解芯片测试、封装，熟悉模组加工工艺，有手机生产以及测试或封装工艺工程师经验或模组工艺工程师经验者优先；
4、良好的团队合作和当责精神，沟通能力

待遇
行业平均薪资(具体面议)，年终奖金，股票期权
有意者联系chenliang@blestech.com