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

everjoy

楼主自我感觉牛B无比也让我欲哭无泪~~~~~~~~~~~~~~~~~~   sigh~~~

limeng57

很高深的说
~

reisky_zlh

年轻人言辞虽然激烈点，但说的也不是没有依据的，一码事归一码事，不同的人看问题的角度也不一样，作为展讯平台客户，希望看到平台的设计人员听取客观的批评，完善自己的平台，旁观的人可以听取观众的意见，以作为平台选型的依据，如果展讯的人看到，是否能关心客户的抱怨，积极改善，做生意讲究互惠互利麻。

anmin

又看到一好贴,顶下.

happfly

恰如: 初看山是山,再看不是山,最后看,还是山  

发现MTK,speadrum这样的平台都是写的很商业化的东西，

明白了点什么｀～～

waterbogie

展讯开机慢根本不是你所说的函数做的事情太多的原因，不要瞎扯。
开机慢那是因为开始就把所有代码都load到ram中需要花时间。这一点和其他平台不同。

avr-arale

一页一页的翻下来都看了！
才知道，写的很好！

astron

MTK的代码比Spreadtrum更让你吐血，我非常反感MTK大量地，过分地，变态地使用全局变量，且它的Windowing System也是相当地垃圾。

perennial

是个好贴，我转抄了makal发的突然截至的理由文章。

zhaodaobeile

<DIV class=quote><B>以下是引用<I>astron</I>在2007-12-9 18:07:00的发言：</B>
MTK的代码比Spreadtrum更让你吐血，我非常反感MTK大量地，过分地，变态地使用全局变量，且它的Windowing System也是相当地垃圾。</DIV>



同感。真不明白mtk的这样的代码，是怎样设计出来的。编译还这么慢。

goodmoden

对mtk编译慢，可以来这里看看，让你有所收获！
http://www.52rd.com/bbs/Detail_RD.BBS_105605_131_2_1.html

wingover

国内就没有真正的软件构架师，所以写成这样也是可以理解的

现在看，展讯同mtk竞争，mtk软件本身有印度人构架好了，又被台湾人改了改，虽说全局变量多些，但至少构架上还算合理。展讯就不同了，各种模块功能是临时被竞争对手强加上的，你没的选择，别人出了mp4，你没有，要怎么竞争，所以就得加，别人已经有了，你现在想赶上，那就的比别人快，但软件不是你想快就快的，所以这些垃圾代码就出来了，简要的说就是时间短任务重。。

vonyoven

我支持你们啊。
我看的6600L平台，全局函数，全局变量多。

GGgirl

以下是引用orion_lee在2006-6-7 12:51:00的发言：
MMI应该是通过FFS对NAND进行操作的

呵呵，最近也在用它家的平台，确实有点欲哭无泪[em10]

wangzhengh

展讯的代码烂也就算了，开放的东西还比MTK少。
特别是模拟器和LCD这块。自以为有什么很核心的技术，但是给开发者带来的麻烦不是一点两点。

ernest68028

以下是引用wingover在2007-12-13 18:22:00的发言：
国内就没有真正的软件构架师，所以写成这样也是可以理解的

现在看，展讯同mtk竞争，mtk软件本身有印度人构架好了，又被台湾人改了改，虽说全局变量多些，但至少构架上还算合理。展讯就不同了，各种模块功能是临时被竞争对手强加上的，你没的选择，别人出了mp4，你没有，要怎么竞争，所以就得加，别人已经有了，你现在想赶上，那就的比别人快，但软件不是你想快就快的，所以这些垃圾代码就出来了，简要的说就是时间短任务重。。

“时间短任务重”有道理！！！

jimbo_lee

继续关注

aquasnake

以下是引用wangzhengh在2010-1-22 13:36:00的发言：
展讯的代码烂也就算了，开放的东西还比MTK少。
特别是模拟器和LCD这块。自以为有什么很核心的技术，但是给开发者带来的麻烦不是一点两点。

这几天我跟我朋友研究了一下展讯的库,发现某些东西实际上是开源代码来的,不过展讯是做了二次开发,比如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,并不会对编译后的代码以及系统有任何不良负作用,有且仅有功能的提升).有想技术切磋的我可以专门开一个专题探讨研究.

aquasnake

以下是引用picasso在2006-9-29 10:46:00的发言：



这位朋友，没有这么简单的。
我们需要考虑内存的应用，如果按照上述的方法，那这块buffer从何而来？不要告诉我用malloc，在内存不够的情况下，有可能会分配不出来的。同时，作为模块来说，窗口的app不应该关心list所用buffer的大小，更不应该去set一个buffer给list用，这样耦合太紧密。同样，如果要set buffer给list，那设置多大的buffer合适呢？又需要一套计算。
所以，这个方法可行性不大。具体怎么做，我们需要考虑，但我们的目标是在不改变接口，或者说不增加使用难度的，或者说，对app来说，是透明的。
不过，对朋友你的批评，我们非常欢迎。我们也是希望做好我们的平台。
<p align=right><font color=red>+3 RD币</font></p>

希望picasso如今还在展讯,软件重要的是思想,一个好的实现思想,可以让代码量缩减20%,代码的复用率提高800%

talisker

以下是引用aquasnake在2012-4-4 23:07:00的发言：
>
希望picasso如今还在展讯,软件重要的是思想,一个好的实现思想,可以让代码量缩减20%,代码的复用率提高800%

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