xyz黑板 - xyzboard.com

最近做个项目，用的是三星的SC32442芯片，号称是S3C2442与SDRAM、NANDFLASH的结合。我却没看出这个芯片有什么好。又贵，200多元。间距又小，0.3mm，焊接成品率低，维修不便。nandflash的容量又小，最大只能256MB。总线还是1.8V的，虽说省了点电，但麻烦啊，如果要扩充点FLASH的话，要么买贵的1.8V芯片（可能还没有），要么用电平转换。
当初，我选择了Windows CE .NET 4.2，虽然它有很多缺点，很多不完善的地方。但是它上面的应用程序开发周期短，人才培养难度低。你想想，找一个会熟练编写Windows程序的人，要比编写Linux的人多的多吧。
所以,虽然WINDOWS CE上的资源较少, 开源工程较少, 我也硬着头发上了. 多花点做BSP的时间, 节省了以后的应用层开发周期, 这样还是值得的。
但现在开发着开发着，觉得很Windows CE .NET 4.2真的是有致命的缺点，就是不支持大容量的Nandflash，因为一般的大容量NandFlash都是2048字节每页面。而CE 4.2 只支持512字节，还没法改，因为大部分相关代码在private目录，这是MS不允许你修改发布的代码。
只好改换 CE 5.0了。
我挺讨厌频繁的升级换代，因为做产品就要有做产品的样子，一个版本应该稳定的用上十年二十年，除非它实在不能用了。
频繁的升级，造成无数的浪费。但现在我不得不升级了。唉。我都开始犹豫，是否要转向LINUX。但仔细看了看LINUX上的开发，人机界面那块儿做起来很麻烦，而且与CE一样不是免费的。LINUX也是30MB左右的大小，真是无语。不过LINUX的好处是，不像CE一样，编译一次要拷贝几个GB的文件，浪费无数的时间。据说LINUX只需要几分钟就编译完了。虽然我没编译过LINUX，但是从开发VXWORKS的经验来看，它们是属于同一类型的，编译应该比较快。
LINUX并没有什么优势。与WINCE相比，人机交互、应用软件开发做的没人家好，且QT同样要收费（CE根据你的组件多少，可以选择费用多少的，我了解到的价格一般都是几十人民币吧）；与VXWORKS/RTEMS/UCOS等实时操作系统相比，又显得极其庞大雍肿，实时性稳定性还不如。人家做产品的，如果想做漂亮的人机界面，就不再乎这开源的几十元钱，宁愿用WINCE做的方便漂亮；如果想做小的嵌入式模块，想选免费系统，LINUX又过于庞大无法胜任（30MB的空间占用啊！！就算精简又能小多少呢？），实时性也不好。我不看好嵌入式LINUX。
犹豫了一下，我还是选择了CE 5.0，就当是上了贼船吧。5.0，又得重新熟悉那微软那一套。唉。万恶的微软。

发表评论

删除了N多的垃圾评论

Submitted by xyz黑板 on 星期日, 十一月 18, 2007 - 04:28

随笔


DELETE FROM `comments` WHERE `comments`.`timestamp` >1194143141;
DELETE FROM `comments` WHERE `comments`.`nid` = 78 `comments`.`timestamp` >1194143141;
DELETE FROM `comments` WHERE `comments`.`comment`like "%http%"

DELETE FROM `comments` WHERE `comments`.`name` = "Anonymous" and `comments`.`homepage`like "%http%"

发表评论

脆弱的网络

Submitted by xyz黑板 on 星期日, 十一月 18, 2007 - 03:46

随笔

本来想着是每周备份一次网站的数据的,结果一时不查,一个月左右都没有备份

结果,还真的是服务器挂了,数据全部丢了,

edong的牛B客服QQ:758656 说赔偿就是延长三个月的期限，其它没的谈。要退款就没赔偿。

唉，中国的IDC服务商就是牛B。

发表评论

调试WINCE的时候，应该做些什么

Submitted by xyz黑板 on 星期四, 十月 18, 2007 - 08:12

随笔

windows ce，编译起来那叫一个慢啊，特别是ce 4.2 .net，极其的慢，变态的慢

都快赶上FPGA了

而且，你改了驱动，还不能直接用PB编译，还得去驱动目录手动编译一下，然后再到PB下整体编译一次，才能起效果。对微软真是无语了。而且，编译之前，还要把所有的文件，包括头文件，库文件之类的，全部拷贝到工程目录下编译，真是烂啊，一次就要拷4000个左右的文件，占硬盘达几个GB。你说做这CE的操作系统是不是太恶心人了。

看看VXWORKS多清爽啊，羡慕死了

但是，没办法，说归说，还是得做WINCE。那在编译CE的时候，应该做些啥了？答案就是：看小说！

发表评论

如何排除程序中的bug

Submitted by xyz黑板 on 星期日, 九月 9, 2007 - 04:39

软件工程

一点想法，在此抛砖引玉了。

找bug的方法，是值得研究的，因为找bug的时间在软件开发周期中占有极大的比例。只要统计一下，软件开发者花费在排除bug上的时间，与花费在写代码上的时间的比例，就可以知道。排除bug的时间在整个软件开发周期中占到了80%以上。

所以，排除bug的方法就有必要好好研究一下。下面是三种典型的排除bug的方法：

一种是猜bug的方法。很多开发者，并没有花心思去排除bug，而是直接在原代码中找到某个可能出错的地方，修改一下，再执行一次看看bug还在不在，如果还在，就换个地方修改，看看bug解决了没有，如此住复，只到bug解决。这种方法并不是真正的排除bug，而是开发者觉得无法分析出bug出现的原因后，放弃了分析，转而使用省脑力耗体力的方法来猜bug。我们软件组的人，不允许出现这种猜bug的情况，因为这种事情只有业余选手才会干出来。

一种是设断点调试的方法。设断点之后，可以仔细分析当前的变量、结构是否正常，从而找到bug。这个方法虽然比上一种方法要高效，但当随着程序趋于复杂时，调试bug花费的时间会越来越多，也会出现补了东边儿，漏了西边儿的情况。另外，在嵌入式领域，很多情况下是没有办法调试的，而且有很多bug是几天难得一见，不会让你有那么好的机会设下断点调试。

一种是断言分析法。对复杂的逻辑、输入输出条件等，设定断言或判断，并将不符合预想结果的错误信息输出。错误信息输出的越详细越好，而且可以存成log文件待事后分析。这样一但出现bug，就可以很快的通过断言、错误信息输出判断出bug所在的位置，从而即时解决。

在以上几种除错方法中，我最提倡的是第三种断言分析法。对于断言分析法，应该再辅助以自动测试代码，对软件中可以测试的函数、模块均进行自动测试，对边缘条件、分支组合进行尽可能的测试。一个一个的函数、模块都测好了，软件出现bug的机会就会减少，就好像盖高楼大厦时，地基要打牢一样。

断言分析法，与自动测试配合之后。在软件出现bug时，就应该冷静的思考一下，是什么地方可能导致bug，因为有了断言与自动测试，我们可以肯定的排除很多种情况，这样一条一条的理下来，最终达到不用调试，而是凭借逻辑分析，直指bug所在。达到这一步，一个软件高手就诞生了。

发表评论

软件工程的迷失

Submitted by xyz黑板 on 星期四, 九月 6, 2007 - 01:49

软件工程

国内外的软件工程书，一堆一堆的，但是为何还有那么多软件做的很烂的公司、单位？

做软件，就像治国。
有无数本经史子集，治国方策，却还是有那么多的烂君主。

开国君主，都会制定一个好的制度，保证国家长治久安。作为软件Team的领导者，也是一样，要根据形式、根据具体情况，制定下符合本team的软件工程策略。

很多软件工程，纯粹是在误导人。因为它们规定了很多无法实现的制度，就好像明朝把官员的薪水定的很低，又希望他们廉洁一样。

很多软件工程的书，要求把文档写的越详细越好。而恰恰是国人在做软件开发的时候，写文档写的少，故而每当看到这种论点，都有愧卑之心，并把它们奉为经典。俗话说得不到的，是最美的，在这里就是一例。然而，文档并非越详细越好，无法实现的软件工程，只能是浮云。

在我看来，软件工程首先要符合人的本性，其次要实实在在。
符合人的本性，就是指，软件工程，以人为本，充分考虑到人性。比如，人有把事情做完美的本性，人有懒惰的本性，人有趋利的本性，人有对即时的奖惩条件反射的本性。针对人的本性设计软件工程策略，重在因势利导。
实实在在，就是指，软件工程中规定的东西，只有经过自己反复推敲，确认一定有用，才能采纳。就像法庭中的疑罪从无，我们做软件工程的，只要不知道某种软件工程方法有什么具体用处，一律不采用。

在软件工程领域，我是倡导改革的。循规蹈距一向是庸人的专利。

2 comments

搜索

导航

常用链接

热门内容

今日：

总体：